7 ms·

If only all UI applications replaced whitespace with underscores when making files. I know... that will never happen and won't help with existing files.

by ape4 3y ago

JadeNB 3y ago
No, please no! Let's first figure out what it means to work with whitespace properly, then update our tools to do it. Behind-the-scenes mangling to work around flawed tools seems to be the macOS favored solution, with .DS_Store files dropped silently everywhere, and "case-insensitive but case-respecting" by default file systems, and increasingly byzantine approaches to file management so that it's harder and harder to figure out where anything is actually stored, which defeats the whole point of a Unix underlayer ….
- pasc1878 3y ago
  Well .DS_Stores are just used by Finder - but do show the limitations of Unix Filesystems. Where should the data they hold be stored? The macOS API is really Foundation - a layer above POSIX - if you use that then the filesystem is not that bad. It gives another solution to meta data like .DS_Store which is bundles. Bundles are an object in the Foundation API which you manipulate as one - on the filesystem they are a directory. Think of a bundle as a zipfile that you can look at using POSIX tools. The files being in odd places is for similar reasons to XDG"s attempt at cleaning up Unix. I think that the MacOS/NeXT structure predates XDG.
- thesuperbigfrog 3y ago
  >> Let's first figure out what it means to work with whitespace properly What does it mean to work with whitespace properly? When commands are entered at the command line and a shell is parsing, how do you distinguish between whitespace between commands, command parameters and switches, filenames that include whitespace characters, paths that include whitespace characters, etc. ? It is a difficult question that does not have good answers.
  - arp242 3y ago
    Not expanding whitespace on $var would be a huge improvement; shells like rc and zsh have been doing that since the early 90s and it's a huge improvement, so hardly a new innovation. Bash refuses to implement this even as an option because ... reasons? Significant chunks of bash are still written in K&R C today, so it's not exactly cutting edge... Autocompletion works well enough for doing things like "ls file with space": either just as "ls file<Tab>" or "ls 'file<Tab" (in zsh it picks up on a starting ' or " so you don't end up with loads of backslashes).
    - teo_zero 3y ago
      On the other hand, not splitting words at spaces during variable expansion would make impossible things like: OPTS="-a -b -c" foo $OPTS
      - o11c 3y ago
        Just use an array. POSIX sh is a useless target, all serious shells support arbitrary arrays.
      - arp242 3y ago
        Use $=opts in zsh for explicit splitting. Better would to be use an array though: 'opts=(-a -b -c)' and then just 'foo $opts'. I'm not sure about rc on this as I'm not too familiar with rc, but I'd be surprised if there wasn't a way to do this.
- foundart 3y ago
  > Let's first figure out what it means to work with whitespace properly A problem with that: What is 'properly'? The current solution is one take on how to do it properly.
- dspillett 3y ago
  > Let's first figure out what it means to work with whitespace properly We know how. Using structure beyond a line of text. The problem with that is then your shell and all the command you run through it need to agree on that structure and implement it. PowerShell works this way, though has a few of its own gotchas (mangling binary data if you aren't careful being one of them). A couple of shells for unix-a-like systems do to, but it falls apart when you start calling de-facto standard tools that are not retro-fitted to support accepting and outputting that structure. Once you have decided on the “proper way” you'll find that was the easy part and getting that way implemented in enough places that it is useful to be a somewhat Sisyphean task. IMO the only way to do spaces in filenames properly without an impractically radical change to all your tooling, is to consider spaces in filenames to be a bug. But good luck getting the world to accept that!
- kergonath 3y ago
  > "case-insensitive but case-respecting" by default file systems That is actually the best policy. Case sensitivity is unnatural and weird; we don’t think by default of readme, Readme, and README as being 3 different things. But then, when the user chose a file’s name, it’s better if the file actually has that name, and keeps it consistently regardless of how the user interacts with the file system (hence the case-preserving). The case-preserving aspect has no effect on anything outside the kernel. For all intent and purposes, it is case insensitive for any userspace code.
  - SAI_Peregrinus 3y ago
    I disagree. It's really weird that "I" and "i" are somehow the same character (but the former is used at the start of a sentence or when it's the entire word only), or that "מ" (U+05DE) and "ם" (U+05DD) are the same character but the latter is only used at the end of a word. They're visibly distinct! Only a minority of languages have multiple cases, most scripts are unicameral (having only one case).
    - kergonath 3y ago
      I am not sure I follow. Are you advocating for doing away with capitals entirely?
      - xmcqdpt2 3y ago
        i support this. capitals are basically useless anyway!
      - SAI_Peregrinus 3y ago
        No, I'm saying that case insensitivity is almost always a bad idea, especially as a default. It's useful (sometimes) for search, but even then not always what you want. Case often carries semantic information, it's not purely syntactic.
  - ElectricalUnion 3y ago
    > Case sensitivity is unnatural and weird; Case sensitivity is naive and simple, case-insensitive systems are complex and require Case Mappings [1] and Normalization [2] and those are ugly, unless you want a half-assed system that is case-insensitive only when you only use ASCII. [1] https://unicode-org.github.io/icu/userguide/transforms/casemappings.html https://unicode-org.github.io/icu/userguide/transforms/casem... > There are different case mappings for different locales. For instance, unlike English, the character Latin small letter ‘i’ in Turkish has an equivalent Latin capital letter ‘I’ with dot above ( \u0130 ‘İ’). > In general: > case mapping can change the number of code points and/or code units of a string, > is language-sensitive (results may differ depending on language), and > is context-sensitive (a character in the input string may map differently depending on surrounding characters). [2] https://unicode-org.github.io/icu/userguide/transforms/normalization/ https://unicode-org.github.io/icu/userguide/transforms/norma...
