10 ms·

The problem is not with capitalisation, the problem is that Linux filesystems are case-sensitive and require you to type the name with exact case.

bayindirh 5y ago
I don't honestly understand why a case sensitive file system is a problem. I think a case insensitive system is counterintuitive.
- codedokode 5y ago
  Because case insensitive filesystem doesn't require you to press Shift key when typing a command. Typing `ls /Program` requires one keypress more than `ls /program`. Also, it is easier to remember just a name rather than remember how exactly it is spelled.
  - rickbad68 5y ago
    A case sensitive filesystem doesn't require you to hit shift either if you just call the directory "programs". Also, there are many ways to save your pinky from moving the huge distance to the shift-key other than an arbitrary restriction on all file names in the file system..
    - codedokode 5y ago
      What are the advantages of using a case-sensitive file system? I cannot imagine a situation when you need to create two files that differ only in letter case. This also would make program that create such files not portable.
      - hvdijk 5y ago
        The primary advantage for me is simplicity. Case insensitive file systems are complicated when you start dealing with non-ASCII characters and different software implementing the case rules with subtle differences. With case sensitive file systems you know exactly what you get.
        jodrellblank 5y ago
        If you're going to move to non-ASCII characters, what about Unicode combining characters, do you have to care if your file named é is a single accented e or a pair of e-and-combining-accent before you can move it? If you shouldn't have to care, if there should be a layer of Unicode normalization happening, why is that okay but case normalisation is not okay? If you do have to care, then you no longer "know exactly what you get".
        hvdijk 5y ago
        > If you do have to care, then you no longer "know exactly what you get". You do know you get exactly what you put in, whether that is é (U+00E9) or é (U+0065 U+0301). When you reference files created by yourself, this is not a problem as realistically speaking, your input method will only have a convenient way of forming one of these, and it will consistently generate the same one every time. When you reference files created by someone else, this may be a problem but no more than e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i): from the user's perspective, the problem is pretty much avoided by selecting the file using tab completion, TUIs, GUIs, whatever you use.
        bayindirh 5y ago
        > e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i)... Just want to remind a little but extremely important thing: There's absolutely no guarantees that upper("i") is I. There's at least one language breaks that convention, and you won't believe how a big headache is that.
        hvdijk 5y ago
        Good point, Turkish uppercases i to İ. This adds complexity to the idea of case insensitive file systems even when only considering ASCII.
        jodrellblank 5y ago
        https://prnt.sc/257kxxa https://prnt.sc/257kxxa lowercase l and uppercase I are quite distinct. If you're going to select all your filenames with autocomplete, then why argue restrict me to case sensitive filenames? Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.
      - naniwaduni 5y ago
        Well, it means you don't need to do things with Unicode casefolding tables in the middle of your not-eating-data fs code.
  - bayindirh 5y ago
    I think the utility of a real case-sensitive file system cannot be nullified with an "I need to press shift!" argument. Apple's APFS will create the folder as "Programs" if you use "mkdir Programs", and will give you an error when you try to create "programs". You can navigate with any case combination, but it just plays along like the capitalization you entered is present. It feels like a hack tbh. Another thing I noticed that I never notice that I'm pressing shift while capitalizing. It's not a deal-breaker issue for me (while this might sound like "it works for me", I'm sure that I'm not alone in that). Case insensitive systems created a lot of problems down the road. Esp. due to popularity of Windows. Program porting is a pain, using macOS with real case-sensitive mode is again a pain for some scenarios. It also encourages sloppy programming practices and "I don't case as long as it works" ism.
    - jodrellblank 5y ago
      > tbh What is this? It's not capitalised so it can't be an acronym or initialism. And your username doesn't start with a capital like a Proper Noun, so it's unreadable. This is my problem with case-sensitivity, it's not how humans use writing, think about writing, design fonts, etc. 'a' and 'A' are the same letter, they're the same letter in the alphabet, they are pronounced the same, they make the same word "apple" or "Apple" which is also pronounced the same and means the same, they could be rendered the same in a given font without making words unreadable or confusing (e.g. small caps fonts). If the computer isn't letting me use "apple" or "Apple" interchangably as I (the user, supposed to be in control here) wish, that isn't helping me, it's nitpickingly hindering me and making me implicitly care about character encoding values I can't even see. This is dreadful UX. Domain names aren't case sensitive, email addresses could be but generally aren't, usernames could be but generally aren't, phone numbers aren't, Twitter handles aren't, my bank cards have my name in ALL CAPS but it's still me, you wouldn't join an IRC channel and think it okay to use a nick which matches someone else's but for capitalisation differences, you know which book I mean when I say "the martian" and so does Google search and my email search, PostgreSQL table and column names aren't case sensitive. It's nice, convenient, helpful when identifiers aren't case sensitive.
      - GlitchMr 5y ago
  - greiskul 5y ago
    If you are manually typing a command, then the shell could do this work instead of the file system, right? That's what the shell is for, to be the bridge between humans and the computer right. In a perfect system, you would type ls /p, and one of the suggestions of the tab completion would be /Program.
    - bayindirh 5y ago
      Bash normally doesn't do that, but there are a lot of options available for both Bash and ZSH, which can do much more than just "case insensitive matching".
      - yjftsjthsd-h 5y ago
        Specifically: For bash, `set completion-ignore-case on` in ~/.inputrc, for zsh ... I have `zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'`, which seems too complicated but that's what's in my zshrc.
    - galaxyLogic 5y ago
      You are right. Imagine that you had a fancy speech-recognition interface to your system. When you pronounce the name of a command, there's no difference whether you pronounce it uppercase or lowercase. Also imagine having two files in the same directory which differ only by case. What would be the benefit of being able to have two or more such files? Are there any use-cases for which case-sensitive file-system is better than case-insensitive one?
      - bayindirh 5y ago
        However, the pronunciation of the actual body text will trigger some words to be upper case, so there's definitely a meaning under that capitalized letters. Actually, not having the exact file may not provide a utility for you, or most of us, but searching for a file in a case sensitive manner, and getting ENOTFOUND just because it doesn't present in the way I searched is valuable from my point of view. Also, having a case-sensitive system is simpler from technical point of view, and prone to less bugs. This is especially true after UTF-8 become ubiquitous. Searching for an exact byte stream is much more simpler than a country dependent, exceptions filled search/match algorithm.
