Bug 25422 - here documents confused by trailing spaces
here documents confused by trailing spaces
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-01-31 16:36 EST by John Hardin
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-01 13:45:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Hardin 2001-01-31 16:36:58 EST
If a here document is defined with spaces after the delimiter names, and
the number of spaces don't match, the processing of the here document is
incorrect: bash will ignore the terminating delimiter completely.


(assume "set list" mode so trailing blanks are visible)

   program <<-EOF     $
        fnord         $
        fnord         $
   EOF                $
   other-program      $

...will echo:



bash should ignore trailing spaces completely when checking the delimiters.
Comment 1 Bernhard Rosenkraenzer 2001-02-01 11:09:39 EST
POSIX demands this behavior, so it's not a bug.
Comment 2 John Hardin 2001-02-01 13:45:12 EST
{boggle} You've *got* to be kidding...

Unfortunately I'm not an IEEE member or subscriber, so I can't reference the
posix 1003.2 standards document directly.

However, quoting from

"The here-document is treated as a single word that begins after the next
newline character and continues until there is a line containing only the
delimiter, _with no trailing blank characters._" (my emphasis added)

Granted, that may be a quote from an implementation-dependent feature, but given
the documentation for here-document redirection everywhere I've seen it:


...since when has a token ("word" is "a token that is not an operator") *ever*
included whitespace *unless it was explicitly quoted*? It's not treated that way
elsewhere, is it?

I could see the objection if the script was:

   command << "fnord   "


   command << fnord\ \ \ \ 

but it's not.

Comment 3 John Hardin 2001-02-01 13:56:34 EST
Oops. Rereading what I quoted makes the behavior correct. Don't I feel dumb.

Note You need to log in before you can comment on or make changes to this bug.