dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Oleg Bulatov <oleg@bulatov.me>, dash@vger.kernel.org
Subject: Re: Line continuation and variables
Date: Tue, 26 Aug 2014 06:34:42 -0600	[thread overview]
Message-ID: <53FC7EE2.7000309@redhat.com> (raw)
In-Reply-To: <1554581409055304@web13g.yandex.ru>

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

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


> $ 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:


"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:


"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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

  reply	other threads:[~2014-08-26 12:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26 12:15 Line continuation and variables Oleg Bulatov
2014-08-26 12:34 ` Eric Blake [this message]
2014-09-29 14:55   ` Herbert Xu
2014-09-29 14:57     ` Herbert Xu
2014-10-29 21:52     ` Jilles Tjoelker
2014-10-30  2:10       ` Herbert Xu
2015-01-05 12:00       ` [0/4] input: Allow two consecutive calls to pungetc Herbert Xu
2015-01-05 12:01         ` [PATCH 1/4] input: Make preadbuffer static Herbert Xu
2015-01-05 12:01         ` [PATCH 2/4] input: Remove HETIO Herbert Xu
2015-01-05 12:01         ` [PATCH 3/4] input: Move all input state into parsefile Herbert Xu
2015-01-05 12:01         ` [PATCH 4/4] input: Allow two consecutive calls to pungetc Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FC7EE2.7000309@redhat.com \
    --to=eblake@redhat.com \
    --cc=dash@vger.kernel.org \
    --cc=oleg@bulatov.me \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).