pxc 5y ago
I personally find the combination of case-sensitive filesystems with case-sensitive or smart-cased autocompletions pretty comfy. Most shells can be configured to behave that way, and Fish works that way by default.
Karellen 5y ago
The problem with case-sensitive filesystems is - which locale's case-sensitivity rules does the filesystem use? Remember that some systems may have multiple users (some may even have multiple simultaneous users) who use different locales. Or a single user might run different programs using different locales, e.g. if a program has a bad translation in their native language, they may prefer to run it with a different language that they also speak. A lot of computer systems only got rid of the problem of storing filenames in locale-specific character encodings (e.g. ISO-8859-*) relatively recently, by switching to a locale-neutral encoding (UTF-*/UCS-*). It would be nice if they could not repeat some of those problems with locale-specific filename matching rules. You could remove the problem of "requiring you to type the name with exact case" by having shells' autocomplete feature fix case issues. So you could type "vi foo<TAB>" and the autocomplete change that to "vi Foo.txt". That could have the advantage of also fixing combining character normalisation issues. And the question of "which locale's rules get used?" is easy - the locale of the shell doing the autocomplete.

bayindirh 5y ago

I don't honestly understand why a case sensitive file system is a problem. I think a case insensitive system is counterintuitive.

codedokode 5y ago
Because case insensitive filesystem doesn't require you to press Shift key when typing a command. Typing `ls /Program` requires one keypress more than `ls /program`. Also, it is easier to remember just a name rather than remember how exactly it is spelled.
- rickbad68 5y ago
  A case sensitive filesystem doesn't require you to hit shift either if you just call the directory "programs". Also, there are many ways to save your pinky from moving the huge distance to the shift-key other than an arbitrary restriction on all file names in the file system..
  - codedokode 5y ago
    What are the advantages of using a case-sensitive file system? I cannot imagine a situation when you need to create two files that differ only in letter case. This also would make program that create such files not portable.
    - hvdijk 5y ago
      The primary advantage for me is simplicity. Case insensitive file systems are complicated when you start dealing with non-ASCII characters and different software implementing the case rules with subtle differences. With case sensitive file systems you know exactly what you get.
      - jodrellblank 5y ago
        If you're going to move to non-ASCII characters, what about Unicode combining characters, do you have to care if your file named é is a single accented e or a pair of e-and-combining-accent before you can move it? If you shouldn't have to care, if there should be a layer of Unicode normalization happening, why is that okay but case normalisation is not okay? If you do have to care, then you no longer "know exactly what you get".
        hvdijk 5y ago
        > If you do have to care, then you no longer "know exactly what you get". You do know you get exactly what you put in, whether that is é (U+00E9) or é (U+0065 U+0301). When you reference files created by yourself, this is not a problem as realistically speaking, your input method will only have a convenient way of forming one of these, and it will consistently generate the same one every time. When you reference files created by someone else, this may be a problem but no more than e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i): from the user's perspective, the problem is pretty much avoided by selecting the file using tab completion, TUIs, GUIs, whatever you use.
        bayindirh 5y ago
        > e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i)... Just want to remind a little but extremely important thing: There's absolutely no guarantees that upper("i") is I. There's at least one language breaks that convention, and you won't believe how a big headache is that.
        hvdijk 5y ago
        Good point, Turkish uppercases i to İ. This adds complexity to the idea of case insensitive file systems even when only considering ASCII.
        jodrellblank 5y ago
        https://prnt.sc/257kxxa https://prnt.sc/257kxxa lowercase l and uppercase I are quite distinct. If you're going to select all your filenames with autocomplete, then why argue restrict me to case sensitive filenames? Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.
    - naniwaduni 5y ago
      Well, it means you don't need to do things with Unicode casefolding tables in the middle of your not-eating-data fs code.
