ash: [PARSER] Report substition errors at expansion time
authorDenys Vlasenko <vda.linux@googlemail.com>
Tue, 25 Oct 2016 23:55:56 +0000 (01:55 +0200)
committerDenys Vlasenko <vda.linux@googlemail.com>
Tue, 25 Oct 2016 23:55:56 +0000 (01:55 +0200)
commit88e15703acdbfb182440cf35fdb8972fc4931dd2
treeabdeba10ffe2446c197bdb2d539fb1c4f3fb5277
parenteaf9436b08f68be8b96730307fe1da1faf374ee0
ash: [PARSER] Report substition errors at expansion time

Upstreams commit:

    Date: Mon, 8 Oct 2007 21:32:25 +0800
    [PARSER] Report substition errors at expansion time

    On Wed, Apr 11, 2007 at 01:24:21PM -0700, Micah Cowan wrote:
    > This operation fails on Ubuntu:
    >
    >     $ /bin/sh -c 'if false; then d="${foo/bar}"; fi'
    >     /bin/sh: Syntax error: Bad substitution
    >
    > When used with other POSIX shells it succeeds. While semantically the
    > variable reference ${foo/bar} is not valid, this is not a syntax error
    > according to POSIX, and since the variable assignment expression is
    > never invoked (because it's within an "if false") it should not be seen
    > as an error.
    >
    > I ran into this because after restarting my system I could no longer log
    > in. It turns out that the problem was (a) I had edited .gnomerc to
    > source my .bashrc file so that my environment would be set properly, and
    > (b) I had added some new code to my .bashrc WITHIN A CHECK FOR BASH!
    > that used bash's ${var/match/sub} feature. Even though this code was
    > within a "case $BASH_VERSION; in *[0-9]*) ... esac (so dash would never
    > execute it since that variable is not set), it still caused dash to
    > throw up.
    >
    > FYI, some relevant details from POSIX:
    >
    > Section 2.3, Token Recognition:
    >
    > 5. If the current character is an unquoted '$' or '`', the shell shall
    > identify the start of any candidates for parameter expansion ( Parameter
    > Expansion), command substitution ( Command Substitution), or arithmetic
    > expansion ( Arithmetic Expansion) from their introductory unquoted
    > character sequences: '$' or "${", "$(" or '`', and "$((", respectively.
    > The shell shall read sufficient input to determine the end of the unit
    > to be expanded (as explained in the cited sections).
    >
    > Section 2.6.2, Parameter Expansion:
    >
    > The format for parameter expansion is as follows:
    >
    >     ${expression}
    >
    > where expression consists of all characters until the matching '}'. Any
    > '}' escaped by a backslash or within a quoted string, and characters in
    > embedded arithmetic expansions, command substitutions, and variable
    > expansions, shall not be examined in determining the matching '}'.
    > [...]
    >
    > The parameter name or symbol can be enclosed in braces, which are
    > optional except for positional parameters with more than one digit or
    > when parameter is followed by a character that could be interpreted as
    > part of the name. The matching closing brace shall be determined by
    > counting brace levels, skipping over enclosed quoted strings, and
    > command substitutions.
    > ---
    > In addition to bash I've checked Solaris /bin/sh and ksh and they don't
    > report an error.
    >
    > -----
    > Micah Cowan:
    >
    > The applicable portion of POSIX is in XCU 2.10.1:
    >
    > "The WORD tokens shall have the word expansion rules applied to them
    > immediately before the associated command is executed, not at the time
    > the command is parsed."
    >
    > This seems fairly clear to me.

    This patch moves the error detection to expansion time.

    Test case:

     if false; then
     echo ${a!7}
     fi
     echo OK

    Old result:

dash: Syntax error: Bad substitution

    New result:

OK

function                                             old     new   delta
evalvar                                              574     585     +11
readtoken1                                          2763    2750     -13

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
shell/ash.c