[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reportting a BUG in Heredoc
From: |
Kerin Millar |
Subject: |
Re: Reportting a BUG in Heredoc |
Date: |
Wed, 26 Oct 2022 09:43:47 +0100 |
On Wed, 26 Oct 2022 11:03:57 +0700
Robert Elz <kre@munnari.OZ.AU> wrote:
> 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.
So they do. Somehow, I missed that upon my reading.
> 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.
Yes, it could. While not unwelcome, the present warning came across as
confusing because it expressed the would-be delimiter verbatim, newline and
all. It purports to "want" something that cannnot susbequently be detected.
>
> 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.
Indeed. Thanks for the clarification.
--
Kerin Millar