On Mon, Jan 04, 2016 at 12:08:43PM -0800, NGie Cooper wrote:
> > It looks like a libc problem though, because I’ve run into this
> > issue with both /bin/sh and bash (my default login shell). I’m not
> > sure why this isn’t reproing on my VM (yet).

> > This doesn’t repro in universe10a.freebsd.org (another jail on the
> > same machine I think…).

> > It was working yesterday on ref11-amd64.freebsd.org before the
> > system was upgraded (it was running October sources), and wasn’t
> > working on universe11a.freebsd.org yesterday (it was running
> > December sources yesterday).

> delphij@ pointed me in the right direction (thanks :)..). Globbing
> expressions seems extremely broken with LANG set to en_US.UTF-8 [at
> least].

> $ echo $LANG
> en_US.UTF-8
> $ hostname
> universe11a.freebsd.org
> $ (unset LANG; cd sys/amd64/conf && echo [A-Z0-9]*[A-Z0-9])

Traditionally, ranges in bracket expressions like A-Z meant characters
that collate between A and Z, inclusive. Although this used to be in
POSIX and is widely implemented, it does not make much sense.
POSIX.1-2008 leaves ranges undefined in locales other than the POSIX

Therefore, it is an option to disable collation for ranges and just
compare character codes.

The problem started to occur more often with the new collation code,
which supports UTF-8 and uses CLDR's different collation order, but
strange results from [A-Z] can be encountered in much older versions.

Bash behaves similarly to sh, but supports 'shopt -s globasciiranges' to
disable collation. In some sense this is strange, an option that needs
to be enabled to provide the behaviour most people expect.

Alternatively, the pattern could be rewritten to be locale-sensitive:

Jilles Tjoelker
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to