Date: Sat, 15 Mar 2025 19:42:54 +0000
From: Nikola Novak via Bug reports for the GNU Bourne Again SHell
<bug-bash@gnu.org>
Message-ID:
<wwypcx2pNs4qBYaa-kztdAc3A3IPRoyfATS8MSoj3jKz3L-BeBQ96dQ52m2cSpL3BOIRzw18KRqWt6lmWVslUnADzNfFNexb6jLCk_QonYI=@proton.me>
| OK, thank you!
| It's a relief, actually, to hear that. :)
The reason for this is that POSIX says (XCU 2.7.4):
The here-document shall be treated as a single word that begins
after the next NEWLINE token and continues until there is a line
containing only the delimiter and a <newline>,
and the definition of "line" (from XBD 3.185) is:
A sequence of zero or more non-<newline> characters plus a
terminating <newline> character.
Since the line cannot contain a \n and the reading the here-doc text
continues until there is a line containing (only) the delimiter, logically
a delimiter containing a \n will never be located (it is not however a
syntax error, unless the shell decides to treat non-terminated here-docs
as an error, which it is encouraged to do, but not required).
FWIW, the NetBSD shell, as an extension, allows this to work, the code
to handle multi-line end delimiters isn't all that hard (not hard at
all really).
kre
