a == a[0] convention

[Dan Douglas]

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 consistency with the current documentation, and
maybe even allowing the current behavior (no errors ever). I think
that leads to confusion though.

 $ bash -c 'typeset -n ref[0]=foo' # no error
 $ bash -c 'typeset -n ref[1]=foo' # no error

The other variations on this theme are if there are references to
"arrays" with or without a zero subscript. Bash example:

 $ bash -xc '
typeset -n ref1=a1 ref2=a2 ref3=a3[0] ref4=a4[0]
ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
echo "${ref1} ${ref2[0]} ${ref3} ${ref4[0]}"
typeset -p {ref,a}{1,2,3,4}'

+ typeset -n ref1=a1 ref2=a2 'ref3=a3[0]' 'ref4=a4[0]'
+ ref1=foo
+ ref2[0]=foo
+ ref3=foo
+ ref4[0]=foo
+ echo 'foo foo foo foo'
foo foo foo foo
+ typeset -p ref1 ref2 ref3 ref4 a1 a2 a3 a4
declare -n ref1="a1"
declare -a ref2=([0]="foo")
declare -n ref3="a3[0]"
declare -a ref4=([0]="foo")
declare -- a1="foo"
/home/ormaaj/doc/programs/bash-build/bash: line 4: typeset: a2: not found
declare -a a3=([0]="foo")
/home/ormaaj/doc/programs/bash-build/bash: line 4: typeset: a4: not found

I think the mksh result for that code is most like what bash is
probably going for. It mostly treats `ref[0]` as `ref` both when
assigning and dereferencing.

 $ mksh -xc '
typeset -n ref1=a1 ref2=a2 ref3=a3[0] ref4=a4[0]
ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
echo "${ref1} ${ref2[0]} ${ref3} ${ref4[0]}"
typeset -p {ref,a}{1,2,3,4}'
+ typeset -n 'ref1=a1' 'ref2=a2' 'ref3=a3[0]' 'ref4=a4[0]'
+ ref1=foo ref2[0]=foo ref3=foo ref4[0]=foo
+ echo 'foo foo foo foo'
foo foo foo foo
+ typeset -p ref1 ref2 ref3 ref4 a1 a2 a3 a4
typeset -n ref1=a1
typeset -n ref2=a2
typeset -n ref3='a3[0]'
typeset -n ref4='a4[0]'
typeset a1=foo
set -A a2
typeset a2[0]=foo
set -A a3
typeset a3[0]=foo
set -A a4
typeset a4[0]=foo

ksh93 also does that except ref4 which understandably assigns to a4[0][0].

Re: Bash crash bug

[konsolebox]

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

[Grisha Levit]

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

$ declare -n ref=var[123]; unset ref; declare +t ref; ref=X; declare
-p ${!ref}declare -- var[123]="X"

(The +t above can be replaced with any other flag)
​

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

[Grisha Levit]

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"
$ declare -p XXX[0]declare -a XXX[0]=([0]="A" [1]="B" [2]="C")

OTOH coproc now handles this a bit better, in that it won’t create the
array, though it will use one if one exists.

$ declare -n ref=XXX[0]; unset ref; coproc ref { :; }; declare -p ${!ref}
bash: `XXX[0]': not a valid identifier
bash: declare: XXX[0]: not found

$ declare -n ref=XXX[0]; unset ref; ref=(); coproc ref { :; }; declare
-p ${!ref}declare -a XXX[0]=([0]="61" [1]="56")

​

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

[Grisha Levit]

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 value of such a nameref when it needs to do
so to close the descriptor:

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

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

[Dan Douglas]

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

[Grisha Levit]

$ 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

[Grisha Levit]

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

Re: nameref/subscript fixes for unset builtin

[Grisha Levit]

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

[Chet Ramey]

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 situation
because it always has.  When running in Posix mode, it doesn't.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Unexpected tilde expansion

[Greg Wooledge]

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 'echo x=~'
> > x=/net/home/wooledg
> > imadev:~$ bash -posix -c 'echo x=~'
> > x=~
> 
> Even if it's a bash extension, it should be documented. Christian is
> right in that it's an unexpected behavior.

It's documented (in reverse, by saying that POSIX mode *doesn't* do it)
at http://tiswww.case.edu/~chet/bash/POSIX which in turn is referenced
in the SEE ALSO section of the man page.

Re: Unexpected tilde expansion

[Ángel González]

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

Even if it's a bash extension, it should be documented. Christian is
right in that it's an unexpected behavior.

Re: Unexpected tilde expansion

[Greg Wooledge]

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

[Christian]

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

$ echo x=~

x=/home/christian

is returned. This case looks like a variable assignment where the
expansion is expected but it is not, for that reason there should not be
an expansion since the tilde is not at the beginning of the word nor a
variable assignment is taking place.

sh and zsh both return the expected x=~

sh -c "echo x=~"

x=~

zsh -c "echo x=~"

x=~

bash -c "echo x=~"

x=/home/christian


I my understanding of the manual incorrect or is there some hidden
interaction with echo?

Greetings,

Christian Steinhaus

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

[Chet Ramey]

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 to be unset?

The code has always done that.  With more error checking happening at
assignment time instead of on reference, it's more apparent.  I'm working
on it.

> |$ declare -n ref=re $ declare -n ref+=f bash: ref: nameref variable self
> references not allowed $ declare -p ref bash: declare: ref: not found $
> declare -n ref=X $ declare -n ref+=/ bash: declare: `/': not a valid
> identifier $ *declare* -p ref bash: declare: ref: not found|
> 
> Also, this still seems to miss some stuff that would normally be caught:
> 
> |$ declare -n ref=ref[0] bash: declare: ref: nameref variable self
> references not allowed $ declare -n ref=re ref+=f[0] $ declare -p ref
> declare -n ref="ref[0]" |

Yes, though you still can't use it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/