7 ms·

Can you expand on why it's not the right answer? (For what?) The following arguments for case-sensitivity come to mind: - Different locales treat uppercasing

by geofft 8y ago

Can you expand on why it's not the right answer? (For what?) The following arguments for case-sensitivity come to mind: - Different locales treat uppercasing and lowercasing differently. In Turkish, for instance, the dotted and dotless letter I are two different letters, unlike languages where dotless uppercase I corresponds to dotted lowercase i. https://en.wikipedia.org/wiki/Dotted_and_dotless_I https://en.wikipedia.org/wiki/Dotted_and_dotless_I - There are common codebases that have files that differ only in case - for instance, the Linux kernel source tree itself has include/uapi/linux/netfilter/xt_rateest.h and include/uapi/linux/netfilter/xt_RATEEST.h with different contents. Can you supply some arguments against case-sensitivity?

lisper 8y ago
Because you never want to distinguish between never and Never and NEVER and NeVer. They are all the same word. The only time that English is case-sensitive is when you want to distinguish between a proper noun and a similarly-spelled word, like rich and Rich. But that hardly ever matters for identifiers, which is what file names are.
- geofft 8y ago
  Well, I think just about all of my filenames have personal names in them - they tend to start with /home/geofft. And "never," your original claim, is not "hardly ever," your revised claim. If there are valid use cases for case-sensitive filenames, it seems like it should be allowed on robustness-principle grounds, even if they are rare, unless they impose some disproportionate cost on users of the system. And filenames don't have to be in English, and usually aren't. "geofft" is not an English word; neither is "usr" or "etc" or "tmp," let alone "xt_RATEEST.h" or "/tmp/tmp.CGZ8Lq5f". And even for common nouns in English, case matters - the UCC for instance requires certain text to be "conspicuous," and gives one example as "a heading in capitals equal to or greater in size than the surrounding text." It's pretty common for lawyers to write "conspicuous" text in all caps to satisfy this requirement. In these cases, you do want to distinguish between "never," "Never," and "NEVER".
  - lisper 8y ago
    Nothing prevents you from having file names that mix cases in a case-insensitive file system. Case-insenstitive is not the same as case-oblivious. For example: $ echo asdf > Foo $ cat foo asdf That's much less error prone that allowing you to have distinct files named foo and Foo and FOO and FoO and fOo and fOO and...
    - geofft 8y ago
      How is this less error-prone?? Have you tried doing a git clone of Linux on a case-insensitive filesystem and running git status?
      - lisper 8y ago
        You mean the entire Linux kernel source tree? No. What happens?
- benj111 8y ago
  I AGREE, CASE DOESN'T COMMUNICATE ANYTHING. .... PARDON?
  - lisper 8y ago
    File names aren't used for communication, they are used to identify files, i.e. they are identifiers. Case-senstivity is never the right thing for identifiers. If you find yourself needing to distinguish two identifiers that differ only by case, you're doing something wrong.
    - geofft 8y ago
      You keep saying "never" despite having given a counterexample two comments ago. Besides, the point of a filesystem isn't to have opinions on right or wrong. It's to store files.
      - lisper 8y ago
        No, I didn't. I gave a counterexample where capitalization matters in English. It does not follow that this distinction ever matters in file names. In English the sentence, "The president of the company is rich," has a fundamentally different meaning than the sentence, "The president of the company is Rich." But when naming files, or choosing identifiers of any sort, if you have two distinct identifiers whose difference hinges only on capitalization, then you've chosen your identifiers poorly. In other words, the fact that capitalization actually matters in English on occasion is a bug, not a feature.
