On 2026-06-12, Frank Winkler <
usenet@f.winkler-ka.de> wrote:
Hi there !
I'm playing with the following in an interactive bash as well as in a
ksh script:
$ n=1
$ x1=" ok "
$ x2=" not ok "
$ eval echo \$x$n
ok
$ eval echo "\$x$n"
ok
$ n=2
$ eval echo "\$x$n"
not ok
$
So the variable var name seems to work but why are the blanks "deleted" here? I also tried some variants with "printf", but also with no success.
eval takes all of its arguments, and catenates them together as if by
spaces. The resulting string is a piece of shell syntax that is
lexically scanned and otherwise processed entirely from scratch, almost
as if the shell were reading input from the command line or a script
file.
First your arguments undergo substitutions, producing the arguments
for eval, like this:
echo \$x$n -> echo $x1
echo "\$x$n" -> echo $x2 # n was reassigned to 2
As you can see, the quoting disappears at this stage before eval
sees it! In both cases, eval sees the two pieces {echo} and {$x}.
These are turned into the syntax {echo $x}. This syntax is then
evaluated. Note that it has no quoting that would preserve
the blanks in the value of $x.
Note how you carefully preserved the dollar sign with a backslash
so that it is not swallowed by the first round of expansions.
You ensured that eval sees the dollar sign in $x1 and $x2.
In exactly the same manner, you must insert quoting in such a
way that it is preserved, for instance like this:
eval echo \"\$x$n\"
Now our first round of expansion, before eval is called
goes like this:
echo \"\$x$n\" -> echo "$x1"
That is the correct syntax for echoing x1 with the spaces preserved.
Just out of curiosity, I tried this:
$ IFS="" eval echo ".\$x$n."
. not ok .
$
To my surprise, it works but why is IFS relevant here? And to my even
IFS="" does not kick in until eval executes. The syntax that is produced
is
echo .$x2.
With the default IFS, that would be subject to field spltting,
producing the four fields {.}{not}{ok}{.} which become separate
arguments of echo.
You've overriden IFS over the execution of eval, suppressing that field splitting, so the expansion of .$x2. is taken as-is, a single argument, containing spaces.
The value of IFS is relevant to the eval, because eval performs complete processing of the syntax from scratch, including another round of
parameter expansion that takes place before echo is called. (Of course:
without that expansion we would not get the $x2 interpolation).
IFS speaks to the semantics of that parameter expansion.
bigger surprise, it looks like everything seems to behave as expected in
the bash session but in the ksh script, IFS is not just changed for this single command but globally - so I had to save and restore it to prevent
the whole script from exploding.
You've run into a quirk of the VAR=value ... command ... syntax.
When you use that with an external command, like "CFLAGS=-O2 make",
it creates an environment binding over just that command. This is
a widely used, standardized feature that works "everywhere".
However, when VAR=value it is used on built-in commands, there are
pitfalls. It depends on which exact built-in command and what shell.
What the POSIX standard requires in regard to assignments in a command
can be found here:
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html
in section "2.9.1.2 Variable Assignments".
As you can see, even in the case when the command is not a built-in
or function, there are some unspecified behaviors!
It is also written that "If the command name is a special built-in
utility, variable assignments shall affect the current execution
environment before the utility is executed and remain in effect when the command completes". So in fact ksh is conforming, even though it
is arguably a dumb behavior that Bash disagrees with (even in --posix
mode; just tested with 4.4 and 5.1).
--
TXR Programming Language:
http://nongnu.org/txr
Cygnal: Cygwin Native Application Library:
http://kylheku.com/cygnal
Mastodon: @
Kazinator@mstdn.ca