Chet Ramey <chet.ra...@case.edu> writes:
> On 5/10/25 11:18 AM, Sam James wrote:
>> Hi,
>> Since the following commit on devel
>> commit c3ca11424d2ae66cafa2f931b008dfb728e209a5
>> Author: Chet Ramey <chet.ra...@case.edu>
>> Date: Wed Feb 12 11:18:16 2025 -0500
>> fix issue with redirections to bash input file descriptor;
>> new minimal chmod builtin; posix mode change for kill builtin return
>> status; perform additional validation on brace expansion sequence
>> expressions
>
> The rationale for this change is to identify brace expansions that contain
> multiple expressions, some valid and some not. The examples added to the
> tests show what I mean:
>
> echo {{1,2,3}..{7,8,9}}
>
> Here the sequence expansion is invalid and shouldn't be evaluated as such,
> but the rest of the brace expansion is valid and should produce
>
> {1..7} {1..8} {1..9} {2..7} {2..8} {2..9} {3..7} {3..8} {3..9}
>
> Bash versions through bash-5.2 produced
>
> 1..7 1..8 1..9 2..7 2..8 2..9 3..7 3..8 3..9
>
> So the additional validation on sequence expressions means that they have
> to follow the documented rules for those expansions, which was a little
> lax before the change.
>
>> the following behaves differently:
>> $ echo {a,../a.cfg}
>> {a,../a.cfg} # with devel
>
> The problem here is that additional validation: the code always treated
> the `../a.cfg' as a potential sequence expression, but left it alone and
> just expanded the comma if it didn't qualify as valid. After the change,
> it still tries to treat that as a potential sequence expression, but now
> marks it as invalid, so the entire brace expansion fails.
>
> We can fix this particular issue by noting the comma and treating it as
> the separator, and not trying to treat the ../a.cfg as a sequence
> expression and validate it. This forces the comma to have higher
> precedence, which I think is the right thing and is still backwards
> compatible even with the additional validation.
>
>> Does this constitute a valid sequence expression? The documentation
>> implies that even if not, an unquoted comma may be fine.
>
> I think it is not.
Thank you for both the explanation and the workaround!
