[Top][All Lists]

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]