14 Ocak 2021 Perşembe tarihinde Léa Gris yazdı:
> Le 13/01/2021 à 22:13, Chet Ramey écrivait :
>
>> The `-i' forces arithmetic evaluation, which makes this expand to the
>> equivalent of `declare -n b=1'. That's an invalid name for a nameref,
>> which you'd see if you used `declare -n b=1'
> On 2021/01/09 23:52, n952162 wrote:
>> I consider it a bug that bash (and its hash functionality) includes
>> non-executable files in its execution look-up
Of course, as described in the manual page, Bash first searches for an
executable with the right name in the PATH, and then if that fails,
Le 13/01/2021 à 22:13, Chet Ramey écrivait :
The `-i' forces arithmetic evaluation, which makes this expand to the
equivalent of `declare -n b=1'. That's an invalid name for a nameref,
which you'd see if you used `declare -n b=1' instead. The assignment
error causes `declare' to return an
On 1/13/21 1:11 PM, Léa Gris wrote:
echo $BASH_VERSION
5.0.17(1)-release
unset a b
declare -ai a=(1)
declare -in b="a[0]"
The `-i' forces arithmetic evaluation, which makes this expand to the
equivalent of `declare -n b=1'. That's an invalid name for a nameref,
which you'd see if you
On 1/13/21 12:00 PM, Oğuz wrote:
See:
$ declare -ai a=1
$ declare -n b=a[0]
$ b+=1
bash: a[0]1: syntax error in expression (error token is "1")
Reproducible on 5.1.4 too
Interesting. The root cause of this problem has existed since June, 2012,
when I first added namerefs.
On Wed, Jan 13, 2021 at 08:50:45PM +0200, Ilkka Virta wrote:
>However, nameref variables can reference array variables and subscripted
> array variables.
Ah, that's in a different section of the man page. OK, I concede that
this is a bug, then.
>
> Lots of things "could be useful" if only they worked, but they don't work,
> so you don't do them.
>
Yes, and it does work in 4.4.
> The fact that this undocumented, unsupported hack "appeared to work"
> with certain inputs in bash 4.4 is just an unfortunate event, unless
> Chet decides to
On 1/13/21 6:00 PM, bug-bash-requ...@gnu.org wrote:
and then (inevitably)
simply reports an error, because its such files aren't executable.
But it is not inevitable. Using 'cp' as an example. Assuming
you have /usr/bin in your PATH, but ~/bin is in your PATH before
/usr/bin, then try:
On Wed, Jan 13, 2021 at 8:49 PM Greg Wooledge wrote:
> On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> > $ declare -n b=a[0]
>
> I can't see any documentation that supports the idea that this should
> be allowed in the first place.
>
It's common sense. `declare a[0]=x' works, `unset
On Wed, Jan 13, 2021 at 08:28:44PM +0200, Ilkka Virta wrote:
> On Wed, Jan 13, 2021 at 7:49 PM Greg Wooledge wrote:
> > On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> > > $ declare -n b=a[0]
> >
> > I can't see any documentation that supports the idea that this should
> > be allowed
On Wed, Jan 13, 2021 at 7:49 PM Greg Wooledge wrote:
> On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> > $ declare -n b=a[0]
>
> I can't see any documentation that supports the idea that this should
> be allowed in the first place.
>
It's arguably useful though, and works in 4.4
Le 13/01/2021 à 18:49, Greg Wooledge écrivait :
On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
$ declare -n b=a[0]
I can't see any documentation that supports the idea that this should
be allowed in the first place.
-n Give each name the nameref attribute,
On Wed, Jan 13, 2021 at 07:00:42PM +0200, Oğuz wrote:
> $ declare -n b=a[0]
I can't see any documentation that supports the idea that this should
be allowed in the first place.
-n Give each name the nameref attribute, making it a name
reference to
See:
$ declare -ai a=1
$ declare -n b=a[0]
$ b+=1
bash: a[0]1: syntax error in expression (error token is "1")
Reproducible on 5.1.4 too
--
Oğuz
14 matches
Mail list logo
