And another one in a similar vein, where the 3 ("working" ??) implementations
all do different things...
cat <<$(echo "foo")
$X
$(echo "foo")
What's expected there?
In this example, there are literal double quote characters, but according
to the "how to parse" theory part of the standard, those ones are just
characters at this point, they only become quoting chars when the command
substitution is evaluated (they count as quoting chars while the recursive
parse is done to locate the terminating ')' - but according to the specified
way to handle this, once that ')' is located, that parse is discarded, and
the chars from $( up to (and including) that ')' are simply included in the
word unaltered, and are parsed again when (if) evaluated.
Does the existence of those quote chars mean that the here doc end word is
quoted, or not?
Here, zsh says "no" (which I believe is most in line with the theory of
how words containing command substitutions are intended to be parsed.
It dutifully outputs 3 (the value of X, which is unchanged from the
example in the previous mail) when given this input.
yash on the other hand decides that those quote chars are quotes, removes
them as part of quote removal, so the end word it seeks is actually
$(echo foo)
(the quotes having been removed), and then outputs $X the here doc not
being expanded in this case, as the end word was (partly) quoted.
Either of those is reasonable, it all depends upon the answer to the
question "is it quoted?"
bash (the current released version) on the other hand does quote removal
on the "foo", so it also wants
$(echo foo)
as the terminating line of the here doc text. But then it doesn't treat
that as having been a quoted end word, and expands the here doc text,
producing '3' as the output (like zsh). That looks like a foot in each
camp to me, and whatever is the answer to the "is it quoted?" question,
this cannot be a correct implementation.
ksh93 for this (the version I test against anyway) is simply broken when
it sees what looks like an unquoted command substitution containing spaces
in a here doc redirection operator end word...
ksh93 $ cat <<$(echo "foo")
/usr/pkg/bin/ksh93: syntax error at line 1: `<<foo' here-document not contained
within command substitution
It does look like it has done quote removal though, but almost anything
is possible there (and no, it is not that it evaluated the command substitution
and produced "foo" from the echo command, which in this case it looks as
if it might be, but:
ksh93 $ cat <<$(a "foo")
/usr/pkg/bin/ksh93: syntax error at line 1: `<<foo' here-document not contained
within command substitution
ksh93 $ a
/usr/pkg/bin/ksh93: a: not found [No such file or directory]
ksh93 $
The "a: not found" is correct, there is no such command. I included
that just to show that it doesn't matter what the command substitution
command happens to be, it is the space and what comes after that breaks things.
Anyway, what is the consensus on this one, is this a quoted end word, or not?
If it is, one would assume that removing the quotes by quote removal
is correct when forming the end word.
Here I hope the answer is "no" - as making that work would add huge amounts
of complexity to the implementation I am attempting (which will effectively
do just what the standard seems to require, and save all the chars in the
word, unaltered, then remove any actual quote chars (which means, chars that
are being used to (potentially) quote something in the current context, not
just a char with ascii code 0x22 etc). In reality they'll be removed
while collecting the word - since the word is never used as anything other
than text, they accomplish nothing, but need to be removed eventually, so
just remove them when they are first seen, and no need to scan again).
kre
