On 08/26/2014 06:15 AM, Oleg Bulatov wrote:
> Hi!
> 
> While playing with sh generators I found that dash and bash have different
> interpretations for <slash><newline> sequence.
> 
> $ dash -c 'EDIT=xxx; echo $EDIT\
>> OR'
> xxxOR

Buggy.

> $ bash -c 'EDIT=xxx; echo $EDIT\
> OR'
> /usr/bin/vim

Correct behavior.

> 
> $ dash -c 'echo "$\
> (pwd)"'
> $(pwd)
> 
> Is it undefined behaviour in POSIX?

No, it's well-defined, and dash is buggy.  POSIX says:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03

"the shell shall break its input into tokens by applying the first
applicable rule below to the next character in its input"

Rule 4 covers backslash handling, while rule 5 covers locating the end
of a word to be subject to $ expansion.  Therefore, rule 4 should happen
first.  Rule 4 defers to the section on quoting, with the caveat that
<newline> joining is the only substitution that happens immediately as
part of the parsing:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02

"If a <newline> follows the <backslash>, the shell shall interpret this
as line continuation. The <backslash> and <newline> shall be removed
before splitting the input into tokens. Since the escaped <newline> is
removed entirely from the input and is not replaced by any white space,
it cannot serve as a token separator."

So the fact that dash is treating the elided backslash-newline as a
token separator, and parsing your input as if ${EDIT}OR instead of
${EDITOR} is a bug in dash.

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