Kaixo! On Mon, Jan 21, 2002 at 11:52:23PM +0100, Bram Moolenaar wrote: > > To use the command line you must be able to read a doc and to copy correctly > > what it said; you are also supposed to know the command line is case > > sensitive. > > Strange way to put it. You mean that command names are case sensitive.
Of course they are. > > But it's also the way things are done sice ever (or at least as long as > > I can look at); why to break it and introduce compatibility problems ? > > Ignoring case does not appear to lead to compatibility problems. It does. > I can't think of an example of two existing locales that only differ by > case. Not because of that, but because in various places the handling is case sensitive; so if case insensitivness is introduced in some places, and a wrong case used, it will work in some palces, and not in some others. Or do you plan to also patch X11 so it is case insensitive too? > > Note that case insensitivity is locale dependent; by introducing case > > insensitivity you may have some very strange behaviours, like > > the locale being recognized when you first define it (as you were on another > > locale previously), then after the change is done you start getting errors > > (as the new locale defines new case insensitivity rules and the string that > > previously was considered the same is not anylonger the same). > > Locale names are always in ASCII and thus are indifferent to the current > locale. You are wrong. uppercase(i) will give different results in English or Turkish locale. same for lowercase(I). Maybe those are the only two cases involving ascii letters; but that also mean that if the name of a Turkish locale includes an 'i' the result may be that it won't work as expected. > That's part of the proposed standard and it would be hard to > imagine how it would work if it didn't, also when case matters. When case matters the case is not changed; so the toupper or tolower could be as bizarre as you want it wouldn't havce any effect, as those transformations are not called. > > Also, remmeber the filesystem is still case sensitive; which means that > > if you introduce case insensitivness for locales naming in variables, you > > need to change the sources of the libc or other sensitive libraries in > > order to have the files where locale data is stored found even if what the > > user request is a different name than the one of the actual directories... > > This is only a small change. Small yes, but not "a change", but "several changes in several places". There is at least the glibc, the X11 library, the directories where X11 ressource files are stored, probably also the KDE locale data handling, and maybe also some other programs (like the ones not using gettext but their own translation systems (other than X11 ressources, told above)) >> The supposed benefits are too small compared to the troubles. > > I think you underestimate the importance of user friendliness. case sensitivness in one small place when everything else is case sensitive is not user friendly; to the contrary: it can only give more trouble. Now the situation is simple: everything is case sensitive. But you want to have a system where commands, file namese and variable names are case sensitive, but the value of some variables are case insensitive... Note also that the common locale related problems are not due to case sensitivity, but to things like using unknown names, typos, bad charset encodings, locale not defined,... case insensitivity won't help if you define LANG=a and "a" don't exist; it won't help either for people mixing country name and language name and asking for LANG=cz instead of LANG=cs, nor will it help for people defining LANG=fr_FR.iso_8859_1 (the problem here is not the case, but the use of '_' instead of '-', a common error as a quite old French Howto gives it that way (as it used to be in libc4 time)). > This is > not unusual when you look at Linux from the point of view of a > developer. Please try looking at it from the point of view of a user, > and attempt to make the system as user friendly as you can! I simply don't think making the value of an extremely small set of shell variables case insensitive will do any real change in user frinedliness. The contents of almost all other variables will remain case sensitive ($HOSTNAME is the only one I can think of that is already case insensitive, well, not exactly, but the case has no effect for host names); the variable names will of course remain case sensitive, and everything related to filesystem. If the user happens to do a bit of programing, there is case sensitivity all the place too, etc. The gains of having case insensitive locale naming are in practice very small; and it may even introduce bugs and problems for Turkish users (they already have too often problems due to the peculiar case changing rules for dot and dotless i's). -- Ki �a vos v�ye b�n, Pablo Saratxaga http://www.srtxg.easynet.be/ PGP Key available, key ID: 0x8F0E4975 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
