Date: Sun, 6 Feb 2022 11:14:05 +0000 (UTC)
From: Thorsten Glaser <[email protected]>
Message-ID: <[email protected]>
| Should that even work?!
Yes. The word after a << redirect is of exactly the same syntax
as the word after any other redirect ooerator.
You can write
cat < $( ls -t *.c | sed 1q)
so you can also write
cat << $( ls -t *.c | sed 1q)
As far as what the syntax permits, those are both a word, a redir
operator, and another word.
The semantics when they are evaluated are completely different
(just as they would be if the redir op was <& .. a third
interpretation of the same syntax).
ash derived shells all parse all of this correctly, but we don't
save the literal text, a word like the one above turns into a
*very* short string which encodes the notion "command substitution
results go here", along with a pointer to a (list of, there can be
more than one in a word) command substitution parse tree(s).
That is useless as a here doc end word, and it is impossible
go back from the parse tree to the text ... just how many
spaces surrounded that pipe symbol? That's irrelevant to the
parse results, but vital for the end word. So if the word is
to be used as as here doc delimiter word, and contains any kind of
expansion, we just forbid it.
I am currently seeing if it is feasible to correct that in the
NetBSD sh, by saving the literal text while parsing a word if
it follows a here-doc redir operator, which I believe is the only
time it actually matters - but explains why the standard is written
to suggest that the actual text in all words (quotes included,
just not \newline combos when those get dropped) must be saved.
But I need to know the correct interpretation of these weird cases
in order to do that properly. Since quote removal, and "was it
quoted?" are the only semantic operations that are apply to this
word, those areas are where the questions apply.
(mksh is one of the shells in which it doesn't,
You are not alone, bash, zsh, and yash are the only shells I
know of that get it right, and (Chet can correct me if I get
this bit not quite correct) bash is planning to break this in
the next release (in some cases) in order to get posix conformance
in more important areas. ksh93 handles some of it, but is very
badly broken in other parts. No idea about ksh88.
| and I'm hard-pressed to see why scripts should even be
| allowed to write constructs like that.)
They are definitely allowed, what saves all of us is that no-one
ever writes this, and if anyone ever attempted it, they'd probably be
hoping that the end-word on the here-doc redirect would be expanded
the same way it is fir all other redirects (which definitely does
not happen).
kre