- asveikau 8y ago
  > The only time that English In the comment you replied to you've just been given a critical example, and it seems like you ignored it to talk just about English. Get a Turk and an Englishman (maybe have them walk into a bar). Show them the letter I and say, "what is the lowercase of this?" They give you different answers. So what should your kernel do about open("I.txt", O_RDONLY), when the directory entry has it as "i.txt"? Tell the Turk ENOENT, and give the Englishman a file descriptor? What happens when the user changes languages and has a filename stored somewhere? I would argue it's not the right layer to solve the problem.
  - lisper 8y ago
    This has nothing to do with case-sensitivity. This has to do with the fact that the glyph that looks like "I" stands for different characters in different languages. That is a problem in and of itself, but the way to solve that problem is not to introduce case-sensitivity and all of its associated problems into the file system.
    - geofft 8y ago
      What are the associated problems?
      - lisper 8y ago
        Ambiguity and the likelihood of making a mistake. If you have N>1 files whose names are only distinguished by capitalization it's going to be very hard to tell which is which. Do you want thisfile or thisFile or Thisfile or ThisFile? (Now imagine being asked that question verbally.)
        geofft 8y ago
        Should the filesystem also ban you from having files named both "thisfile" and "thisfilе" (Cyrillic lowercase ye)? In what character sets?
        8y ago
- scbrg 8y ago
  So, this one particular language is always case insensitive, except when it isn't. Well, then... that clears it all up.
deleted 8y ago
[deleted]
lemoncucumber 8y ago
If you want case insensitivity at all, the filesystem is the wrong layer at which to implement it. If instead you implemented it at much higher level in userspace then it would avoid a lot of complexity in the kernel and also result in a more useful feature for users. I primarily use a Mac, and I don't think I've ever taken advantage of the case insensitivity. The only time I open files is by choosing them graphically or by tab-completing their names in my terminal or my editor. The fact that case insensitivity is implemented at the filesystem layer rather than higher up means that my shell is still case sensitive, so I can't type "m<tab>" to autocomplete "Makefile" -- I have to type "M<tab>" instead. Things like Spotlight or my IDE, on the other hand, implement their own case-insensitive filename search that works fine regardless of whether the underlying filesystem is case-insensitive or not.
- Someone 8y ago
  ”so I can't type "m<tab>" to autocomplete "Makefile" -- I have to type "M<tab>" instead.” Many shells can do case-insensitive autocomplete. For example, in bash (https://askubuntu.com/a/87066 https://askubuntu.com/a/87066): set completion-ignore-case On in csh (https://stackoverflow.com/a/3306469 https://stackoverflow.com/a/3306469): set autolist = ambiguous set complete = enhance
  - lemoncucumber 8y ago
    Right, but that's exactly my point: having it in the filesystem doesn't help with actual day-to-day use cases, since you still have to reimplement it in the shell if you want it there.
yellowapple 8y ago
> In Turkish, for instance, the dotted and dotless letter I are two different letters, unlike languages where dotless uppercase I corresponds to dotted lowercase i. In this case, I'd argue that Unicode should provide codepoints for Turkish-specific versions of these letters (or at the very least a separate codepoint for a capitalized version of a dotless 'i', such that it can always be assumed that the Latin uppercase I is meant to be dotted and can be displayed as such when using a Turkish locale). Alternately, the Turkish alphabet should have its own Unicode codepoints entirely, thus circumventing this issue (just like how Latin A != Cyrillic А != Greek Α). > the Linux kernel source tree itself has include/uapi/linux/netfilter/xt_rateest.h and include/uapi/linux/netfilter/xt_RATEEST.h with different contents. That's a rather horrific code smell, and I'm surprised Linus didn't chew someone out on the LKML over it. If they have different contents, then they should have meaningfully-different names (in this case, maybe xt_rateest_target.h v. xt_rateest_match.h?). It looks like there might be other files there with the same issue, and they should be fixed, too (as should any other files that reference those headers). Like, just because it's possible to stick the barrel of a loaded 12-gauge in your mouth doesn't mean it's a good idea to do so.
- geofft 8y ago
  I don't necessarily disagree with either of these, but Unicode got encoded as it was and Linux got these files with these names and we can't go back and change it. (Even if the files get renamed, we have git history and stable release branches to think about.) The point of software is to deal with the world as it is, not as it should be. We've got pseudocode and research papers for the world as it should be.
  - yellowapple 8y ago
    We absolutely can change Unicode (that happens all the time, unless you think we've had emoji since the 90's), and we absolutely can rename those files (as they should be anyway, regardless of whether the filesystem is case-insensitive). If you need to dig through the git history or work with a branch that does not have that fix, then you can always mount a case-sensitive FS specifically for that purpose.