- bayindirh 5y ago
  I think the utility of a real case-sensitive file system cannot be nullified with an "I need to press shift!" argument. Apple's APFS will create the folder as "Programs" if you use "mkdir Programs", and will give you an error when you try to create "programs". You can navigate with any case combination, but it just plays along like the capitalization you entered is present. It feels like a hack tbh. Another thing I noticed that I never notice that I'm pressing shift while capitalizing. It's not a deal-breaker issue for me (while this might sound like "it works for me", I'm sure that I'm not alone in that). Case insensitive systems created a lot of problems down the road. Esp. due to popularity of Windows. Program porting is a pain, using macOS with real case-sensitive mode is again a pain for some scenarios. It also encourages sloppy programming practices and "I don't case as long as it works" ism.
  - jodrellblank 5y ago
    > tbh What is this? It's not capitalised so it can't be an acronym or initialism. And your username doesn't start with a capital like a Proper Noun, so it's unreadable. This is my problem with case-sensitivity, it's not how humans use writing, think about writing, design fonts, etc. 'a' and 'A' are the same letter, they're the same letter in the alphabet, they are pronounced the same, they make the same word "apple" or "Apple" which is also pronounced the same and means the same, they could be rendered the same in a given font without making words unreadable or confusing (e.g. small caps fonts). If the computer isn't letting me use "apple" or "Apple" interchangably as I (the user, supposed to be in control here) wish, that isn't helping me, it's nitpickingly hindering me and making me implicitly care about character encoding values I can't even see. This is dreadful UX. Domain names aren't case sensitive, email addresses could be but generally aren't, usernames could be but generally aren't, phone numbers aren't, Twitter handles aren't, my bank cards have my name in ALL CAPS but it's still me, you wouldn't join an IRC channel and think it okay to use a nick which matches someone else's but for capitalisation differences, you know which book I mean when I say "the martian" and so does Google search and my email search, PostgreSQL table and column names aren't case sensitive. It's nice, convenient, helpful when identifiers aren't case sensitive.
    - GlitchMr 5y ago
- greiskul 5y ago
  If you are manually typing a command, then the shell could do this work instead of the file system, right? That's what the shell is for, to be the bridge between humans and the computer right. In a perfect system, you would type ls /p, and one of the suggestions of the tab completion would be /Program.
  - bayindirh 5y ago
    Bash normally doesn't do that, but there are a lot of options available for both Bash and ZSH, which can do much more than just "case insensitive matching".
    - yjftsjthsd-h 5y ago
      Specifically: For bash, `set completion-ignore-case on` in ~/.inputrc, for zsh ... I have `zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'`, which seems too complicated but that's what's in my zshrc.
  - galaxyLogic 5y ago
    You are right. Imagine that you had a fancy speech-recognition interface to your system. When you pronounce the name of a command, there's no difference whether you pronounce it uppercase or lowercase. Also imagine having two files in the same directory which differ only by case. What would be the benefit of being able to have two or more such files? Are there any use-cases for which case-sensitive file-system is better than case-insensitive one?
    - bayindirh 5y ago
      However, the pronunciation of the actual body text will trigger some words to be upper case, so there's definitely a meaning under that capitalized letters. Actually, not having the exact file may not provide a utility for you, or most of us, but searching for a file in a case sensitive manner, and getting ENOTFOUND just because it doesn't present in the way I searched is valuable from my point of view. Also, having a case-sensitive system is simpler from technical point of view, and prone to less bugs. This is especially true after UTF-8 become ubiquitous. Searching for an exact byte stream is much more simpler than a country dependent, exceptions filled search/match algorithm.

pxc 5y ago

I personally find the combination of case-sensitive filesystems with case-sensitive or smart-cased autocompletions pretty comfy. Most shells can be configured to behave that way, and Fish works that way by default.

Karellen 5y ago

The problem with case-sensitive filesystems is - which locale's case-sensitivity rules does the filesystem use? Remember that some systems may have multiple users (some may even have multiple simultaneous users) who use different locales. Or a single user might run different programs using different locales, e.g. if a program has a bad translation in their native language, they may prefer to run it with a different language that they also speak. A lot of computer systems only got rid of the problem of storing filenames in locale-specific character encodings (e.g. ISO-8859-*) relatively recently, by switching to a locale-neutral encoding (UTF-*/UCS-*). It would be nice if they could not repeat some of those problems with locale-specific filename matching rules. You could remove the problem of "requiring you to type the name with exact case" by having shells' autocomplete feature fix case issues. So you could type "vi foo<TAB>" and the autocomplete change that to "vi Foo.txt". That could have the advantage of also fixing combining character normalisation issues. And the question of "which locale's rules get used?" is easy - the locale of the shell doing the autocomplete.