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

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: 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

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 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

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 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: 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 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 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

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 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

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 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