On 02/23/2016 03:49 PM, Eric Blake wrote:
> [adding the Austin Group]
> 
> On 02/23/2016 03:07 PM, Oleg Bulatov wrote:
>> Hello,
>>
>> trying to minimize a shell code I found an unobvious moment with heredocs and subshells.
> 
> Thanks for a cool testcase.
> 
>>
>> Is it specified by POSIX how next code should be parsed? dash output for this code differs from bash and zsh.
> 
> XCU 2.3 says:
> 
> When an io_here token has been recognized by the grammar (see Shell
> Grammar), one or more of the subsequent lines immediately following the
> next NEWLINE token form the body of one or more here-documents and shall
> be parsed according to the rules of Here-Document.
> 
> and 2.7.4 says:
> 
> The here-document shall be treated as a single word that begins after
> the next <newline> and continues until there is a line containing only
> the delimiter and a <newline>, with no <blank> characters in between.
> Then the next here-document starts, if there is one.
> 
> but with no mention of what happens if you somehow manage to make the
> next <newline> be part of an incomplete shell word on the line
> containing the here-doc operator.

As it is, all shells I tested have a shorter test case that proves they
don't always start looking for the heredoc body after the first newline:

$ dash -c 'cat <<ONE && cat \''
<<TWO
a
ONE
b
TWO
'
a
b

The newline immediately after the backslash is NOT used to start the
first heredoc.

> Maybe we need a defect against the standard that says behavior is
> unspecified if the next <newline> after a here-doc operator occurs in
> the middle of a shell word.

Or maybe refine the wording to state the first unescaped newline, since
backslash escaping seems to consistently work (and only newlines inside
incomplete command substitution is where the confusion begins).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org