Re: Reportting a BUG in Heredoc

[Robert Elz]

There is no bash bug here, though it could perhaps be a little
kinder to users who make this simple mistake.

The rules for heredocs say that the end delimiter is a line.
A line cannot contain an embedded newline - then it would be
two lines.

The here doc end delimiter given after the << redirect operator
is just a shell word.  Those can contain embedded newlines, either
by having an unbalanced number of unquoted single or double quote
characters, or by using $'\n' to create one.

If the user gives such a heredoc delim after the << they have put
themselves in a situation where it is impossible to ever end
the here doc.  That is until the input stream ends (EOF).

bash could issue a warning when this occurs, rather than just
the one new versions issue when EOF is reached without the end
delimiter being located (which can happen for other reasons as well
of course).  It has chosen not to.

Shells are allowed to extend the standard - bash has many of those
extensions.  Other shells do various things when encountering a
here doc delimiter with an embedded \n - one is to look for a multi
line delimiter to end the here doc, the shell could also simply
truncate the expected end delim at the first embedded newline.
Or treat this as a syntax error.  Or almost anything else.  In this
case bash has chosen not to extend the standard at all - if the user
gives an end delim it is impossible to find, bash just looks for it
anyway.

If the intent is to duplicate bash exactly (which I would not
recommend, some of what bash does is historical, and has little
tporecommend it) then this would be something that would have to
be copied.  Doing so is pointless however, no real scripts, as
distinct from test cases, are going to be using a here doc
delim with embedded newlines, so this would be a case to do better.

kre