a == a[0] convention

This is possibly relevant to some of Grisha's observations. First, declaring or assigning to a variable with a subscript. I think I would prefer these to be errors for various reasons. Admittedly there's an argument for making one or both of these non-errors for declarations without assignment for

Re: Bash crash bug

On Thu, Jun 2, 2016 at 1:12 PM, Matthias Zimmerman wrote: > a better example is > cat <(su) | cat > cat <([a very simple program that will block io]) | (any thing else) Ok, it does crash. Next time, please send your message to bug-bash@gnu.org as well. -- konsolebox

Re: mapfile creates poorly-named array if passed nameref to array subscript

I guess it’s even more general than just list assignments. See also below problems with declare: $ declare -n ref=var[123]; unset ref; declare ref=; declare -p ${!ref}declare -- var[123]="123]" $ declare -n ref=var[123]; unset ref; declare ref+=; declare -p ${!ref}declare -- var[123]="23]" $ dec

Re: mapfile creates poorly-named array if passed nameref to array subscript

Actually it’s a bit more general than just mapfile: $ declare -n ref=XXX[0]; declare -A ref; ref[foo]=bar $ declare -p XXX[0]declare -A XXX[0]=([foo]="bar" ) $ declare -n ref=XXX[0]; ref+=([2]=x) $ declare -p XXX[0]declare -a XXX[0]=([2]="x") $ declare -n ref=XXX[0]; read -a ref <<< "A B C" $ de

Re: {ref}<&- does not work on array reference subscripts

Yikes, I missed the exec command in my example, that would certainly make it confusing.. What I meant was that the assignment works (i.e. the nameref is followed correctly), but the relevant code doesn’t handle retrieving the v

Re: {ref}<&- does not work on array reference subscripts

You also noticed it runs in a subshell generally. Do you expect something different here? I think <&- should be consistent. On Wed, Jun 1, 2016 at 5:15 PM, Grisha Levit wrote: > declare -n ref=var[0] > {ref} {ref}<&- # fails

mapfile creates poorly-named array if passed nameref to array subscript

$ declare -n ref=XXX[0]; mapfile ref <<< $'1\n2'; declare -p XXX[0]declare -a XXX[0]=([0]=$'1\n' [1]=$'2\n') maybe makes sense to check for legal identifier before making the array? ​

{ref}<&- does not work on array reference subscripts

declare -n ref=var[0] {ref}

Re: nameref/subscript fixes for unset builtin

On Tue, May 31, 2016 at 11:40 PM, Grisha Levit wrote: The patch below addresses the following three issues: > Slightly better patch attached. ​ unset_nameref_subscripts-rev2.patch Description: Binary data

Re: Unexpected tilde expansion

On 6/1/16 9:33 AM, Christian wrote: > Hello, > > I have been playing around with tilde expansion lately and I think i > have discovered a case where the tilde is expanded where it, according > to the documentation, should not. When running in its default mode, bash expands the tilde in that situa

Re: Unexpected tilde expansion

On Wed, Jun 01, 2016 at 04:57:46PM +0200, Ángel González wrote: > On 2016-06-01 at 10:40 -0400, Greg Wooledge wrote: > > On Wed, Jun 01, 2016 at 03:33:23PM +0200, Christian wrote: > > > sh and zsh both return the expected x=~ > > > > > > sh -c "echo x=~" > > > > > > x=~ > > > > imadev:~$ bash -c

Re: Unexpected tilde expansion

On 2016-06-01 at 10:40 -0400, Greg Wooledge wrote: > On Wed, Jun 01, 2016 at 03:33:23PM +0200, Christian wrote: > > sh and zsh both return the expected x=~ > > > > sh -c "echo x=~" > > > > x=~ > > imadev:~$ bash -c 'echo x=~' > x=/net/home/wooledg > imadev:~$ bash -posix -c 'echo x=~' > x=~ Eve

Re: Unexpected tilde expansion

On Wed, Jun 01, 2016 at 03:33:23PM +0200, Christian wrote: > sh and zsh both return the expected x=~ > > sh -c "echo x=~" > > x=~ imadev:~$ bash -c 'echo x=~' x=/net/home/wooledg imadev:~$ bash -posix -c 'echo x=~' x=~

Unexpected tilde expansion

Hello, I have been playing around with tilde expansion lately and I think i have discovered a case where the tilde is expanded where it, according to the documentation, should not. When running: $ x=~ x is set to the current users home directory as expected. $ echo $x /home/christian But whe

Re: declare checks on valid nameref names don't account for +=

On 5/31/16 2:08 PM, Grisha Levit wrote: > On Wed, May 25, 2016 at 3:29 PM, Chet Ramey > wrote: > > > Thanks for the report. Both of these cases should be caught > > Is it deliberate that with the latest changes a faulty += RHS causes an > existing valid nameref