Only the explicit assignment preceding the command_word is evaluated in the
new context, and uses the value from the caller's context temporarily. The
expansions all occur in, and assignments affect, the caller's context
first. So I agree VAR should stay an empty string or unset, but M, N, and Q
getting set to bla is the conforming behavior, and this is what the most
common result reflects. This is one of the reasons, afaik, that redirect
evaluation can be swapped with assignment evaluation in XCU 2.9.1, because
actual
value assignment may need to be deferred to the new context after
expansions related to the redirects are evaluated in the caller's context.
If you add $VAR before the '>', it should put bla bla into JUNK-bla, not a
single bla; if you want to check which value the first echo sees.
In a message dated 7/24/2017 1:51:37 P.M. Eastern Daylight Time,
[email protected] writes:
Given the following command sequence ...
VAR=${M=bla} /bin/echo ${N=bla} > /tmp/JUNK-${Q=bla}
echo $M:$N:$VAR:$Q
what is the "echo" on the 2nd line supposed to print?
It is clear (I think) that expanding VAR='' and N=bla is correct there,
and all shells I tested did that,
Beyond that, little consistency - there was a clear winning result,, but
not one that is in accordance with the way I read the spec.
The NetBSD sh (the one I work on) is in that group - I have long had an
item on my todo list to fix this, as I consider us to be broken there.
>From my reading of the spec, what I expect the output is intended to be
is
:bla::
Of the shells I tested, only zsh managed that (zsh with no options, other
than zsh -c '...'). That would make zsh (based just on this one test)
the only possible candidate (among the shells I tested) as being posix
conformant!
The most common result is
bla:bla::bla
which is at least consistent, but to me incorrect, I believe from reading
the spec, that the var-assigns and redirects are supposed to be evaluated
in the context of the command about to be executed, which would mean that
the side-effects from evaluating them would not be visible in the parent
shell (which later runs the 2nd command - at least not when, as in this
case, the command is clearly not a builtin utility or function.)
The result
bla:bla::
was also observed, which looks closer to correct, but inconsistent, I
cannot
find any way to read the spec in which that can be the result.
I appreciate that this kind of thing is not common (which is why it is
just an entry on my todo list, not even elevated to the status of being
a current project to consider - just something for the future when I run
out of more useful things to do) but we should really know what should
happen in cases like this.
kre
