Commit Graph

3 Commits

Author SHA1 Message Date
ridiculousfish
eaecb817ca Retain leading spaces in non-expanding braces
This makes two changes:

1. Remove the 'brace_text_start' idea. The idea of 'brace_text_start' was
to prevent emitting `BRACE_SPACE` at the beginning or end of an item. But
we later strip these off anyways, so there is no apparent benefit. If we
are not doing brace expansion, this prevented emitting whitespace at the
beginning or end of an item, leading to #6564.

2. When performing brace expansion, only stomp the space character with
`BRACE_SPACE`; do not stomp newlines and tabs. This is because the fix in
came from a newline or tab literal, then we would have effectively
replaced a newline or tab with a space, so this is important for #6564 as
well. Moreover, it is not easy to place a literal newline or tab inside a
brace expansion, and users who do probably do not mean for it to be
stripped, so I believe this is a good change in general.

Fixes #6564
2020-02-04 12:34:34 -08:00
Fabian Homborg
967c1d51ee Only do brace expansion if they contain a variable or ","
Brace expansion with single words in it is quite useless - `HEAD@{0}`
expanding to `HEAD@0` breaks git.

So we complicate the rule slightly - if there is no variable expansion
or "," inside of braces, they are just treated as literal braces.

Note that this is technically backwards-incompatible, because

    echo foo{0}

will now print `foo{0}` instead of `foo0`. However that's a
technicality because the braces were literally useless in that case.

Our tests needed to be adjusted, but that's because they are meant to
exercise this in weird ways.

I don't believe this will break any code in practice.

Fixes #5869.
2019-05-19 18:23:27 +02:00
Mahmoud Al-Qudsi
1e5d7d98a8 Add tests for new parameter expansion features 2018-03-12 07:04:05 -05:00