Re: strange glob parsing

[Ryan Rotter <rrotter@xxxxxx>]

Thanks (to everyone on the thread), this makes sense now. The reference discussion on the 35131 thread really helped me make sense of this. TIL.

> On 3. Jun 2025, at 00:14, dana <dana@xxxxxxx> wrote:
> 
> On Mon 2 Jun 2025, at 22:19, Lawrence Velázquez wrote:
>> It's not what I expect.  I believe that POSIX requires the synonymous
>> "[!]" to match a literal '[' followed by a literal '!' followed by
>> a literal ']', and bash, dash, and ksh perform matching this way.
> 
> i agree that it's unexpected but not sure about the rest? posix isn't
> very explicit but it implies (in 9.3.5) that the body of the bracket
> expression (the ... in [...] or [^...]) can't be empty. all the regex
> engines i tested treat both [] and [^] as erroneous so that seems to be
> the case
> 
> linux glob(7) is clearer:
> 
>> The string enclosed by the brackets cannot be empty
> 
> and the context implies that that extends to [!...]
> 
> afaict bash treats both [] and [^] as never-matching, which is in
> accordance with that
> 
> On Mon 2 Jun 2025, at 22:19, Lawrence Velázquez wrote:
>> These are expected.  In each of "[]...]", "[!]...]", and "[^]...]",
>> the leading ']' represents itself in the list of candidate characters
>> and doesn't preemptively terminate the bracket expression.
> 
> also agreed that this case is behaving as expected, consistently with
> posix and with other implementations
> 
> the [^] case is the one that's arguably unexpected. that's due to
> workers/35131. i'm not sure whether that specific behaviour with '^' was
> intended or not. i suppose if [] matches nothing it makes a certain
> sense for [^] to match everything, but as mentioned bash works in a
> different way which is also logical and more consistent with regex
> 
> dana