Hi, On Thu, 5 Jan 2023, at 21:32, наб wrote: > (I built 0.5.12-2 from the .dsc, > the binary packages don't appear to have propagated yet. > I also originally wrote this without knowing that glob > classes are negated by !, not ^. > s/correct/compatible/ and s/broken/incompatible/, i guess)
Thanks for the report. > Ruh-roh!!! That's /horrific/. > In my original reproducer that test is for checking the input > is an integer, this is a common pattern. > > This smells an awful lot like it'd affect all globs, right? > Yeah. <...> > Bisecting over the upstream git, I got > commit 8f9cca055bc661c4c690a5f5e1ca71370d129bc3 (HEAD, refs/bisect/bad) > Author: Herbert Xu <[email protected]> > Date: Wed Jan 19 16:37:54 2022 +1100 > > expand: Always quote caret when using fnmatch > as the first bad commit with default configuration (HAVE_FNMATCH=1). > > I /cannot/ find a set-up where configuring like Debian > (--disable-fnmatch --disable-lineno --disable-glob) > isn't broken. I’m not sure why this also affects configurations with --disable-fnmatch — from the description of it, it shouldn’t? > Y'know what, I bisected the Salsa git, too, but then I consulted POSIX. > Apparently, this is fine. > Please for the love of god add this to the NEWS. > I /guarantee/ people are using '[^0-9]' to mean "not 0-9", > and similar constructs, even if they are well-versed in the shell language. > > This is a breaking change going from bullseye, and quite an insidious one. > I assume my reaction is gonna mirror others' quite well. > > /Please/ add this to the NEWS. I’m actually considering reverting that patch, as it seems a bit too late in the release cycle to introduce such a breaking change. -- Cheers, Andrej
