9 ms·

This is interesting, he also provided commentary on Fixing Unix/Linux/POSIX Filenames[1] [1] https://dwheeler.com/essays/fixing-unix-linux-filenames.html https

This is interesting, he also provided commentary on Fixing Unix/Linux/POSIX Filenames[1] [1] https://dwheeler.com/essays/fixing-unix-linux-filenames.html https://dwheeler.com/essays/fixing-unix-linux-filenames.html

tredre3 3y ago
Your link was an interesting read, he does make good points along with clear examples. I'm one of those who believes that linux paths should have more limitations. I also believe they should be case insensitive. Both opinions are highly controversial, unfortunately I guess it comes down to whether you believe paths are there to serve humans or machines. If you believe it should serve humans, then you understand why allowing a - prefix or case sensitivity causes unnecessary problems. On the other hand if you believe that paths are there to serve the machine, then the fewer "arbitrary" limitations the better. The devs know best, after all.
- fbdab103 3y ago
  >If you believe it should serve humans, then you understand why allowing a - prefix or case sensitivity causes unnecessary problems. Serving humans feels like it should take whatever garbage I shove down its throat and be happy to receive. Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx"
  - lmm 3y ago
    > Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx" I strongly disagree. Those sound exactly the same. If you had a physical filing cabinet and asked someone to get a document from the final folder (which is supposed to be the human-friendly metaphor we're using here), they would happily open a folder labeled FINAL, and be quite confused if you had distinct final and FINAL folders.
    - smackeyacky 3y ago
      If they shout the name, you know to look for the upper case version :-)
  - eviks 3y ago
    Humans don't speak binary garbage, so it's a disservice to them to happily swallow/spit it out Cap sensitivity is a much lesser mistake
  - coldtea 3y ago
    >Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx" Would they? Both are the "final resume" Word document... Humans don't care about case in distinguishing names. Considering case differences as important distinctions between names (of files in this case) is something instilled from using computers, not a human trait. That's a concern for coders, proof-readers, and other OCD types. Not to mention that the most popular Desktop OSes (Windows, MacOS) don't care for file case either. They preserve it for visual display is you set it, but two filenames with differences in case only are the same file - and can't coexist.
- jackthetab 3y ago
  > The devs know best, after all. Which may be why they gave us these options to put in our ~/.inputrc ``` set completion-ignore-case on set completion-prefix-display-length 2 set completion-map-case on ``` Technically filenames and paths are still case-sensitive, but with these settings they practically aren't.
  - jackthetab 3y ago
    ARGH! How does one do code on this site? I meant: set completion-ignore-case on set completion-prefix-display-length 2 set completion-map-case on
    - deleted 3y ago
      [deleted]
    - deleted 3y ago
      [deleted]
    - js2 3y ago
      Indent by 4 spaces. like this
      - tsimionescu 3y ago
        You actually indent by 2 spaces, not 4: Like this 4 spaces is a Markdown thing.
        js2 3y ago
        My bad, I knew that at some point. The rules are actually linked to from the well-hidden "help" at the bottom right of the comment box: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
    - chasil 3y ago
      https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
