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.
My solution is for the OS to ignore the caps lock key. Not only would it solve the case problem, but it would shut up a whole lot of AOL users.
:-D
www.HearMySoulSpeak.com
This is a flamebait topic.
Why don't we ask: "Should the convention for tapping threads in metal be switched to left hand threads by default?"
Nothing will change as a result of the discussion, and nothing should change. It's the 'simplify UNIX and destroy it in the process' arguement all over again.
Good grief.
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.
What is confusing is that "A" and "a" don't sort next to each other -- so, letter.txt doesn't end up following Letter.txt, but instead is down somewhere past Zebra.jpg. That defies reason; if something is to be fixed, let it be that.
Subscribers can see articles in the future? So what? Everyone gets to see them in the future.
What are the odds that your Aunt Ginny or any equally technically inept person is actually using *nix for something so mundane as typing a letter. She is almost certainly using some Flavor of Windows, or perhaps a Mac. OS X is already case insensitive, and lets face it, Aunt Ginny is never going to open a term window anyway. As long as she can point and click she can find and open her letter regardless of how its named. In the really unlikely event that she is in fact using *nix do you really think she's using vi to send those letters home? or is it more likely she is using KDE or Gnome as a windows substitute and is still quite fine as long as her mouse finger holds out? I'd say this is really a non issue. .
If privacy had a tombstone it would read "We did it for your own good" . -- John Twelve Hawks
Novice users will always use file selection dialogues and icon-based file managers. Thus the only time they type a filename is at initial creation. Beyond that it does not matter. If they are going into a shell, they are not novice users anymore (I doubt you will see aunt Ginny do this)
"I don't know that atheists should be considered citizens, nor should they be considered patriots." George HW Bush
>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.
Just like how aunt Ginny was likely somehow able to grasp that her
name is written aunt Ginny and not aunt gInNy, aunt gINNy, or other
combination. Give her a little credit. Simply explain that the case
is part of the file name. Your example Letter.txt file names would be
a perfect way to show her the difference. Just make each contain
different information, and open each one to show her they are
different.
File systems should be case sensitive. An upper case 'A' is a different
character than a lower case 'a'. We should not confuse people by
tricking them when the create file names.
>In real life, upper and lower case letters represents almost identical
>information to most people.
Almost, but not identical.
>Has any thoughts been spent on this issue, now that our favorite OS is
>becoming increasingly mainstream?
>
>Does it need to be addressed?
No.
>Have any attempts been done?
I hope not. Mount a case insensitive file system if you want one.
Leave existing file systems alone.
>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.
The sooner people accept that 'Ginny' and 'gInNy' are not the same the
sooner they will understand how to interact with a computer.
>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.
How about a mouse-click'n GUI like GNOME, KDE, etc.
any application or standard dialog that lists filenames but does not sort them in a case insensitive manner should be trashed. its useless. i don't care if the filesystem itself is case sensitive or not but the high level application user should not present them to the user in a messed up order putting apple after Orange.
If "B" and "b" were meant to be the same, they'd look the same.
In many languages, English and German to take two examples, capital letters have had a specific usage for a much longer time than computers, or eve for a much longer time than typewriter keyboards. They are different letters and, more importantly, people believe they're different letters.
Why regress to that era 20 years ago when in some strange computer-based subculture of reality the two letters were indistinguishable?
"Provided by the management for your protection."
OS X remebers case, but ignores it. This way your
file is named just the way you typed it, caps and
all, but if you reference it with different
capitilazation, it still matches. If you try to make
a second file with the same letters but different
capitalization, it won't let you. The best of both
worlds. No multiple files with the same name, yet
case is preserved for looks and correct grammar.
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...
The problem is more complicated than the question makes it out to be. An Ideal filesystem should allow any random binary bits to make up a filename, such that the filenames can be Unicode, so that Chinese people can name files in Chinese, Math professors can use the unicode for a math formula as the name of a document describing how to solve it. When you think in this bigger sense - it becomes a lot harder.
Ideally the encoding method (Unicode in this example) should provide some way of seeing the equivalency of certain characters (two different representations of the equal sign, two different cases of the letter A, etc..), and the application should be able to make use of this during a regex search, or maybe even during a library wrapped "open() or readdir()" call, where the application is "Windows Explorer", "bash", or anything else.
Ultimately this has to be resolved in userland tools and the libraries that support them - the best answer for the filesystem layer is to support all possible characters literally and meaningfully in filenames, so as not to restrict the schemes layered on top of it.
11*43+456^2
The only reason why Unix is case sensitive is because it was easier, and faster to implement it as such in the early days.
It is not quite efficient to Preserve Case, and not make it case-sensitive.
I used a file system like this (HPFS) for many years and much prefer it over the case-sensitive alternatives.
It is also a security concern. If I have 2 files, which are identical except for case it is possible I could run the wrong one. Why? Point and Click interfaces barely show a difference between o and O, etc.
There is also no need for 2 files with the same name, and different case when it comes to SOURCE CODE. I have seen more than 1 program implemented like this and it is downright confusing and stupid. " No no, not "ubergeek.c", "Ubergeek.c"... etc.
Garbage. Crap. Total waste of resources.
I've been working in a database language that is case-insensitive for a number of years as well. It is damn nice to not have to worry about somebody typing something in differently than expected. It isn't a problem. And I don't have to call UPPER every time I do something!
case-sensitive is a pain in the ass.
iF yOU wROTE a lETTER tO yOUR aUNT gINNY lIKE tHIS wOULD sHE nOTICE sOMETHING wRONG wITH iT?
If you think she would, then she can grasp the concept that case makes a difference. Give her a little credit.
If tits were wings it'd be flying around.
In windows if you name something "LETTER.txt" I nicely changes the name to "Letter.txt" for you.
Do what they say, not what they do.
Oh, by the way...
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.
... and now that I got your attention, let me specify that all other file systems as well are obsolete in the context of the USER INTERFACE.
Frankly, aunt Ginny should *never* have to deal with files and file names. She should not need to know what a file is, nor choose to "save" or "discard" her work after she has written the letter to her friend Margaret. She does not know her HD from her RAM, and all for the better. She would worry to death over having her letter spun around on a magnetic disc, it would get all jumbled up for sure!
File system is an internal, abstract and archaic database that is familiar to programmers and geeks, but a lousy way to represent data for the general user. There are few things worse than navigating a blind hierarchy of unknown folders with no contextual guide to help.
The system should remember the letter when it is written, keep tabs on when it was written, put the subject in a "recent letters" list and generally manage the internal filing transparent to the user. The storage capacity of a modern computer can last aunt Ginny for years, the real trouble is in FINDING her data, the file names alone do little good for that.
For a wonderful example of how well you could do without a filesystem, look at the operation of the Palm OS devices. Anyone could learn to use them. No files in sight! It's only recently that the clever engineers at Palm jumped off the deep end by adding a file system for the flash carts. Anyone who has ever used those knows what a nightmare managing them is.
Aunt Ginny knows fsck all about file systems. Lets keep it that way.
(Oh, and the answer in the context of user interfaces? Go for the most HUMAN representation. People are not very sensitive at all to upper/lowercase letters. We should not punish them for this.)
Jouni
Jouni Mannonen | Game Designer, Consultant
I'm actually a bit nervous posting in this thread, because the whole thing reeks of flamebait, but:
What about a common toolkit (common-dialogue) system that automagically lower-cases all filenames when entered in the common dialogue?
ie, if KDE/QT or GIMP/GTK+ automatically lowercased any filenames saved or loaded through its common file-loading dialogues.
This would have to be easily turned off, but would solve the problem for most non-power users, while other users could turn it off, and never have to deal with it again.
Just an idea.
OTOH, people are probably already somewhat used to this. If I go to http://slashdot.org/CoMMenTs.pL, I get a 404.
S
I like the system "correctness" of different ASCII values being treated differently. But the practical value escapes me.
That said, a large number of systems would break if the scheme changed. Given that most users use GUIs and rarely actually type names, is there a good reason to switch at this point? The few places where I see a true advantage (Windows compatibility, for example) have already handled this at the application layer.
Says the RIAA: When you EQ, you're stealing bass!
Just put this:in your ~/.inputrc. Tab-completion will then ignore case.
It's not like your aunt is going to use Emacs - she'll just point and click with whatever graphical software she is using.
Leave case sensitivity alone - it's the right thing to do, just hide any ease-of-use problems it may introduce with a GUI.
That keeps the smart people happy, and the dumb people happy. We're all happy!
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
As Donald Norman has commented, if lots of people use something incorrectly there is probably a problem with the design, not the people. I will admit to having on more than one occassion typed "less readme" instead of "less README" or scrolled through a file listing and overlooked a file that was sorted elsewhere due to capitalization.
Even worse is the fact that subparts of an item follow different rules. For example:
http://slashdot.org/index.html == http://SlashDot.ORG/index.html
due to required case-insensitivity of domains,
http://slashdot.org/index.html != http://slashdot.org/Index.html
unless the underlying OS/web/app-server chooses to interpret them as equivalent.
As some have commented, everyone sees a difference between joe doe, Joe Doe, JOE DOE and jOe doE but they all know that in every case we are referring to the same person. In fact many places standardize on all-caps for the family name in forms and documents to reduce errors.
To those who say that the problem should be solved on the application level: consistency is good - a user should not have to remember the quirks of each application. Even if one is a slave to point-and-click GUIs there are problems created by sorting and the possibility of multiple files with the "same" name.
Windoze is also brain dead. Although it is case insensitive, it also changes the case of file names in one of its many misguided attempts to "help" the user.
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.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
This boils down to you're trying to protect people from themselves -- and it won't work, because it can't.
Why assume people are idiots? Why not assume they'll be able to tell the difference between upper and lower case letters? The only reason case equivalency is intuitive is because it's what the system they currently use does it that way.
--
Twoflower
Correct me if I'm wrong here, but that would mean that passwords should be case-insensitive, too. This problem is even worse on passwords, where one isn't given a list to choose from and actually has to memorize the case of characters.
Personally, though, I think that's a bad idea. The little piece of BOFH in me says any user who can't remember letter case has a lot of learning to go through before they should be allowed to use an expensive piece of equipment such as a computer, and the case-sensitivity of passwords is an excellent automated way to ensure that this is in fact what happens.
\000 - Putting a zero byte in a filename will break any program written in C.
'/' - A filename with an embedded slash will be unusable except by programs that walk directory contents very carefully.
white space - Filenames with embedded white space work with most basic system commands, but will break shell scripts that aren't prepared for them (which means most shell scripts).
To a Lisp hacker, XML is S-expressions in drag.
Windows doesnt care what the case is 'B' is the same as 'b'. your aunt shouldnt be using unix.
I agree, why would we want to dumb it down?
It would be less functional not more.
Also notice it is "make it like what I used to have" rather then just suggesting making it case insensitive, seems like it is laziness, not a well thought out reason.
On my Mac, if I type "Letter.txt" or "lETTEr.TxT", it is preserved and displayed in this manner. But if I want to find this file and I look for "letter.txt", the computer isn't going to tell me there isn't any.
In this circumstance the OS doesn't have to enter into the equation. Since what you are referring to is the search program, which is distinct from the OS. A search program could easily be programmed to default to being case insensitive (as the search in Windows is) and only discriminate on case when selected by the user.
Or if I try to name one file "letter.txt" and another "letter.TXT", it won't let me put them in the same directory.
Again, this could be addressed in the interface rather than the OS. Remember that with 32 bit Windows systems all files have three names, their long file name, their case sensitive long file name and the DOS (8.3) file name. As far as the OS is concerned you could get by with just one of these, the rest are just interface enhancements (I think that the OS in fact does this ignoring two of the name forms and using the third as the basis for locating files on the physical drive - the actual work of the OS.)
So really the question is could a *nix SHELL be created that is case insensitive, and could *nix file utilities be set to be case insensitive by default. And the answer to both of these questions is YES and YES, and the source code is out there should there be someone with sufficient interest and skill. You wouldn't the OS itself (i.e. the kernel) to be case insensitive as it would only remove capabilities and slow it down.
Work for Change & GET PAID!
What about non-English languages? What about accented characters? It seems to me that an internationalized version of case-insensitivity could be very complicated and inconsistent.
Mea navis aericumbens anguillis abundat
Some people call wisened leaders Elders. As a title, the word is capitalized. So, "elder Tom" means the older of two Toms and "Elder Tom" means the Elder named Tom.
The church" on the corner is a building...
The Church is the organization/establishment (i.e. "The Catholic Church").
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
But when it is represented inconsistently, people will get confused IMO. You're right about how the search program could be case insensitive. But what if someone writes a file and names it "letter.txt", intending to overwrite the original file, which they happened to have named "Letter.txt" before. The file is saved, and now there is "letter.txt" as well as "Letter.txt" in that directory. Maybe the application accounts for this as well. But every single hole to the "real" UNIX filesystem has to be patched up, and the user has to be shielded from ever finding it.
Not a horrible situation (as you said, DOS+Windows works that way), but IMO not the best situation. I think a case-preserving (only) system would be the best, because it is much easier to use for the normal person, and it would mean this case-issue would be consistent system-wide.
And what is lost? It may be difficult to convert everything over, which is not to be ignored. But just talking theoretically, how is this a worse filesystem (eg what is the advantage to having "Aaa.txt" exist in the same directory as "AAA.txt")?
mark
If you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
Not if something is done to the system to let XFree open the file with the name XF86Config...
Tomorrow will be cancelled due to lack of interest
I think Ayn Rand would disagree .
The kind of search you are talking is way overkill. Your search program simply reads each filename and converts the name to all upper or all lower case before it compares to the simarly-converted requested file. See for instance these C library functions. Your program is only a few lines, and it only need pass through the directory once.
Two 'b's, or not two 'b's?
Good judgment comes from experience.
Experience comes from bad judgment.
You're the one insulting people's intelligence if you think the problem is that they don't grasp the ability to even distinguish upper- and lowercase.
You wouldn't know what an insult to intelligence was. By definition, it can't happen to you.
My comment was in fact stating the very opposite of what you think it stated.
If tits were wings it'd be flying around.
All that said, capitalization or other letter-forms can carry more information in other languages than in English. Diacritics can completely change the meaning of a character (English speakers don't have this, but it is important in most other European langauges and vital in some asian languages).
The question, really, is language specific, and is a real pain in the butt if you want to properly sort and compare strings for international usage. A related issue has to do with ligatures and glyph transformation in some middle-eastern languages: the same word can be spelled differently depending on it's position in a sentence or relative to other words.
There is, unfortunately, no simple solution to these problems.
1) keep the file system as it is.
2) Create a new system call fiopen (*) that would open a file in a consistent way, mathing actual case first, and if that failed, various alternatives, probably depending on the locale, and a number of other things. The details to be sorted out in a horrible flame war
3) Use this call in standard GUI components. Applications will follow naturally.
The important thing is to figure out the one right way to handle the case insensitivity correctly and consistently, and possibly leave the old stubborn user a way not to be forced to use it if he (**) so prefers.
Notes:
(*) As in stricmp, etc
(**) Since the English language requires me to choose a gender for an unknown person, I have here chosen the male, as is often common. Normally I consider users female, to remind me to go out of my way to be nice to them. Chauvinist or gentleman - your choice.
In Murphy We Turst
Anyway, I think I understand your point, but I guess I just fundamentally disagree. I hate it when programs like Windows keep making assumptions about what I want to do. The only useful thing I have found is when I mistype "the" as "teh" in Word and it corrects it for me. However, when I want to create a folder called "QNX" so that I can put in QNX-related software, I don't want it insisting that it should be named "Qnx." Do as I say, not as what you think I want!!! As someone who programs, I also find it useful to tell the difference between the files foo.c and foo.C (and my compiler finds it useful too).
In the case that you mention, I just don't see the problem. If I'm looking for a file letter.txt and my search routine comes back with Letter.txt, letter.txt, and Letter.Txt, then I (and Aunt Ginny) should know what file we want opened. If not, then we should open all three to see which one we want. If Aunt Ginny started a file letter.txt and later "Save As" it to Letter.txt, then that is a problem she has to work out. It is the same as if she later saved her file as lettre.txt. At some point she'll have to reconcile her errors.
I never had a PC until about 8 years ago. I cut my computer teeth on a VAX system and got used to case-insensitive filenames. When I moved to Unix/Linux systems, it was just a minor difference to get used to. A lot of people make the argument that Linux will only be popular if the UI is exactly like Windows, but I disagree. Anyone should expect a learning curve when moving from one OS to another (even Aunt Ginny). Move Ginny from Windows to a Mac and you'll have to explain to her how some of the things she wants to do are different. Look at the differences between the various Windowses, but people have had little problem moving from 3.11 to Win95 to WinXP, etc. Microsoft just has the genius (and $$) to market the idea that it is a revolutionary and great step and people accept it and learn it. Remember when Win95 came out? The Mac users were annoyed to no end because Microsoft was touting their new point-and-click-and-drag GUI as incredibly revolutionary and the greatest breakthrough in computer history.
I think that it is the idea of moving to a different OS and not some silly minor UI differences that keep people from actually doing it.
NO!
B != b
There is a very good reason why UNIX is case-sensitive, or at least I can think of a very good reason to keep it case-sensitive.
In biology, writing out a protein name in all uppercase letters indicates the wild-type GENE (i.e., VAC8), while writing it in lowercase letters indicates a mutant of the wild-type gene (i.e., vac8). This is just a specific example. In other words, there are many instances where case matters.
VAC8 is not the same as vac8 (one refers to the wild-type gene, the other to a mutant).
Federal is not the same as federal (one, I believe, refers to specific federal entities, the other to the idea there-of).
Bush is not the same as bush (one is the President, the other is a plant).
Banks is not the same as banks (one is a last name, the other is a financial institution).
Come on. Its not that difficult for people to grasp the concept that a file named dave is not the same as one named DAVE. If certain users really don't like that, then they should disable cap-sensitivity (I'm sure there are options to do such).
There is a lot of talk about making Linux easier to use for the average person. Just as easy -- and an effort which would not require programming skills -- would be to make the average user more Linux-savvy. This is what a large part of the Linux community (known as gurus) does. It means you don't say rtfm to every question, though it is good to try to help people figure things out for themselves, rather than telling them the answer.
social sciences can never use experience to verify their statemen
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!
The only people who care about minor, but unimportant differences like this are techies, because they are already accustomed to a certain style, and because it is a religious issue they can discuss till the end of time, like vi/emacs, windows/mac/linux/, gnome/kde, etc...
More importantly, I don't care about how user-friendly the command-line is for someone getting confused about case-sensitivity. Users like that should be strapped to their idiot-interface which we can create on top of Unix as well as on Windows. One good example of such an interface is called Bob.
Even todays computer interfaces (which isn't exactly completely suitable for complete morons (noticed the amount of courses for beginning windows users?)) doesn't require you to type a file-name more than once (at first "save"). After that, it's point and click.
My mother can't even use a mouse, or remember the difference between backspace and delete from each time she uses the computer. But I assure you, case-sensitivity is not an issue. There are many things that are confusing her, but understanding that you should use the same name in the same case is not one of them.
God forbid you should respond to the points I made.
That applies to you. Your first message in the thread was an obvious misunderstanding of the point I made. Why not make another attempt at a coherent reply to the actual point I was making?
If tits were wings it'd be flying around.
The only reason for not having case-unsensitivity in the kernel, is to not complicate the kernel, and keep policy out of the kernel. This, on the other hand, is a good reason.
Correct.
Wow. Nearly every reply in this thread is an example of how techies are not like normal people -- and yet don't realize it. Despite your wishes, the non-techie world is not going to accept that "Letter.txt" and "LETTER.TXT" don't refer to the same file. If I received a check made out to "WALLY HARTSHORN", would you say that I cannot cash that check because my name is "Wally Hartshorn"? Would you say that "Ford" is a different company than "FORD"?
Like the original poster, I am a former Amiga user, so I am quite familiar with the experience of a file system that allows mixed-case filenames, but recognizes that they are equivalent. It was far, Far, FAR nice than having to remember whether I named the file "Letter.txt", "LETTER.txt", "LETTER.TXT", or "letter.txt". Like nearly everyone else, I remember words much more readily than I do specific capitalizations.
The sooner UNIX-based computers learn that when a person is looking in a directory for "letter.txt" that "Letter.txt" is probably what they mean, the sooner they (the computers) will understand how to interact with people.
And shouldn't that be the point of it? Not the other way around.
right.... How many GUIs have you designed. Users are not logical at all. After we remove case, they'll ask that 1==l==i==t, then a==e==o==0==D==c==Q, then d==b==p==q then s==z then j==i, then g==q==j, then R==K==h and P==R and E==F and b==S and m==n and u==w==v and w==m. Now we are down to two letters x and the other stuff.
Why screw up a working system and not fix the root cause. The root is that the user is incapable of specifying the file by typing. Duh, use a search panel that handles the rules and presents a big button [IS THIS YOUR FILE STUPID?].
Joe
Joe Batt Solid Design
Hmm... Banks and Banks are different too. Oh my. That can't be good.
Even worse. Banks and banks *are* the same here. That can't be good either.
Would you like to re-design the English language?
A lot of information in language comes from context. In a filesystem, context is, unfortunately, usually lacking. Rather, context is usually provided by the directory/path and the file extension. That is insufficient information to tell the difference between
This discussion isn't properly about capitalization... it is about context (i.e., metadata) for files.
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
There is no difference between directories and files. It's just that usually, you don't use file extensions on directories, but if you call you directory QWERTY.txt, case will be preserved.
And, like most annoying behaviour in Windows, there's a way to turn it off: Tools->Options->View->Allow all upppercase filenames. Given the alternatives, I think windows actually did the right thing here. Mainly since the filesystem doesn't care about case anyway, and manually renaming 200 files with uppercase names is annoying. I'd much rather have the system take a guess at something more readable, and have an option to turn it off, if I really want my ALL_CAPS filenames.
Next week, come back to Ask Slashdot: Should filenames be 3117-zP34k-4vv4R3
That said, however, the conceit that capitalization is either vital or useless for word meaning is an entirely parochial prejudice. Rules that work well in English may be entirely wrong for another language. If we are going to talk, usefully, about how to manager the sorting and comparisson of file names, we need to consider more than just English usage.
What about "Aaa.java" vs. "AAA.java"? Java classes are case sensitive, meaning the files must be also. I know I've run into problems before with distinct Java classes that work fine on a UNIX platform (with case sensitive filenames) being brought onto a Windows platform where the two classes can no longer coexist. Sure, Java could be changed, but why should it? For some people who can't understand that "Aaa.java" and "AAA.java" are TWO different file names? I've never run into a person who couldn't understand that, once they've been told.
Just like most of UNIX/Linux's "user unfriendliness", it's mearly a difference from what (most) people are used to in the Windows World(TM). Personally, I know I've had more problems with case insensitivity (because I wanted to have two different files with just different cases) than with case sensitive systems. YMMV.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
simple solution - only ever use lower case in filenames
why have a complete mirroring of th alphabet in another case? th ancient greeks and th romans got along very nicely with just one case - th russians still do today (and perhaps still th greeks?)
i read somewhere that th terms 'upper case' and 'lower case' are printing terms and correspond directly to th cases in which th metal type letters were kept - hence it seems to be an invention of th printing press age or perhaps goes back to th monastic penchant for illuminating certain letters to give them added emphasis
capital letters always have this feel for me - a kind of victorian sensibility of 'This Is A Very Special Word Which You Must Respect And Hold Dear In Your Heart' - a some words are more equal than others kind of approach - very like that irritating practice of capitalising him and he when referring to Certain August Fictionalities in th bible
and yes, to forestall yr reply of capitals increase legibility - i am aware of that argument, however i think th present model of capitalisation at th beginning of a sentence is tired and could do with some creative alternatives
domain names are case insensitive, however, usernames are often case sensitive.
Also, in going with cnn as the example...
http://robots.cnn.com/ALLPOLITICS/ shows all the political news... however http://robots.cnn.com/ALLPOLITICs/ shows 'not found'
most portions of the url other than the domain name are in fact case sensitive, although this depends on the server running the resource.
(slash may murder those links, but you should get the point)
Need a Catering Connection
First of all, my rudeness to you is a response to your rude post. You seem to dish it out just fine, but when I throw that shit back in your face you cry foul. Who's the hypocrite?
You seemed to make the point of "sHE kNOWS wHAT iS wRONG wITH tHIS", therefore, she should be able to tell the difference between different capitalizations in the file system, and we shouldn't assume they are dumb.
There, you have correctly stated my point. You get a cookie.
It doesn't matter for email addresses and (most) URLs.
That's right, and they are broken. We've got to fix that problem right away. I'm serious.
And maybe that's fine... maybe you don't want to encourage the mainstream users to use unix. Because then you do have to deal with stuff like that.
Maybe you like to pull hypotheses out of your ass? Maybe you like straw men? Maybe that really IS a monster under my bed? Or maybe I never said that, I never implied it, and you just made it up.
Don't join the Army. You'll have a very hard time if you try to interpret the Sarge's orders as loosely as you interpret what I write.
If tits were wings it'd be flying around.
please explain the difference in context of your example. /usr/home/letter.txt and /usr/home/Letter.txt.
For ease of use, only 2 things are needed, programs that remember a history, and the ability to search your HD with an case insensitve search.
The Kruger Dunning explains most post on
Incorrect.
The Kruger Dunning explains most post on
Case insensitivity required globbing in the kernel. UNIX has historically done all globbing in user space, and passed only literal values to the kernel.
Case folding on storage is realtively easy (Just Do It(tm)), but case folding on lookup for system calls that take explicit names (open, stat, creat, rename, unlink, etc.) requires that the literal value passed match multiple potential values as soted in a directory.
Doing globbing in the kernel is actually more efficient in a lot of ways (consider that when doing an "ls -c", rather than pushing the whole directory contents over the user/kernel boundary via the getdirentries/getdents system calls, you would push only names which matched the expression, drastically reducing the protection domain crossing overhead).
However, POSIX practically *demands* that you not do your globbing in the kernel.
Apple gets around this by force-folding. Basically, it is case sensitive on storage, and case insensitive on lookup (Windows outside the legacy 8.3 namespace is the same). The problem with this, as you would know, if you had ever written internationalized FS code on Windows to be installe dunder the IFSMgr, is that there is a requirement for "active character set case folding tables", and these are locale specific (e.g. what do you do with the Schlossen if you are in Germany vs. France, and how do you handle Hangul, Kanji, etc.).
Basically, without destorying certain standards mandated behaviour, it's not possible. Most likely, you will not find a programmer willing to give up POSIX compliance or internationalization in order to change this behaviour.
-- Terry
What's the end of your sig say? Read my sig to see my feelings on the subject. (:
Whoever stated that signature sizes should be limited to one hundred and twenty characters can just go ahead and kiss my
Two words: Unicode and upcase
[an error occurred while processing this directive]
When you get down to the core operation of the kernel, it shouldn't be burdened with having to do conversions
hm. i argue it should. actually, not the OS, perhaps just the shell. i'm not sure where this should happen. but i doubt it's at all hard, eh.
Is el nino the same as El Nino? Is the internet the same as the Internet. You're assumption is false -- the case really DOES convey essential information in most languages.
"Freedom means freedom for everybody" -- Dick Cheney
More people who think it's actually acceptable to have "python" and "PYTHON" subdirectories in the same dir.
Two words which differ only in case are pronounced exactly the same way, at least in English (but also in most other language which have a concept of letter case). That's the only real determining factor. Grammar is meaningless when dealing with filenames, so capital vs. lowercase loses any real value. Thus, case-insensitive should be taken to rule the day, bec ause it more accurately reflects the way people think about filenames.
Or, to put it another way, what is the difference between "Mary had a little lamb" and "mary had a little lamb"? Most people would say there is none, and indeed, given the massive number of people who don't use capitals in their e-mails anymore, there's some credence to that claim. If people don't care about whether things are capital or lowercase on a computer, then why should the computer itself care either?
Some filesystems implement case insensitive filenames, so it can't be that hard.
Quick! You write efficient filesystem-level code to handle upcasing Unicode filenames for collation on non-Latin writing systems. It'd be easy to map [A-Z] to [a-z], but what about German, where a lowercase ß (1 char) becomes uppercase SS (2 chars)? What about Turkish, where dotted i upcases to dotted I, and dotless I downcases to dotless i? What about Greek, Cyrillic, Armenian, Georgian, and other writing systems that have upper- and lowercase letters? Can you really handle localized Unicode processing in the kernel?
Will I retire or break 10K?
This has been handled for ages in the standard C library. If you want a comparison to be case sensitive, you call strcmp(). If you want case insensitivity, you call strcasecmp().
Similar things exist in most higher-level programming languages. For example, with perl pattern matches, you add 'i' to the list of flags, and a case-insensitive compare is done. This works with locales in all recent versions of perl. And so on for other languages.
This is an open invitation to implementers. It's very easy to to case-insensitive compares. If you are aiming your software at a user population that can't handle case distinctions, the tools are there and you have no excuse.
Unix and its clones don't impose any policy at all on user-level software, and they supply the tools to handle case sensitivity. Use them and stop complaining.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
I'm not going to waste a lot of time on the reply.
What, what and WhAt are all different, it's that simple. I.T. is different from it.
It's a Simple matter of education.
Unfortunately there is only a certain level that things can be dumbed down to... or maybe only a certain level that they should be dumbed down to.
Capitalization punctuation and spelling, are the kinds of things that cannot be dumb'ed out of existance beyond the use of GUI's.
Two different languages can have the same accented characters, but different rules about case conversion.
And conceivably, changing the locale can cause files whose names had not clashed before to begin to clash. Thus, the locale for files in a particular folder must be stored as an attribute of that folder.
Will I retire or break 10K?
It is my understanding that case makes a huge difference for other character sets. I'm afraid that I have no evidence to point at, but I've been told this by several people, so it MUST be true.
perl refers to the executable, while Perl refers to the religion^H^H^H^H^H^H^H^H programming language, which in this case, is a proper noun.
By the same token, it is proper to write "He speaks the english language because he is English." Yes, case makes a difference.
The question should be restated: does anyone care?
Give me my freedom, and I'll take care of my own security, thank you.
...when I read these comments, the quote at the bottom of the page was:
... Although I don't know WHY!!"
"All of a sudden, I want to THROW OVER my promising ACTING CAREER, grow a LONG BLACK BEARD and wear a BASEBALL HAT!!