Re: param expansion with single-character special vars in the environment

On 5/2/16 4:01 PM, Dan Douglas wrote: > On Mon, May 2, 2016 at 1:59 PM, Grisha Levit wrote: >> >> On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: >>> >>> and this one throws away the nameref attribute: >>> >>> typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo >> >> >> I think it's impo

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 1:59 PM, Grisha Levit wrote: > > On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: >> >> and this one throws away the nameref attribute: >> >> typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > > > I think it's important to note that the nameref attribute is throw

Re: param expansion with single-character special vars in the environment

On 5/2/16 2:59 PM, Grisha Levit wrote: > > On Mon, May 2, 2016 at 2:48 PM, Chet Ramey > wrote: > > and this one throws away the nameref attribute: > > typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > > > I think it's important to note that the n

IFS as the control variable in a for loop

When in a non-interactive shell, IFS, when modified as the control variable in a for loop does not change splitting behavior. $ bash -c 'for IFS in .; do printf "%s\n" "$IFS" "$*"; done' bash x x . x x $ bash -ic 'for IFS in .; do printf "%s\n" "$IFS" "$*"; done' bash x x . x.x

Re: param expansion with single-character special vars in the environment

On Mon, May 2, 2016 at 2:48 PM, Chet Ramey wrote: > and this one throws away the nameref attribute: > > typeset -n foo ; typeset -i foo ; foo=7*6 ; typeset -p foo > I think it's important to note that the nameref attribute is thrown away at the `typeset -i foo' step, which makes some sense since

Re: param expansion with single-character special vars in the environment

On 5/2/16 12:12 PM, Chet Ramey wrote: > On 4/27/16 4:07 PM, Eduardo A. Bustamante López wrote: > >> The 'mapfile' one is interesting, because it drops the nameref attribute from >> the 'r' variable. > > Array variables can't have the nameref attribute. The process of creating > and clearing the

Re: param expansion with single-character special vars in the environment

On 4/27/16 8:36 PM, Grisha Levit wrote: > > On Wed, Apr 27, 2016 at 6:47 PM, Piotr Grzybowski > wrote: > > + if (v == 0 && onref || ( onref && !legal_identifier(value))) > > > Shouldn't this (and the other patch) check valid_array_reference as well t

Re: param expansion with single-character special vars in the environment

On 4/27/16 7:37 PM, Piotr Grzybowski wrote: > > sorry for the spam concerning the patch: it needs merging with what Eduardo > posted (excluding the `declare -n r; declare -n r;' regression bug), and what > is in #ifdef 0 in declare.def; I just found out that it is exactly what it > intends to

Re: declare [-+]n behavior on existing (chained) namerefs

Hi, I hope the attached patch does not break to much; it addresses the masking: > declare -nt r=a; f() { declare a; declare -n r=a; declare -p a r; }; f as per Grisha's report; it tries to enlighten make_local_variable to the existence of nameref by returning existing local nameref in scope (d

Re: param expansion with single-character special vars in the environment

On 4/27/16 4:07 PM, Eduardo A. Bustamante López wrote: > The 'mapfile' one is interesting, because it drops the nameref attribute from > the 'r' variable. Array variables can't have the nameref attribute. The process of creating and clearing the array with the name supplied as an argument clears

Array expansions in scalar assignments

Hi, it looks like these expansions still aren't quite being delimited by IFS consistently. Probably strangest of these is a4 where `$*` doesn't agree with `${a[*]}`, and a3 vs. a4 where quoting modifies the result. I would think bash should look like the ksh output with all @'s space-separated and

Re: param expansion with single-character special vars in the environment

On 4/27/16 8:41 AM, Grisha Levit wrote: > On Wed, Apr 27, 2016 at 7:37 AM, Piotr Grzybowski > wrote: > > It seems to me that creating the reference should be allowed, but the > access to the referenced variable should honor its attributes. > > Once you conver

Re: [patch] /* XXX - possibly run Coproc->name through word expansion? */

Hi, On 2 May 2016, at 10:26, Dan Douglas wrote: > FWIW, something like this works currently. This pattern is useful in a > bunch of situations where the shell wants to assign to a fixed > variable name. (getopts being another). [..] thanks for the hint, of course I like it with the patch better

Re: [patch] /* XXX - possibly run Coproc->name through word expansion? */

FWIW, something like this works currently. This pattern is useful in a bunch of situations where the shell wants to assign to a fixed variable name. (getopts being another). ~ $ bash /dev/fd/9 9<<\EOF function mkProcs { typeset -n COPROC ref=$1 set -- "${ref[@]}" for COPROC; do co