by geofft 8y ago

lisper 8y ago

Because you never want to distinguish between never and Never and NEVER and NeVer. They are all the same word. The only time that English is case-sensitive is when you want to distinguish between a proper noun and a similarly-spelled word, like rich and Rich. But that hardly ever matters for identifiers, which is what file names are.

geofft 8y ago
Well, I think just about all of my filenames have personal names in them - they tend to start with /home/geofft. And "never," your original claim, is not "hardly ever," your revised claim. If there are valid use cases for case-sensitive filenames, it seems like it should be allowed on robustness-principle grounds, even if they are rare, unless they impose some disproportionate cost on users of the system. And filenames don't have to be in English, and usually aren't. "geofft" is not an English word; neither is "usr" or "etc" or "tmp," let alone "xt_RATEEST.h" or "/tmp/tmp.CGZ8Lq5f". And even for common nouns in English, case matters - the UCC for instance requires certain text to be "conspicuous," and gives one example as "a heading in capitals equal to or greater in size than the surrounding text." It's pretty common for lawyers to write "conspicuous" text in all caps to satisfy this requirement. In these cases, you do want to distinguish between "never," "Never," and "NEVER".
- lisper 8y ago
  Nothing prevents you from having file names that mix cases in a case-insensitive file system. Case-insenstitive is not the same as case-oblivious. For example: $ echo asdf > Foo $ cat foo asdf That's much less error prone that allowing you to have distinct files named foo and Foo and FOO and FoO and fOo and fOO and...
  - geofft 8y ago
    How is this less error-prone?? Have you tried doing a git clone of Linux on a case-insensitive filesystem and running git status?
    - lisper 8y ago
      You mean the entire Linux kernel source tree? No. What happens?
benj111 8y ago
I AGREE, CASE DOESN'T COMMUNICATE ANYTHING. .... PARDON?
- lisper 8y ago
  File names aren't used for communication, they are used to identify files, i.e. they are identifiers. Case-senstivity is never the right thing for identifiers. If you find yourself needing to distinguish two identifiers that differ only by case, you're doing something wrong.
  - geofft 8y ago
    You keep saying "never" despite having given a counterexample two comments ago. Besides, the point of a filesystem isn't to have opinions on right or wrong. It's to store files.
    - lisper 8y ago
      No, I didn't. I gave a counterexample where capitalization matters in English. It does not follow that this distinction ever matters in file names. In English the sentence, "The president of the company is rich," has a fundamentally different meaning than the sentence, "The president of the company is Rich." But when naming files, or choosing identifiers of any sort, if you have two distinct identifiers whose difference hinges only on capitalization, then you've chosen your identifiers poorly. In other words, the fact that capitalization actually matters in English on occasion is a bug, not a feature.
asveikau 8y ago
> The only time that English In the comment you replied to you've just been given a critical example, and it seems like you ignored it to talk just about English. Get a Turk and an Englishman (maybe have them walk into a bar). Show them the letter I and say, "what is the lowercase of this?" They give you different answers. So what should your kernel do about open("I.txt", O_RDONLY), when the directory entry has it as "i.txt"? Tell the Turk ENOENT, and give the Englishman a file descriptor? What happens when the user changes languages and has a filename stored somewhere? I would argue it's not the right layer to solve the problem.
- lisper 8y ago
  This has nothing to do with case-sensitivity. This has to do with the fact that the glyph that looks like "I" stands for different characters in different languages. That is a problem in and of itself, but the way to solve that problem is not to introduce case-sensitivity and all of its associated problems into the file system.
  - geofft 8y ago
    What are the associated problems?
    - lisper 8y ago
      Ambiguity and the likelihood of making a mistake. If you have N>1 files whose names are only distinguished by capitalization it's going to be very hard to tell which is which. Do you want thisfile or thisFile or Thisfile or ThisFile? (Now imagine being asked that question verbally.)
      - geofft 8y ago
        Should the filesystem also ban you from having files named both "thisfile" and "thisfilе" (Cyrillic lowercase ye)? In what character sets?
        8y ago
