stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: svn commit: r628839 - /stdcxx/trunk/tests/self/0.braceexp.cpp
Date Fri, 22 Feb 2008 00:24:45 GMT
 

>Mark Brown wrote:
>
>On 2/19/08, Martin Sebor <sebor@roguewave.com> wrote:
>>Travis Vitek wrote:
>>> sebor-2 wrote:
>>>> +    // weirdly-formed brace expansions -- fixed in post-bash-3.1
>>>> +    TEST ("a-{b{d,e}}-c",    "a-{bd}-c a-{be}-c");
>>>>
>>>
>>> I don't understand how this could be interpreted as valid 
>>> brace expansion at all. The body of the expansion is '{b{d,e}}'.
>>> Paragraph 5 [and paragraph 1 for that matter] require a
>>> correctly-formed brace expansion have unquoted [unescaped?]
>>> opening and closing braces, and at least one unquoted comma or
>>> a valid sequence expression. The body does not meet either of
>>> these requirements, so it must be invalid.
>>>
>
>The C-Shell that had brace expansion long before Bash did outputs
>a-bd-c a-be-c as Martin expects. It doesn't require a comma at all.

Yes, but "a-bd-c a-be-c" is very different from "a-{bd}-c a-{be}-c",
which the test expects.

Many of the shells implement brace expansion in one way or another. One
problem that I see with bash is that the documentation appears to be out
of date or incomplete. The man pages [and the reference manual]
explicitly say...

    A correctly-formed brace expansion must contain unquoted opening
    and closing braces, and at least one unquoted comma or a valid
    sequence expression. Any incorrectly formed brace expansion is
    left unchanged.

The above example clearly violates the behavior that one would expect
after reading the documentation.

Not only that, but the bash behavior is inconsistent with similar
testcases. Here is the output of a few common shells...

    [csh-6.13.00]$ echo a-{b}-c
    a-b-c
    [csh-6.13.00]$ echo a-{b{d,e}}-c
    a-bd-c a-be-c

    [ksh-5.2.14]$ echo a-{b}-c
    a-{b}-c
    [ksh-5.2.14]$ echo a-{b{d,e}}-c
    a-{b{d,e}}-c

    [bash-3.00.15]$ echo a-{b}-c
    a-{b}-c
    [bash-3.00.15]$ echo a-{b{d,e}}-c
    a-bd-c a-be-c

The csh shell consistently expands the contents of the brace list
regardless of the number of subexpressions in the list, and the ksh
shell consistently rejects brace lists that don't have more than one
element. Finally, the bash shell swings both ways, and newer versions of
bash have even weirder behavior as they appear to expand the nested
subexpression, and leave the outer braces in place for one reason or
another.

I'm honestly leaning toward implementing the behavior of either csh or
ksh, and adding support for bash style sequences.

The problem isn't that I can't implement one or the other. Well,
honestly I'd like to avoid implementing the bash 3.2 behavior at all,
but that is another issue. The problem is that our measuring stick
[bash] is inconsistent, and it appears to be changing with every
version.

Travis

Mime
View raw message