Dear Maintainer,
bullseye bash as well as bullseye, sid, and git dash observe the following:
$ cat -n boment
1 echo "$(head -n1 <<EOF)"
2 # 2
3 # 3
$ sh boment
$ sh -x boment
+ head -n1
+ echo
$
POSIX Issue 7, XCU, 2. Shell Command Language says
2.7.4 Here-Document
The redirection operators "<<" and "<<-" both allow redirection of subsequent lines read by the shell to the input of a command. The redirected lines are known as a "here-document".
The here-document shall be treated as a single word that begins after the next <newline> and continues until there is a line containing only the delimiter and a <newline>, with no <blank> characters in between. Then the next here-document starts, if there is one. The format is as follows:
and its counterpart in Issue 8 Draft 3
80601 2.7.4 Here-Document
80602 The redirection operators "<<" and "<<-" both allow redirection of subsequent lines read by
80603 the shell to the input of a command. The redirected lines are known as a ``here-document’’.
80604 The here-document shall be treated as a single word that begins after the next NEWLINE token
80605 and continues until there is a line containing only the delimiter and a <newline>, with no
80606 <blank> characters in between. Then the next here-document starts, if there is one. For the
80607 purposes of locating this terminating line, the end of a command_string operand (see sh) shall be
80608 treated as a <newline> character, and the end of the commands string in $(commands) and
80609 `commands` may be treated as a <newline>. If the end of input is reached without finding the
80610 terminating line, the shell should, but need not, treat this as a redirection error. The format is as
80611 follows:
That is, as I understand it:
echo "$(head -n1 <<EOF
abc
def
EOF
)"
and
echo "$(head -n1 <<EOF)"
abc
def
EOF
are always required to work and Issue 8 allows shells to have
echo "$(head -n1 <<EOF
abc
def
EOF)"
work as well.
Either way, this looks to me like a POSIX violation.
Best,
наб