Curious situation.
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
The only mention of this syntax is in an Appendix in the GNU Info >documentation which lists differences between Bash and The Bourne Shell.
Curious situation.
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
The only mention of this syntax is in an Appendix in the GNU Info documentation which lists differences between Bash and The Bourne Shell.
There a single bullet point is made:
] * Bash has indirect variable expansion using ${!word} (see Shell
] Parameter Expansion).
But there is no mention of it in Shell Parameter Expansion.
The other {! gadgets are documented like ${!name[@]} and ${!pattern@}
and whatnot; but not that one.
The man page mentions nothing about it at all.
More curiously, this doc situation already exists in the oldest commit
in Bash git, which was an import of bash-2.0 sources dated 1996.
(I'm presuming that the feature worked then also.)
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Presumably because it does a single pass of variable substitutions.
The result of a variable substitution is not subject to variable
substitution again.
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
$ a=b
$ b=c
$ echo ${${a}}
-bash: ${${a}}: bad substitution
It would make sense, as it is the most intuitive syntax.
In perl the nested brace syntax works alright
$ perl -e '${a}="b"; ${b}="c"; print "${${a}}\n"'
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
That's exactly why I was investigating into it.
The feature is present, together with arrays and ${name[@]} and all
that in bash-2.0.
The feature is absent, as are arrays and all, in bash-1.14.17.
The GNU FTP archive has no tarball of Bash between those two
versions!
I was trying to find out whether ${!word} was introduced before,
after, or at the same time as ${!name[@]} and those other ${!...}
notations.
So, as far as I can guess, Ramey (or someone) perhaps introduced a ${! sequence for signaling the start of some expansion extensions. Computed names ended up there, whether as a first feature, or later one.
To learn more, we would have to bother Ramey with questions.
$ a=b
$ b=c
$ echo ${${a}}
-bash: ${${a}}: bad substitution
Consider that this would be crippled if it only supported ${$.
...
People would try ${abc_$foo} and expect that to work too,
not just ${$foo}.
Whereas ${!...} can more easily handwaved away as the ${! being
a canned sequence for introducing a bunch of extensions (that
are not even related).
On 07.06.2023 22:34, Kaz Kylheku wrote:
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which >>>> holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Because it's non-POSIX ? - Normative text is spread across the
specs, you'll probably have to read the whole chapter 2.6 on
Word Expansion, but see also 'parameter' vs. 'word' definitions
in the syntax.
So, as far as I can guess, Ramey (or someone) perhaps introduced a ${!
sequence for signaling the start of some expansion extensions. Computed
names ended up there, whether as a first feature, or later one.
I _think_ (but may be misremembering) that bash supported ${!var}
before it supported namerefs
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 07.06.2023 22:34, Kaz Kylheku wrote:
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which >>>>> holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Because it's non-POSIX ? - Normative text is spread across the
specs, you'll probably have to read the whole chapter 2.6 on
Word Expansion, but see also 'parameter' vs. 'word' definitions
in the syntax.
Supporting the ${${variable}} syntax would not stop Bash from being
able to execute correctly POSIX shell code. POSIX-compliant shells
can implement non-POSIX extensions, and even exists the possibility
that those extensions be adopted by POSIX in the future.
Because it's non-POSIX ?
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
$ a=b
$ b=c
$ echo ${${a}}
-bash: ${${a}}: bad substitution
Consider that this would be crippled if it only supported ${$.
...
People would try ${abc_$foo} and expect that to work too,
not just ${$foo}.
Another problem with the ${abc_${foo}} syntax would be that it would complicate the specification for typing variables with the NAMEREF
attribute in the builtin 'declare'
declare: declare [-aAfFgilnrtux] [-p] [name[=value] ...]
-n make NAME a reference to the variable named by its value
On 07.06.2023 22:34, Kaz Kylheku wrote:
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which >>>> holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Because it's non-POSIX ? - Normative text is spread across the
specs, you'll probably have to read the whole chapter 2.6 on
Word Expansion, but see also 'parameter' vs. 'word' definitions
in the syntax.
Bash's ${!word} specification makes a big deal about whether word itself
is a nameref. The behavior splits. If it's not a nameref, you get the
named variable indirection. If word it is a nameref, then the feature retrieves the name of the variable targeted by word. Completely
unrelated, different semantics, ouch.
Bash's ${!word} specification makes a big deal about whether word itself
is a nameref. The behavior splits. If it's not a nameref, you get the
named variable indirection. If word it is a nameref, then the feature retrieves the name of the variable targeted by word. Completely
unrelated, different semantics, ouch.
On 08.06.2023 02:38, Javier wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 07.06.2023 22:34, Kaz Kylheku wrote:
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which >>>>>> holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Because it's non-POSIX ? - Normative text is spread across the
specs, you'll probably have to read the whole chapter 2.6 on
Word Expansion, but see also 'parameter' vs. 'word' definitions
in the syntax.
Supporting the ${${variable}} syntax would not stop Bash from being
able to execute correctly POSIX shell code. POSIX-compliant shells
can implement non-POSIX extensions, and even exists the possibility
that those extensions be adopted by POSIX in the future.
What I meant was that in POSIX there's some definitions what may
and what may not appear in lexical context - that's what I thought
to have seen in chapter 2.6 -, and I did not mean any lexically
non-related extensions.
On 2023-06-07, Javier <invalid@invalid.invalid> wrote:[...]
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
That's exactly why I was investigating into it.
The feature is present, together with arrays and ${name[@]} and all
that in bash-2.0.
The feature is absent, as are arrays and all, in bash-1.14.17.
The GNU FTP archive has no tarball of Bash between those two
versions!
I was trying to find out whether ${!word} was introduced before,
after, or at the same time as ${!name[@]} and those other ${!...}
notations.
On 08.06.2023 02:18, Kaz Kylheku wrote:
Bash's ${!word} specification makes a big deal about whether word itself
is a nameref. The behavior splits. If it's not a nameref, you get the
named variable indirection. If word it is a nameref, then the feature
retrieves the name of the variable targeted by word. Completely
unrelated, different semantics, ouch.
Indeed. - What they seem to try to do is finding any non-conflicting combination of punctuation characters to implement new features. (A
bit of a cynical view, I admit.)
This looks like an awful syntax design in zsh, and can lead to very
hard to detect bugs, especially for people familiar with perl
perl -e '${a}="b"; ${b}="c"; print "${${a}}\n"'
c
Curious situation.[...]
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
Op 07-06-2023 om 19:39 schreef Javier:
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
The abandoned 93v- beta of AT&T ksh93 (and hence also the derived and
equally abandoned AT&T ksh2020 project) supported a ${$variable} syntax
for indirection, though nested braces are a syntax error.
I've found multiple bugs in their implementation of it, the worst being:
- It malfunctions for indexed array subscripts other than 0, @ and *
(e.g., ${$var[2]}) and associative array subscripts other than @ and *
- It crashes when the variable name is a negative integer
But those problems might be fixable. I could try backporting and fixing
it for a future ksh 93u+m/1.1 release.
However, the functionality is redundant because namerefs already exist:
$ nameref foo=bar
$ bar=OK
$ echo $foo
OK
The new syntax would allow:
$ foo=bar
$ bar=OK
$ echo ${$foo}
OK
It takes just as many steps, so I don't really see the advantage.
Kaz Kylheku <864-117-4973@kylheku.com> writes:
Curious situation.[...]
Bash has a computed variable syntax. If there is a $word variable which
holds foo, then ${!word} will produce expansion $foo.
Something the manual doesn't directly address (or I've missed it) is
that a nameref can refer to a nameref, to arbitrarily many levels.
For example:
```
#!/bin/bash
declare -n var0=var1
declare -n var1=var2
declare -n var2=var3
declare -n var3=var4
declare -n var4=var5
var5=42
echo "var0=$var0"
echo "\${!var0}=${!var0}"
```
The output is:
```
var0=42
${!var0}=var5
Let's use points: everyone's favorite example for structures.
p1.x = 0
p1.y = 1
p2.x = 2
p2.y = 3
Now if we have a variable $(P) that holds a point like p1 or p2,
we can do $($(P).x) and $($(P).y) to read the "fields".
If symbols can be machine generated, then eval-ed assignments
can simulate real dynamic objects.
point=$(gensym) # point takes on value like __g0037
eval "${point}_x=42" # evaluates __g0037_x=0
echo ${${gensym}_x} # prints 42
Maybe if variable interpolations are allowed in variable names,
they should be allowed in assignments too (in the left hand
side) without eval, just:
${point}_x=42
[...]
Op 07-06-2023 om 19:39 schreef Javier:
BTW, does anybody know why the shell does not allow the nested
brace syntax ${${variable}} for indirect variable reference?
The abandoned 93v- beta of AT&T ksh93 (and hence also the derived and
equally abandoned AT&T ksh2020 project) supported a ${$variable} syntax
for indirection, though nested braces are a syntax error.
I've found multiple bugs in their implementation of it
The obvious question there is, how late is the binding?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:46:36 |
| Calls: | 9,812 |
| Calls today: | 14 |
| Files: | 13,754 |
| Messages: | 6,190,891 |