Hide Forgot
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. Example: (assume "set list" mode so trailing blanks are visible) program <<-EOF $ fnord $ fnord $ EOF $ $ other-program $ ...will echo: fnord fnord EOF other-program bash should ignore trailing spaces completely when checking the delimiters.
POSIX demands this behavior, so it's not a bug.
{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 http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_007_004 "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: <<[-]word here-document delimiter ...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 " or command << fnord\ \ \ \ but it's not.
Oops. Rereading what I quoted makes the behavior correct. Don't I feel dumb.