Linda Walsh wrote: > Chet Ramey wrote: > >http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html > >...Campaign For Rational Range Interpretation... > > The next version of bash will have a shell option to enable this > behavior. It's in the development snapshots if anyone wants to try > it out now.
> The above relies upon a hack to the algorithm -- use *USEFUL* hack > in most cases, but still a hack. Why do you think it is a hack? Because it isn't in libc? I might agree with that. But if it isn't in libc then in the application is the only reasonable alternative. > Note...before bash broke UTF-8 compatiblity, I could use > en_US.UTF-8, but now I assert the current need to do the above > is a bug. This has been discussed a very great many times in a very great many places and you have been part of that discussion many times. Please don't rehash all of that discussion again. It isn't useful or productive. > I will make no claim about en_US.iso88591 or other locale-specific > charsets. However, UTF-8 defines collation order the same as ASCII in > the bottom 127 chars. No it doesn't. That is the root of the problem. > Bash ignores UTF-8's collation order. No it doesn't. It is using the system libc code which is obeying the locale collation ordering. Since that misconception is the basis of your complaint and that basis is false it isn't useful for more chatter about more details of it. > For some reason, I am not allowed to use LC_COLLATE=UTF-8: > -bash: warning: setlocale: LC_COLLATE: cannot change locale (UTF-8): > No such file or directory You are not allowed to use it because your system does not provide such a file. If it did then you would. You might argue that the error message in that case could be more friendly. That would be a bash specific discussion and perhaps even a useful one. See 'man 3 setlocale' for more details. On my system locale files are stored down /usr/share/locale/* paths. Bob