scbrg 8y ago
So, this one particular language is always case insensitive, except when it isn't. Well, then... that clears it all up.

deleted 8y ago

[deleted]

lemoncucumber 8y ago

If you want case insensitivity at all, the filesystem is the wrong layer at which to implement it. If instead you implemented it at much higher level in userspace then it would avoid a lot of complexity in the kernel and also result in a more useful feature for users. I primarily use a Mac, and I don't think I've ever taken advantage of the case insensitivity. The only time I open files is by choosing them graphically or by tab-completing their names in my terminal or my editor. The fact that case insensitivity is implemented at the filesystem layer rather than higher up means that my shell is still case sensitive, so I can't type "m<tab>" to autocomplete "Makefile" -- I have to type "M<tab>" instead. Things like Spotlight or my IDE, on the other hand, implement their own case-insensitive filename search that works fine regardless of whether the underlying filesystem is case-insensitive or not.

Someone 8y ago
”so I can't type "m<tab>" to autocomplete "Makefile" -- I have to type "M<tab>" instead.” Many shells can do case-insensitive autocomplete. For example, in bash (https://askubuntu.com/a/87066 https://askubuntu.com/a/87066): set completion-ignore-case On in csh (https://stackoverflow.com/a/3306469 https://stackoverflow.com/a/3306469): set autolist = ambiguous set complete = enhance
- lemoncucumber 8y ago
  Right, but that's exactly my point: having it in the filesystem doesn't help with actual day-to-day use cases, since you still have to reimplement it in the shell if you want it there.

yellowapple 8y ago

> In Turkish, for instance, the dotted and dotless letter I are two different letters, unlike languages where dotless uppercase I corresponds to dotted lowercase i. In this case, I'd argue that Unicode should provide codepoints for Turkish-specific versions of these letters (or at the very least a separate codepoint for a capitalized version of a dotless 'i', such that it can always be assumed that the Latin uppercase I is meant to be dotted and can be displayed as such when using a Turkish locale). Alternately, the Turkish alphabet should have its own Unicode codepoints entirely, thus circumventing this issue (just like how Latin A != Cyrillic А != Greek Α). > the Linux kernel source tree itself has include/uapi/linux/netfilter/xt_rateest.h and include/uapi/linux/netfilter/xt_RATEEST.h with different contents. That's a rather horrific code smell, and I'm surprised Linus didn't chew someone out on the LKML over it. If they have different contents, then they should have meaningfully-different names (in this case, maybe xt_rateest_target.h v. xt_rateest_match.h?). It looks like there might be other files there with the same issue, and they should be fixed, too (as should any other files that reference those headers). Like, just because it's possible to stick the barrel of a loaded 12-gauge in your mouth doesn't mean it's a good idea to do so.

geofft 8y ago
I don't necessarily disagree with either of these, but Unicode got encoded as it was and Linux got these files with these names and we can't go back and change it. (Even if the files get renamed, we have git history and stable release branches to think about.) The point of software is to deal with the world as it is, not as it should be. We've got pseudocode and research papers for the world as it should be.
- yellowapple 8y ago
  We absolutely can change Unicode (that happens all the time, unless you think we've had emoji since the 90's), and we absolutely can rename those files (as they should be anyway, regardless of whether the filesystem is case-insensitive). If you need to dig through the git history or work with a branch that does not have that fix, then you can always mount a case-sensitive FS specifically for that purpose.