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
Attachment:
signature.asc
Description: OpenPGP digital signature
