Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Should "B" be the Same as "b"? 342

Posted by Cliff from the insensitivity-about-case-sensitivity dept.
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.
This discussion has been archived. No new comments can be posted.

Should "B" be the Same as "b"? More

Should "B" be the Same as "b"?

Comments Filter:
  • Correct me if I'm wrong, but doesn't Aunt Ginnie have to actually hold the Shift key, or press Caps Lock, in order to get anything beyond "letter.txt"? Therefore, can't it be assumed in the case of Letter.txt that she did it on purpose? Sure, I'll agree that the case of LETTER.TXT is probably a user who put capslock on and forgot about it. But why deny her the ability to express herself the way she intended, if that's what she intended?

    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

    • 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. .

  • Flame-baitey topic (Score:3, Insightful)

    by SN74S181 ( 581549 ) on Monday August 12, 2002 @02:05PM (#4055553)
    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.
    • Blockquote-eth the parent poster.
      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.

      I'm sorry you feel that way. That was not the intent when I posted the question and I feel that I need to be a bit defensive here. Whether you agree with me after this...well, that is up to you.

      My point is that getting Unix (and it's variants) adopted by more users may require a change in how data is presented to them. We don't need to lose case sensitivity in the file system, and in many cases we shouldn't. When I posted this question I didn't even mean to imply that such a change should be made at such a low level. I implied a shell change. Nothing more.

      Your analogy above regarding thread tapping is highly misleading and incorrect. There is nothing stopping someome from correcting this problem, and it's need not be as complex as changing ext2/3 or any filesystem for that matter, but the actual piece of software that interracts with the user!

      For files like "LETTER.TXT", "Letter.Txt" and "letter.txt", what's stopping a "basic shell" from presenting these as "Letter.Txt(1)", "Letter.Txt(2)", and "Letter.Txt(3)". Note that we follow a standard case template for all files displayed and just add a counter which is easier for people to distinguish rather than differing case? These are all interface issues. The shell itself could disallow for creation of a filename that is a mixed-case version of something is already on the system (meaning that the display above need only occur if such files exist on the underlying file system).

      This allows for Granny to have her own portion of the hard drive, while you can continue to use bash and it's ilk without effect. That's the trick here, trying to accomodate others without affecting anyone else, and hence the reason why I posted it.

      I figure anything we can do to make Unix more appealing and intersting to use for the masses (without affecting ourselves) we should do. Please don't assume that a question is "stupid" or "impossible" solely because you don't see a workable solution. There are many heads here. Let's put them together and see if we can come up with something agreeable for everyone.

      This is the purpose of Ask Slashdot in a nutshell.

      I also disagree that change can't occur due to discussion. I instead posit that discussion is an essential trigger for change, and I respectfully challenge you to prove me wrong on that point.

      • Re:Flame-baitey topic (Score:3, Insightful)

        by rtaylor ( 70602 )
        End result, having l == L isn't right either. You're just going to piss off people in a non-en locale.

        What you really want are unicode enable file naming with colation patterns applied appropriately per locale the users locale.
      • Poor Granny's fingers get tired too. Better limit us to 8.3 filenames like DOS.

        Granny also has trouble with her password. Sometimes she has the capslock key on and can't login. Better make all passwords case insensitive

        Where do you stop? Granny shouldn't use the shell. Granny should use a GUI. Would you suggest that granny use a "command prompt" in Windows instead of Windows Explorer?

        This is a flamebait topic, sorry. If granny is a fucking idiot, she will have trouble with certain features / behaviors in ANY type of computer / OS. If she is NOT a fucking idiot, she can learn that filenames, like passwords, are case sensitive. It's just not that hard of a concept to grasp. You seem to think it is for some reason. I've taught a number of not-very-bright people that filenames are case sensitive on UNIX. They never needed to be taught twice. The response was usually "Oh, OK. Now I know!"

        I'll give you one VERY good reason why you shouldn't do "LETTER.TXT", "Letter.Txt" and "letter.txt", as "Letter.Txt(1)", "Letter.Txt(2)", and "Letter.Txt(3)" in a "basic shell". NO OTHER PROGRAM WILL KNOW WHAT "Letter.Txt(3)" IS. You are going to make Granny MUCH more confused than she already is. She will wonder what happened to her files as the names are "changed" out from under her. Sorry, changing things on the user behind the scenes is NOT userfriendly. Trying to explain to the user why filenames get changed and how is MUCH more difficult than just saying "Filenames in UNIX are case sensitive which means that letter.txt is different than Letter.txt.

        There are MANY usability issues in Linux that need to be addressed. Filename case isn't one of them. You are attempting to make a "big deal" out of a TRIVIAL educational issue.

        There is an old medical saying that applies: The cure is often worse than the disease (usually heard refering to side effects of drugs, some of which are nasty.)
    • 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.

  • Apple.... (Score:4, Informative)

    by jeffy124 ( 453342 ) on Monday August 12, 2002 @02:08PM (#4055573) Homepage Journal
    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.

    • Re:Apple.... (Score:5, Informative)

      by medcalf ( 68293 ) on Monday August 12, 2002 @02:13PM (#4055619) Homepage
      Actually, OS X per se is not this way. The HFS+ filesystem used by OS X is this way. Using UFS on OS X (built-in and easily used if you want to) uses a case-sensitive, rather than simply case-preserving, filesystem.)
    • There is even a paper about the problems of integrating the UNIX and Mac OS Environments:
      http://www.mit.edu/people/wsanchez/ papers/USENIX_2 000/, it talks about more than just case sensitive but there were a few more problems than that going from UFS to HFS+. Also it takes about how to go from a single user system to a multiple user system and back.
    • 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.
    • acutally, it is semi-case senstive. iu'm using an HFS+ partition with my own compiled version of bash, and in the shell its case sensitive, but otherwise not.

  • Sort order (Score:3, Insightful)

    by myawn ( 562028 ) <.mike. .at. .theYawns.com.> on Monday August 12, 2002 @02:14PM (#4055630) Homepage
    'A' is different than 'a'. This isn't unique to computer filenames; we all learned this in the first grade. If there is any confusion, it is probably caused by those other computers that blurred a distinction we were all quite comfortable with.

    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.

    • Re:Sort order (Score:4, Informative)

      by Papineau ( 527159 ) on Monday August 12, 2002 @02:35PM (#4055822) Homepage
      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).

  • No (Score:2, Insightful)

    by Mad Quacker ( 3327 )
    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)

  • 'A' is not 'a' (Score:3, Interesting)

    by mmynsted ( 552933 ) on Monday August 12, 2002 @02:23PM (#4055708)
    >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.
    • The sooner people accept that 'Ginny' and 'gInNy' are not the same the
      sooner they will understand how to interact with a computer.

      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.

      "Hello" and "heLLo" and "HELLO" are slightly different things. This is noticed by anyone. Yet, I am betting that if someone wrote you one of these variations, you would not tell them they were speaking nonsense. You could, but you'd be the moron, not them.

      Preserving cases is good, so if I name my file "Hello.txt", the cases should be preserved. But then if I look for "hello.txt" in that very folder, or I don't remember the capitalization exactly later, the OS shouldn't act like these are two totally unrelated strings.

      Having it the anal way in the system, and user friendly in the GUI or in a special shell is definitely a step in the right direction, although if the user ever ends up having to interact with the anal system, that inconsistency would be quite confusing.

      mark

      • typing (Score:2)

        by battjt ( 9342 )
        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
    • I think Ayn Rand would disagree [aynrand.org] .
  • 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.
    • Wasnt the original reason for this that files that were especially important were capitalised (README, INSTALL, etc) specifically so they'd head up the list in ls.

      Sounds like a good idea to me - but a real pain in the butt when dealing with files created on Windows.
      • Wasnt the original reason for this that files that were especially important were capitalised (README, INSTALL, etc) specifically so they'd head up the list in ls.
        You can prepend 0 (numeral zero) to the few files that need it to force them to sort to the top, then do case-insensitive sorting. This convention is already in use. E.g., Documentation/00-INDEX in the Linux kernel sources.
    • End result, any dialog that lists filenames in the manner you propose is also useless.

      Use the proper collation, sorting, etc. based on the users locale. You'll notice sort does what you want if you're in the 'en-US' locale, but also does what I want in my locale.

  • 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?

  • some rules of English (Score:3, Informative)

    by nwanua ( 70972 ) on Monday August 12, 2002 @02:26PM (#4055739) Journal
    Yes, I know this is English-specific, but perhaps other languages have similar distinctions:

    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: /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".

    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...
    • Actually, according to what you've said files should be enforced to begin with a capital.

      There is only 1 "Letter.txt". letter.txt would be generic, and not a noun, and therefor would have to be a folder.

      oh god...

    • "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").

      I think this is a bad example. The difference between "school" and "School" is very different beween the difference between "letter.txt" and "Letter.txt".

      Grammatically, we know the difference between "School" and "school".

      But a computer doesn't really know the diffrence better letter.txt and Letter.txt any more than between "letter.txt" and "lEtTeR.TxT", or for that matter, between "letter.txt" and "abcefg.hij". More specifically, it doesn't know the relationship between "letter.txt" and "Letter.txt".

      Some applications can understand insensitivity (like "grep -i letter *")

      I'm not sure where I stand on this. Should people act more like computers, or should computers act more like people? *shrug*

      I tend to like a suggestion made by another use on this thread: Mount a case-insensitive file system if you need it.

  • Unix has it right (Score:3, Interesting)

    by photon317 ( 208409 ) on Monday August 12, 2002 @02:27PM (#4055747)

    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.
    • In theory, you can give a Unix file a name of any arbitrary string of charcters. In reality, there are several characters that won't work, or will work at the raw file system level but be unreliable or plain broken above that. In rough order of obviousness, they are:

      \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).


      • Yeah most current software doesn't deal well with these as well as other control characters - but it's conceivable to make them work, by using wide characters and unicode-aware stuff in your C code, and maybe revamping a bash-variant to do the same. I'm pretty sure glibc has the right functions in there, just most people don't use them - they prefer to live in an ascii dreamland.
      • 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).
        Unfortunately, any such script will break on alot more then just whitespace. Failing to catch this sort of thing is a bug in the script or application, not a shortcoming of the OS or filesystem.

  • Preserve Case but don't make it case sensitive (Score:5, Insightful)

    by topham ( 32406 ) on Monday August 12, 2002 @02:27PM (#4055752) Homepage
    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.

    • 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.

      You might enjoy HFS+ [apple.com]. It does what you describe. Lots of folks who appreciated OS/2 are coming to appreciate OS X.

    • Re:Preserve Case but don't make it case sensitive (Score:4, Informative)

      by sigwinch ( 115375 ) on Monday August 12, 2002 @03:39PM (#4056258) Homepage
      The only reason why Unix is case sensitive is because it was easier, and faster to implement it as such in the early days.
      No, it's because case sensitivity is the Right Thing.
      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.
      If by "Point and Click" you mean "the egregiously bad fonts chosen for Windows", I agree. They have other problems, such as "1Il" (one capital-eye lowercase-ell) and "O0" (oh zero). (Will the real Bruce Perens please stand up? ;-)
      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.
      On the other hand, it is arguably useful to distinguish between file.c and file.C.
      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!
      All computers are not Vaxes. All text is not 7-bit ASCII. For a general purpose Unicode-compatible system, **THERE IS NO WAY TO BE CASE INSENSITIVE**. Period. End of story. No further discussion. How do you handle "Â" versus "â"? Or "" versus ""? (Capital thorn versus small thorn.) Or "Æ" versus "aE"? Or similar things for terrorist languages like Arabic and Klingon? Or the Russian letter whose name escapes me that looks exactly like a capital "O" but *isn't*. (That one's good for all sorts of fun.) The answer is that you don't even try. Anything you do is going to break badly, and a system that is randomly broken is less useful than a system that is consistent.
      • It's even worse in some languages. You have a single letter for one case, and more than one letter for another case. German is a good example here, The sharp S character is ß (&szlig;) in lower case, but SS in upper case.
      • I'm not here to debate the issues related to other languages.

        I'm saying that: For English usage differentiating between file.c and file.C is stupid.

        case sensitivity isn't 'The Right thing.' it is an artifact of the times. Nothing more. I have absolutly no reason to believe it was an 'active' decision made the first time to be 'correct'. Rather it was 'it happened to work this way when we finished', or, 'well, it was faster than converting everything to uppercase for comparisons because we only had 2K of storage anyway.'.

        I believe that case-sensitivity in a filesystem is nothing but a problem waiting to happen.

        On the other hand, I used to program in C a lot and never had a major complaint about it being case sensitive. Of course I don't expect just anyone to be playing with C source code either.

      • Well, of course it should be Æ vs æ. There are some languages that actually use that as a letter and not a ligature you know. But I agree that it is a problem...

  • Think about it a second (Score:4, Interesting)

    by PD ( 9577 ) <slashdotlinux@pdrap.org> on Monday August 12, 2002 @02:28PM (#4055760) Homepage Journal
    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.

  • In the meantime... (Score:5, Informative)

    by dar ( 15755 ) on Monday August 12, 2002 @02:37PM (#4055836) Homepage
    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.

  • Linux file system is OBSOLETE (Score:5, Interesting)

    by Jouni ( 178730 ) on Monday August 12, 2002 @02:40PM (#4055861)
    ... 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
    • 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.

      Just like democracy - it is a bad system likely to go even worse. Its only defence is that all the alternatives seem to much worse...

    • For a wonderful example of how well you could do without a filesystem, look at the operation of the Palm OS devices.

      I disagree. I think the missing file-system on Palm devices reduces its usability a lot.

    • People are not very sensitive at all to upper/lowercase letters.

      lEt ME asK yOu OnE thiNG jOUNI, arE yOu aBSoLuTElY SURe abOuT thAt?

      I know for sure that I am sensitive about it, and it really gets on my nerves when they're not used properly. Of course, people are different, but most [non 1337 script kiddies] people do care...
  • 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 [slashdot.org], I get a 404.

    S
    • OTOH, people are probably already somewhat used to this. If I go to http://slashdot.org/CoMMenTs.pL [slashdot.org], I get a 404.

      yes, but not if I go to http://sLaShDoT.OrG [slashdot.org]. And really, how often do "people" (as in average users) type in something more complicated than www.cnn.com?

  • My big question is - when have case-sensitive filenames ever worked to your advantage?

    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.

  • .inputrc (Score:2, Informative)

    by ntr0py ( 205472 )
    Special shells for novice users, that can simplify much of the complexity may be the way to go, here.


    Just put this:
    set completion-ignore-case On
    in your ~/.inputrc. Tab-completion will then ignore case.

  • Aunt Ginney won't care! (Score:3, Insightful)

    by zulux ( 112259 ) on Monday August 12, 2002 @02:55PM (#4055967) Homepage Journal
    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!

    • It's not like your aunt is going to use Emacs - she'll just point and click with whatever graphical software she is using.

      What about when she saves a file as "Letter.txt" when there's already "letter.TXT" in the directory? It'll let her do that, but the fancy GUI isn't going to tell her which one is which when she goes to open them later.
      • What about when she saves a file as "Letter.txt" when there's already "letter.TXT" in the directory?

        The Gui should politly as her for a diferent name.

        All OS level tools and services expect diferent names to be, well..., diferent. This is correct behaviour. If a particular application has users that can't handle this behaviour, then the application itself should deal with it.

        And, thats assuming that people are too suupid to make the disctinction that "Letter.txt" is diferent than "lETTER.TXT" - I don't make that assumption about my users and they are happy. Maby, I've just gotten lucky to have useres with an IQ greater than a worm.

        I've always deplored the way GUI designers attempt to hide difficult aspects of computing with gloss - "My Documents" and "My Network Places" get in the way of undrestanding and mastery. They look good in theory, because the GUI concepts help a new user - but the cause all sorts of brain damage down the road. The poor user starts to think that there are two places where their documents are stored - c:\documents and crap\users\some hidious directory\user #2\my documents" and "My Documents".

        Evil.

        My useres are happy to know that their documents are "/home/user/" Bing. Done. End of story. Takes ten seconds to explain, and dosen't cause a headache.

  • And probably, reluctantly even after years of *nix use, for case insensitivity.

    As Donald Norman [jnd.org] 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.

    • Re:I vote vor consistency (Score:2, Informative)

      by Ster ( 556540 )
      [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
  • 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.
  • Windows doesnt care what the case is 'B' is the same as 'b'. your aunt shouldnt be using unix.
  • 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.
  • Two 'b's, or not two 'b's?
  • In my humble opinion, if this is the way to go, we should do the following:
    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.

  • yes (Score:2)

    by psicE ( 126646 )
    This raises a bigger point in terms of how computers work.

    Should Aunt Ginny be able to call a file "Letter.TXT", then later search for "LETTER.txt" and find it? Certainly. Due to the nature of the English language, capital letters don't actually denote anything; they simply define a style. What I'd *really* like to see is for programs to stop recognizing capital letters the way they do now. Screw the shift and caps-lock keys; it's blatantly obvious that, in English, the first letter of every sentence and proper nouns, and acronyms, are capitalized. Period. The only other thing that caps are used for is l33t-speek, and computer design certainly doesn't need to accommodate them.

    Design word processing apps so that they automatically capitalize the first letter of every sentence. Then, change the working of the shift key so that one press means that the next letter is capitalized, and two presses means that every letter until the next space or punctuation mark is capitalized. Capitalized letters are never actually stored in a document, but simply used as formatting; all programs decode sentences and render the first letter capitalized, and can decode a "proper noun" tag or "acronym" tag as to mean certain formatting.

    My suggestions do have some side effects; namely, how would you type ~!@#$%^&*()_+:"{}|? Well, Apple had that figured out a long time ago. It's called the Alt key. Windows, unfortunately, made the mistake of using the Alt key for two-step keyboard shortcuts. The Alt key's true use is for Alternative letters. If you hold it down, there's a full range of secondary characters available. Accents, punctuation, Wingdings-like pictures, you name it. Put the !s and the ^s there too.

    This is, of course, a radical reworking in how computers currently treat capital letters. But it would work. Humans don't think of capital letters as being anything but a different style of letters, and programs should treat them just like that.
  • The future is a database-based filesystem, or at least a file system which incorporates database features. "Name" will just be one among many pieces of metadata, including potentially Mime-Type, abstract, keywords, modification date, chronological list of applications which modified said file etc. Once you look at it like this, the concept of "name" as the sole identifier becomes quaint.
  • A while back, I was writing software that encouraged third party resources being used. I realised after a while that the majority of the resources would come from Windows developers, who would be insensitive to case sensitivity. I tried to implement case sensitivity into the Windows file handling, and after looking at my results, whacked myself in the head with a cluestick, and went ahead and required all files to be distributed in a tar or zip file.

    Still, it was a portability barrier.

  • 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.

    • Banks lend money to Mr. Banks.


      Hmm... Banks and Banks are different too. Oh my. That can't be good.


      Banks lend money to other banks.


      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 /usr/home/letter.txt and /usr/home/Letter.txt.

      This discussion isn't properly about capitalization... it is about context (i.e., metadata) for files.
  • I've never ever seen a beginner having a problem with case-sensitiveness. Any sane, rational, thinking person will see that there are both advantages and disadvantages to both approaches. And once you tell the end-user how your system work (s)he will accept that, and don't worry about it.

    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.

  • The Real World (Score:2, Insightful)

    by WallyHartshorn ( 64268 )
    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.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close