Slashdot Mirror
Should "B" be the Same as "b"?
joshua42 asks: "Although having used Linux and FreeBSD for many years, I have yet to come
across anyone seriously questioning the traditional UNIX style file system name paradigm. With an Amiga background (It should be the same for people growing up with Windows, or those growing up with no computer at all (God forbid!).) it took me quite a while to get used to 'A' and 'a' being treated as different characters. This is of course fairly easy to accept and to understand if you have a technical background. I do however
have a hard time to see how aunt Ginny will ever be able to distinguish between her 'Letter.txt', 'LETTER.TXT' and 'letter.txt' files. In real life, upper and lower case letters represents almost identical information to most people. Has any thoughts been spent on this issue, now that our
favorite OS is becoming increasingly mainstream? Does it need to be
addressed? Have any attempts been done? What are the implications to parts outside the file systems?" This is an interesting point. As Unix grows more and more popular, the simple things we've taken for granted about the filesystem may stand in the way of general users adopting it. What ways can you think of that will mitigate this problem for new Linux users without actually affecting too much? Special shells for novice users, that can simplify much of the complexity may be the way to go, here.
Apple OSX is already case-insensitive in terms of filenames, probably for the reason mentioned. MS Windows/DOS have probably all done that for the exact same reason as well.
Of course, in OSX this did cause a security hole in Apache, but it was small, required a specific setup, and was easily fixed.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Yes, I know this is English-specific, but perhaps other languages have similar distinctions:
/home/Dock and /home/dock go to the same place. Yet do a pwd or try tab completion and it's all confused. (the location in finder is /home/Dock, for clarity). My take on the issue is "I will remember how you named it; just kindly tell me the file you want, exactly how I told you it's called".
what's the difference between:
"I went to school."
and
"I went to School." ?
In the first sentence, school is being used as a regular noun: which school? Who cares? On the other hand, in the second sentence, School is being used as proper name - there can be only one School.
In other words, if English speakers can understand the nuance between school and School, then said English speaker (please avoid dissing the US publik skool edukashion sistem) can reasonably be expected to distinguish between letter.txt and Letter.txt (ie. "letter? Which one?" vs. "Letter? ahh yes, THE Letter").
Anyhoo, an example of a totally confused implementation: Mac OS X: some things understand the difference, some don't:
ie:
Nwanua.
ps. if the above is true ONLY for English, all you have to do is politely state that fact, and we'll all be better informed...
That behavior depends on your locale.
Let's say I have a file with the following (meaningless) unsorted content:
asklhf
Adjgd
zaskd
Zaoifh
If I sort it with LC_ALL=posix sort myfile, here's what I get:
Adjgd
Zaoifh
asklhf
zaskd
Now, that is exactly the kind of behavior that you dislike.
Try this (LC_ALL=en_US sort myfile) now:
Adjgd
asklhf
Zaoifh
zaskd
Much like you wanted it to be, right? The C locale seems to give the same results as posix, and fr_CA gives the same thing as en_US. I'll leave it to somebody else to explain it by looking in a specific standard, or in the source code.
So in short, check that your locale is correctly specified, and sort should do what you want it to do. Or, you could just use the --ignore-case of sort.
Or were you talking about something system-wide, for ls, file selection boxes, etc.? Then it depends on where the sorting is done, and might be more difficult to fix (since you'll always miss one place).
For bash users: Add the following to the .inputrc in your home dir.
set completion-ignore-case on
Then when hitting tab to complete a filename, it will fix the case for you. i.e. typing "vi xf8" and pressing tab will get you "vi XF86Config" etc.
My other Slashdot ID is much lower.
Just put this:in your ~/.inputrc. Tab-completion will then ignore case.
[QUOTE]
My preference would be to have the OS keep the filename in whatever form of caps/lowercase that I choose but to treat files in a case-insensitive manner.
[/QUOTE]
HFS, the file system used for all versions of Mac OS, does this. I think this is generally referred to as "case perserving but insensitive". Mac OS versions from 8.6 on also support HFS+, which adds support for longer filenames and other stuff. Mac OS X can also use UFS, which is fully case-sensitive.
-Ster
-- ;-)
Kuro5hin.org: where the good times never end.
yes there is a good reason. and it is not about "removing" case-sensitivity, it's about adding it.
/any/ way what so ever. The only restrictions on Unix filesystem names is that no byte within a name may equal '\0' or '/'. You can put whatever characters or bits you want in a filename as long no byte equals ASCII \0 or /.
/before/ these 'beyond ASCII' schemes were even invented. Unix filesystems also support many many other future encoding schemes that have not been invented yet. :)
The basic issue is that Unix filesystems at the kernel level do not interpret filesystems in
This means no "tolower()" or case comparison overhead in the kernel. No complicated (and perhaps non-obvious) policy in the kernel.
It also means filename schemes are easily extensible in userspace. Eg, Unix filesystems support Unicode, UTF-8, ISO8559-[0-9][0-9], and whatever other encoding system you want provided you respect '\0' and '/'. In fact Unix supported Unicode, UTF-8, etc.. almost from day one (ie 1970), literally
Basically, tolower() / case comparison can be easily done in userspace - hence that is the best place for it. Now, of course, userspace might not always agree on policy or how to implement it, but that is not a kernel problem.
Case sensitivity is a matter of taste, and as such it's best not done in the kernel (where it will be set in stone forever). That's actually a general Unix design principle "policy should be implemented in userspace" - and it's actually a very good design principle..
now let's see how many slashdotters fail to realise it..
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
what is the advantage to having "Aaa.txt" exist in the same directory as "AAA.txt"
Because the file name Aaa.txt is "0x41 0x61 0x61 0x2e 0x74 0x78 0x74" in hexadecimal which is not the same as "0x41 0x41 0x41 0x2e 0x74 0x78 0x74" the hexadecimal equivalent of "AAA.txt".
When you get down to the core operation of the kernel, it shouldn't be burdened with having to do conversions of 0x41 to 0x61. If some one writing an application wants to make that distinction, that's fine (and could easily be incorporated into programming libraries), but it shouldn't be the job of the OS.
Work for Change & GET PAID!