foundart 3y ago
As a MacOS user, I have long wished that Apple would make it possible to configure a custom file naming policy for the the dialog boxes presented when saving files. In my dream world it would enable changing "The shell and its crappy handling of whitespace _ Hacker News.html" to "The-shell-and-its-crappy-handling-of-whitespace_Hacker-News.html"
kergonath 3y ago
That’s a typical software engineer solution, though. In the real world, putting spaces in file names is much more natural than avoiding it at all costs. We find it distasteful only because we have PTSD from using such dumb tools. The real solution is something that does not split a variable on spaces, or that offers some control about how it splits things. These exist, there is no excuse to stick to bash in this day and age. We really don’t need another layer of obfuscation between GUIs and the underlying file system.
- saurik 3y ago
  You could make the same argument about putting slashes in filenames (or, I think, even colons on old versions of Mac OS), and yet we accept that limitation generally without question. FWIW, I generally make sure most of my shell scripts support spaces in filenames--and am in fact more pedantic about it than almost anyone I have ever met--but for a developer tool as part of a build system or whatnot? No: developers should know better and I have no sympathy if they insist on spaces in filenames as it just isn't worth the productivity loss to everyone across the entire stack.

If only all UI applications replaced whitespace with underscores when making files. I know... that will never happen and won't help with existing files.

by ape4 3y ago

If only all UI applications replaced whitespace with underscores when making files. I know... that will never happen and won't help with existing files.

JadeNB 3y ago

No, please no! Let's first figure out what it means to work with whitespace properly, then update our tools to do it. Behind-the-scenes mangling to work around flawed tools seems to be the macOS favored solution, with .DS_Store files dropped silently everywhere, and "case-insensitive but case-respecting" by default file systems, and increasingly byzantine approaches to file management so that it's harder and harder to figure out where anything is actually stored, which defeats the whole point of a Unix underlayer ….

pasc1878 3y ago
Well .DS_Stores are just used by Finder - but do show the limitations of Unix Filesystems. Where should the data they hold be stored? The macOS API is really Foundation - a layer above POSIX - if you use that then the filesystem is not that bad. It gives another solution to meta data like .DS_Store which is bundles. Bundles are an object in the Foundation API which you manipulate as one - on the filesystem they are a directory. Think of a bundle as a zipfile that you can look at using POSIX tools. The files being in odd places is for similar reasons to XDG"s attempt at cleaning up Unix. I think that the MacOS/NeXT structure predates XDG.
thesuperbigfrog 3y ago
>> Let's first figure out what it means to work with whitespace properly What does it mean to work with whitespace properly? When commands are entered at the command line and a shell is parsing, how do you distinguish between whitespace between commands, command parameters and switches, filenames that include whitespace characters, paths that include whitespace characters, etc. ? It is a difficult question that does not have good answers.
- arp242 3y ago
  Not expanding whitespace on $var would be a huge improvement; shells like rc and zsh have been doing that since the early 90s and it's a huge improvement, so hardly a new innovation. Bash refuses to implement this even as an option because ... reasons? Significant chunks of bash are still written in K&R C today, so it's not exactly cutting edge... Autocompletion works well enough for doing things like "ls file with space": either just as "ls file<Tab>" or "ls 'file<Tab" (in zsh it picks up on a starting ' or " so you don't end up with loads of backslashes).
  - teo_zero 3y ago
    On the other hand, not splitting words at spaces during variable expansion would make impossible things like: OPTS="-a -b -c" foo $OPTS
    - o11c 3y ago
      Just use an array. POSIX sh is a useless target, all serious shells support arbitrary arrays.
    - arp242 3y ago
      Use $=opts in zsh for explicit splitting. Better would to be use an array though: 'opts=(-a -b -c)' and then just 'foo $opts'. I'm not sure about rc on this as I'm not too familiar with rc, but I'd be surprised if there wasn't a way to do this.
foundart 3y ago
> Let's first figure out what it means to work with whitespace properly A problem with that: What is 'properly'? The current solution is one take on how to do it properly.
dspillett 3y ago
> Let's first figure out what it means to work with whitespace properly We know how. Using structure beyond a line of text. The problem with that is then your shell and all the command you run through it need to agree on that structure and implement it. PowerShell works this way, though has a few of its own gotchas (mangling binary data if you aren't careful being one of them). A couple of shells for unix-a-like systems do to, but it falls apart when you start calling de-facto standard tools that are not retro-fitted to support accepting and outputting that structure. Once you have decided on the “proper way” you'll find that was the easy part and getting that way implemented in enough places that it is useful to be a somewhat Sisyphean task. IMO the only way to do spaces in filenames properly without an impractically radical change to all your tooling, is to consider spaces in filenames to be a bug. But good luck getting the world to accept that!
kergonath 3y ago
> "case-insensitive but case-respecting" by default file systems That is actually the best policy. Case sensitivity is unnatural and weird; we don’t think by default of readme, Readme, and README as being 3 different things. But then, when the user chose a file’s name, it’s better if the file actually has that name, and keeps it consistently regardless of how the user interacts with the file system (hence the case-preserving). The case-preserving aspect has no effect on anything outside the kernel. For all intent and purposes, it is case insensitive for any userspace code.
- SAI_Peregrinus 3y ago
  I disagree. It's really weird that "I" and "i" are somehow the same character (but the former is used at the start of a sentence or when it's the entire word only), or that "מ" (U+05DE) and "ם" (U+05DD) are the same character but the latter is only used at the end of a word. They're visibly distinct! Only a minority of languages have multiple cases, most scripts are unicameral (having only one case).
  - kergonath 3y ago
    I am not sure I follow. Are you advocating for doing away with capitals entirely?
    - xmcqdpt2 3y ago
      i support this. capitals are basically useless anyway!
    - SAI_Peregrinus 3y ago
      No, I'm saying that case insensitivity is almost always a bad idea, especially as a default. It's useful (sometimes) for search, but even then not always what you want. Case often carries semantic information, it's not purely syntactic.
- ElectricalUnion 3y ago
  > Case sensitivity is unnatural and weird; Case sensitivity is naive and simple, case-insensitive systems are complex and require Case Mappings [1] and Normalization [2] and those are ugly, unless you want a half-assed system that is case-insensitive only when you only use ASCII. [1] https://unicode-org.github.io/icu/userguide/transforms/casemappings.html https://unicode-org.github.io/icu/userguide/transforms/casem... > There are different case mappings for different locales. For instance, unlike English, the character Latin small letter ‘i’ in Turkish has an equivalent Latin capital letter ‘I’ with dot above ( \u0130 ‘İ’). > In general: > case mapping can change the number of code points and/or code units of a string, > is language-sensitive (results may differ depending on language), and > is context-sensitive (a character in the input string may map differently depending on surrounding characters). [2] https://unicode-org.github.io/icu/userguide/transforms/normalization/ https://unicode-org.github.io/icu/userguide/transforms/norma...

foundart 3y ago

As a MacOS user, I have long wished that Apple would make it possible to configure a custom file naming policy for the the dialog boxes presented when saving files. In my dream world it would enable changing "The shell and its crappy handling of whitespace _ Hacker News.html" to "The-shell-and-its-crappy-handling-of-whitespace_Hacker-News.html"

kergonath 3y ago

That’s a typical software engineer solution, though. In the real world, putting spaces in file names is much more natural than avoiding it at all costs. We find it distasteful only because we have PTSD from using such dumb tools. The real solution is something that does not split a variable on spaces, or that offers some control about how it splits things. These exist, there is no excuse to stick to bash in this day and age. We really don’t need another layer of obfuscation between GUIs and the underlying file system.

saurik 3y ago
You could make the same argument about putting slashes in filenames (or, I think, even colons on old versions of Mac OS), and yet we accept that limitation generally without question. FWIW, I generally make sure most of my shell scripts support spaces in filenames--and am in fact more pedantic about it than almost anyone I have ever met--but for a developer tool as part of a build system or whatnot? No: developers should know better and I have no sympathy if they insist on spaces in filenames as it just isn't worth the productivity loss to everyone across the entire stack.