- scbrg 3y ago
  Every time I see someone argue for case insensitivity I remember this excellent Hacker News comment on the issue: https://news.ycombinator.com/item?id=29755865 https://news.ycombinator.com/item?id=29755865 It's definitely more complex than you'd naively think it is.
  - arp242 3y ago
    People are making things more complex than they are. No one said you need to convert between scripts or muck about with fullwidth variants or stuff like that; "semantically identical" is not the same as "case insensitive". That post is going of on a "if you want case-insensitivity then you must also treat color and colour as identical!" tangent, which is just silly and not what anyone has ever argued for. The scripts with case translations that are more complex than a simple 1-to-1 mapping are the exception, not the rule (German, Greek, Turkish, Lithuanian). These can be dealt with. It's certainly not the case that it "will only work for English and a few European languages"; it will work for much of the world. The fact of the matter is, two out of the three most used systems today are case-insensitive, and Linux/POSIX being the exception is rather painful.
    - lelanthran 3y ago
      > It's certainly not the case that it "will only work for English and a few European languages"; it will work for much of the world. I respectfully disagree. Consistently broken in the same way for everyone is better than unreliably working for some people, reliably working for other people, unreliably broken for a third group and reliably broken for a fourth group. Filenames should be created as the user typed it - don't change the input before storing it. Filenames should be displayed as the user typed it - don't render output different to what was input. Tools should match filenames as the user expects it - in this case (hehe) it should perform a case-insensitive match. Ambiguity resolution has to be performed in the case where there is more than one match. cat > MyFile.txt # Create 'MyFile.txt' ls # Display 'MyFile.txt' echo myfile* # Display 'MyFile.txt' vim myfile.txt # Opens 'MyFile.txt' The first problem with this is in automated shell scripts: there is no interactivity so the script can't prompt the user "Which of the following files did you mean to open: [MyFile.txt, myfile.txt]?". This means that a script which relies on 'foo.txt' will fail if someone creates a 'Foo.txt' in the same directory. Another issue with this is that userspace calls to `open()`, `stat()`, etc aren't able to fail and return a list of case-insensitive matches in the case of ambiguity. This makes handling the ambiguity the applications (very complex) problem - before any `open(fname)` call, the application will first have to `scandir()` to get all the filenames, then perform a case-insensitive match against the list to get all the CI matches, then prompt the user to select the correct one. > The fact of the matter is, two out of the three most used systems today are case-insensitive I think it's more that they are case-aware than case-insensitive; after all the filesystem certainly stores the case, and they both retrieve the case correctly. It's the tooling that faces the user which "fix" cases to prevent two files with the same name in different cases being created. You can certainly create file 'FOO' and file 'foo' on Windows in the same directory, and then the tools tend to randomly open only one of them no matter which on the user clicked on.[1] Which is why I say that the actual filesystem is case-sensitive. The user programs normalise the case for the user. [1] EDIT: I accidentally did this once, and had to write another small tool to remove files with the filename as typed because the normal tools (del, explorer.exe) just randomly choose one file to remove.

tredre3 3y ago

Your link was an interesting read, he does make good points along with clear examples. I'm one of those who believes that linux paths should have more limitations. I also believe they should be case insensitive. Both opinions are highly controversial, unfortunately I guess it comes down to whether you believe paths are there to serve humans or machines. If you believe it should serve humans, then you understand why allowing a - prefix or case sensitivity causes unnecessary problems. On the other hand if you believe that paths are there to serve the machine, then the fewer "arbitrary" limitations the better. The devs know best, after all.

fbdab103 3y ago
>If you believe it should serve humans, then you understand why allowing a - prefix or case sensitivity causes unnecessary problems. Serving humans feels like it should take whatever garbage I shove down its throat and be happy to receive. Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx"
- lmm 3y ago
  > Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx" I strongly disagree. Those sound exactly the same. If you had a physical filing cabinet and asked someone to get a document from the final folder (which is supposed to be the human-friendly metaphor we're using here), they would happily open a folder labeled FINAL, and be quite confused if you had distinct final and FINAL folders.
  - smackeyacky 3y ago
    If they shout the name, you know to look for the upper case version :-)
- eviks 3y ago
  Humans don't speak binary garbage, so it's a disservice to them to happily swallow/spit it out Cap sensitivity is a much lesser mistake
- coldtea 3y ago
  >Similarly, I think many humans would like to differentiate between, "resumefinal.docx" and "resumeFINAL.docx" Would they? Both are the "final resume" Word document... Humans don't care about case in distinguishing names. Considering case differences as important distinctions between names (of files in this case) is something instilled from using computers, not a human trait. That's a concern for coders, proof-readers, and other OCD types. Not to mention that the most popular Desktop OSes (Windows, MacOS) don't care for file case either. They preserve it for visual display is you set it, but two filenames with differences in case only are the same file - and can't coexist.
