[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#333953: bash: LC_COLLATE ignores nocaseglob in some locales



Hi,

On Tue, 02.11.2010 at 19:54:40 -0500, Jonathan Nieder <jrnieder@gmail.com> wrote:
> # this is how fnmatch() is documented to work

you can document all you want, including that 'ls' is suddenly meant to
behave like 'rm -f', but that doesn't make it any better.

> The relevant detail is that what [a-z] matches depends on the
> collation order.  This gives globs like [??-??] a more useful
> (locale-specific) meaning than the C.UTF-8 collation order would
> dictate, with the unfortunate side-effect of giving [a-z]
> counterintuitive behavior with respect to case folding[1].

I must admit that I am not sure that I completely understood your
opengroup references, but would like to point out that programmers and
systems administrators may have quite different requirements than "end
users", which these Posix documents are clearly aimed at, and that
these people are also most likely constitute the majority of bash
users. End users are expected to use a GUI these days, where their
nautilus, konqueror and what-have-you can sort files all the way *they*
want.

I just verified that dash does *NOT* ignore case like bash does. IOW,
scripts intended to run on both bash and dash may behave differently,
depending on which shell they are actually run by. This should hold for
a large part of system scripts in Debian.

I therefore request that the options nocaseglob and nocasematch are
made to work as primarily documented, ie, without any hidden gotchas.
Ie, these options should override, not be overridden by, the effects of
LC_*.

> Toni Mueller wrote:
> > Upping the severity due to possible negative impact (I've been bitten
> > several times, too), semi-hidden documentation,
> 
> A separate bug report suggesting how to improve the documentation
> would be welcome.

I'd rather have the behaviour return to a sane state, than having this
idiocy documented any better, although attaching big flashing warning
signs to these options and stating any workaround might be a first
step to prevent people from getting snared.

> Hope that helps,

Not really.

> [1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_01
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03_05
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;bug=570929

-- 
Kind regards,
--Toni++




Reply to: