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