jackthetab 3y ago
> The devs know best, after all. Which may be why they gave us these options to put in our ~/.inputrc ``` set completion-ignore-case on set completion-prefix-display-length 2 set completion-map-case on ``` Technically filenames and paths are still case-sensitive, but with these settings they practically aren't.
- jackthetab 3y ago
  ARGH! How does one do code on this site? I meant: set completion-ignore-case on set completion-prefix-display-length 2 set completion-map-case on
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - js2 3y ago
    Indent by 4 spaces. like this
    - tsimionescu 3y ago
      You actually indent by 2 spaces, not 4: Like this 4 spaces is a Markdown thing.
      - js2 3y ago
        My bad, I knew that at some point. The rules are actually linked to from the well-hidden "help" at the bottom right of the comment box: https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
  - chasil 3y ago
    https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
scbrg 3y ago
Every time I see someone argue for case insensitivity I remember this excellent Hacker News comment on the issue: https://news.ycombinator.com/item?id=29755865 https://news.ycombinator.com/item?id=29755865 It's definitely more complex than you'd naively think it is.
- arp242 3y ago
  People are making things more complex than they are. No one said you need to convert between scripts or muck about with fullwidth variants or stuff like that; "semantically identical" is not the same as "case insensitive". That post is going of on a "if you want case-insensitivity then you must also treat color and colour as identical!" tangent, which is just silly and not what anyone has ever argued for. The scripts with case translations that are more complex than a simple 1-to-1 mapping are the exception, not the rule (German, Greek, Turkish, Lithuanian). These can be dealt with. It's certainly not the case that it "will only work for English and a few European languages"; it will work for much of the world. The fact of the matter is, two out of the three most used systems today are case-insensitive, and Linux/POSIX being the exception is rather painful.
  - lelanthran 3y ago
    > It's certainly not the case that it "will only work for English and a few European languages"; it will work for much of the world. I respectfully disagree. Consistently broken in the same way for everyone is better than unreliably working for some people, reliably working for other people, unreliably broken for a third group and reliably broken for a fourth group. Filenames should be created as the user typed it - don't change the input before storing it. Filenames should be displayed as the user typed it - don't render output different to what was input. Tools should match filenames as the user expects it - in this case (hehe) it should perform a case-insensitive match. Ambiguity resolution has to be performed in the case where there is more than one match. cat > MyFile.txt # Create 'MyFile.txt' ls # Display 'MyFile.txt' echo myfile* # Display 'MyFile.txt' vim myfile.txt # Opens 'MyFile.txt' The first problem with this is in automated shell scripts: there is no interactivity so the script can't prompt the user "Which of the following files did you mean to open: [MyFile.txt, myfile.txt]?". This means that a script which relies on 'foo.txt' will fail if someone creates a 'Foo.txt' in the same directory. Another issue with this is that userspace calls to `open()`, `stat()`, etc aren't able to fail and return a list of case-insensitive matches in the case of ambiguity. This makes handling the ambiguity the applications (very complex) problem - before any `open(fname)` call, the application will first have to `scandir()` to get all the filenames, then perform a case-insensitive match against the list to get all the CI matches, then prompt the user to select the correct one. > The fact of the matter is, two out of the three most used systems today are case-insensitive I think it's more that they are case-aware than case-insensitive; after all the filesystem certainly stores the case, and they both retrieve the case correctly. It's the tooling that faces the user which "fix" cases to prevent two files with the same name in different cases being created. You can certainly create file 'FOO' and file 'foo' on Windows in the same directory, and then the tools tend to randomly open only one of them no matter which on the user clicked on.[1] Which is why I say that the actual filesystem is case-sensitive. The user programs normalise the case for the user. [1] EDIT: I accidentally did this once, and had to write another small tool to remove files with the filename as typed because the normal tools (del, explorer.exe) just randomly choose one file to remove.