Re: square bracket vs. curly brace character ranges

[Bob Proulx]

Marcel Giannelia wrote:
> But the other day I was on a fresh install (hadn't set
> LC_COLLATE=C yet, so I was in en_US.UTF-8), and this happened:
> 
> $ ls
> a  A  b  B  c  C

> $ ls {a..c}
> a  b  c

The above has nothing to do with file glob expansion.  Using 'ls'
there I think confuses the discussion.  You can see the same result
with 'echo' and avoid the confusing use of ls like this:

  $ echo {a..c}
  a  b  c

> $ ls [a-c]
> a  A  b  B  c

The expression [a-c] is really like saying [aAbBc] in your active
locale.  Using locale based character ranges outside of the C locale
is problematic and I always avoid them.

This result is due to the matching of file globs against files in the
directory.  If you were to remove files for example you would see
fewer matches.  (I am sure you already knew that but I wanted to say
it explicitly.  Since using ls in that context adds confusion.)

> Curly brace range expressions behave differently from square-bracket
> ranges. Is this intentional?

Yes.  Because bracket expansion is a file glob expansion and dependent
upon the locale.  Brace expansion is a bash extension and can do what
it wants.  (I am going to get in trouble for saying it that way,
because it isn't really correct, and I expect at least three
corrections. <grin>)

> The sheer number of threads we've got complaining about
> locale-dependent [a-c] suggests to me that the software should be
> changed to just do what people expect, especially since nothing is
> really lost by doing so.

I know that some projects are doing just that.  I don't know the plans
for bash.  I would like to see it addressed in libc so that it would
be uniform across all projects.  But that isn't likely to happen.  But
if libc isn't going to do it then it is beneficial if projects do it
themselves outside of libc.  Eventually in the future when libc
addresses the problem then those hacks can be removed.

Bob