4 ms·

Oh god. I already get upset enough by spaces in a file name, although I realise that fight is basically lost now!

enriquto 2y ago
As a fellow spaces-in-filenames-hater, the fight is not lost. We are on the brink of winning it; it's just a mount option away! While we cannot avoid that people hit the spacebar when writing a filename on a gui, this does not mean at all that the resulting filename itself need contain a plain space character. Those spaces can and should be transparently translated to non-breaking space characters at some point. Maybe by the gui itself, or more robustly by the filesystem. This would make everybody happy: gui users and naive shell script writers.
- poincaredisk 2y ago
  >Those spaces can and should be transparently translated to non-breaking space characters at some point Why? This just introduces more complexity and interoperability headaches for seemingly no reason.
  - enriquto 2y ago
    > Why? In order to preserve the sacrosanct simplicity of naive shell scripts. Seems like a very noble goal to me. The only unexpexted compexity arises when you want to deal with filenames having mixed spaces and nbsps. But I'd say that people who do that had it coming.
    - alexvitkov 2y ago
      If you want simple shell scripts to work, make an actually good shell language without all the footguns. The filesystem is way more important than /bin/sh and and any complexity added there will trickle down to all programs, not just shell scripts. It's not worth adding hacks on the FS to patch defects in poorly written shell scripts (which are being replaced en masse with python/nodejs/even weirder yaml files/systemd units/etc... anyways)
      - ksp-atlas 2y ago
        nushell uses real lists for things which means you don't need to care about seperators except when dealing with external system things
      - consteval 2y ago
        Whitespace in filenames in general is difficult to deal with. Many, maybe most, programs get it wrong. It's not just about shell scripts, many GUI programs fail to handle those files properly too.
        alexvitkov 2y ago
        When GUI programs mishandle filenames with spaces, IME it's usually because they spawn a subshell in a naive way (system("rm " + filename)). To mishandle spaces you have to split an input w/ filenames by whitespace, which is not that common of an operation outside of a shell.
        InfiniteRand 2y ago
        My favorite file+space issues is spaces at the end of file names, especially when you copy and paste text, or text gets trimmed from an input box, or the person forgets to trim space from an input box...
        nradov 2y ago
        The vast majority of Windows and MacOS programs get it right.
        consteval 2y ago
        No, no they don't - you just don't notice when they get it wrong, and you also don't name your files stupid things (I imagine). If you actually test this, you'll realize a ton of Windows programs get it wrong. Also, in general this is a poor argument. The goal of Linux isn't to be as much like Windows as possible, because Windows sucks ass. Nobody in their right mind would use Linux if it was just Windows but, presumably, shittier. The entire appeal of Linux is that it isn't Windows, and it isn't MacOS.
    - lifthrasiir 2y ago
      Simplicity doesn't always mean stupidity. The simple but functional shell that correctly handles whitespaces without much hassle was already available since 90s, namely rc which is also found in Plan 9. Adopting rc's string concatenator `^` in POSIXy shells shouldn't be too hard.
- vbezhenar 2y ago
  Yep, works today: sh-3.2$ f='Hello world' sh-3.2$ echo $f Hello world sh-3.2$ for i in $f; do echo $i; done Hello world sh-3.2$ f='Hello\xC2\xA0world' sh-3.2$ echo $f Hello world sh-3.2$ for i in $f; do echo $i; done Hello world
  - stouset 2y ago
    Just always quote variable interpolation and you will never have problems. sh-3.2$ f='Hello world' sh-3.2$ echo "${f}" Hello world sh-3.2$ for i in "${f}"; do echo "${i}"; done Hello world sh-3.2$
- chasil 2y ago
  It would be really nice if there was a mount option that would quietly remove spaces in filenames, or convert them to an underscore. If I had it, I would use it today.
curt15 2y ago
Didn't Windows name "Program Files" with a space to force application developers to handle spaces in paths properly?
- ape4 2y ago
  Not to mention C:\Program Files (x86)
  - account42 2y ago
    And C:\Programme and other localized variants to force people to go through the proper APIs instead of hardcoding paths.
- pjmlp 2y ago
  In theory yes, in practice to this day many people don't bother how to learn how to deal with pathnames in a proper way.
  - inetknght 2y ago
    Top difficulties in computer science: 1. naming things 2. cache coherency 3. off-by-one errors ??? 4. quoting pathnames
    - nneonneo 2y ago
      Eh, maybe. In practice I usually do all my moderately-heavy filesystem scripting in Python these days, for which pathname quoting is just a complete non-issue. Of course, I still use a shell for quick-and-dirty stuff, but usually only for pretty simple tasks where the simplest quoting setup ("$i") suffices.
    - hawski 2y ago
      I would replace 4 with parameter expansion rules.
- mmcdermott 2y ago
  For the longest time you could get away with this in cmd: > dir c:\progra~1 So if forcing people to handle spaces was the goal, it took a long time to force it.
jonhohle 2y ago
Convince (force?) your team to use make and soon everyone will forget spaces in file names are even a thing!
- taneliv 2y ago
  My team already uses `make` but there's no reason for me to run it in my Downloads folders. File names in there are sometimes wild. Yet I expect command line tools to work with them. If they will cease to do so, I will have to start using non-POSIX variants of those tools, I guess.

As a fellow spaces-in-filenames-hater, the fight is not lost. We are on the brink of winning it; it's just a mount option away! While we cannot avoid that people hit the spacebar when writing a filename on a gui, this does not mean at all that the resulting filename itself need contain a plain space character. Those spaces can and should be transparently translated to non-breaking space characters at some point. Maybe by the gui itself, or more robustly by the filesystem. This would make everybody happy: gui users and naive shell script writers.

poincaredisk 2y ago
>Those spaces can and should be transparently translated to non-breaking space characters at some point Why? This just introduces more complexity and interoperability headaches for seemingly no reason.
- enriquto 2y ago
  > Why? In order to preserve the sacrosanct simplicity of naive shell scripts. Seems like a very noble goal to me. The only unexpexted compexity arises when you want to deal with filenames having mixed spaces and nbsps. But I'd say that people who do that had it coming.
  - alexvitkov 2y ago
    If you want simple shell scripts to work, make an actually good shell language without all the footguns. The filesystem is way more important than /bin/sh and and any complexity added there will trickle down to all programs, not just shell scripts. It's not worth adding hacks on the FS to patch defects in poorly written shell scripts (which are being replaced en masse with python/nodejs/even weirder yaml files/systemd units/etc... anyways)
    - ksp-atlas 2y ago
      nushell uses real lists for things which means you don't need to care about seperators except when dealing with external system things
    - consteval 2y ago
      Whitespace in filenames in general is difficult to deal with. Many, maybe most, programs get it wrong. It's not just about shell scripts, many GUI programs fail to handle those files properly too.
      - alexvitkov 2y ago
        When GUI programs mishandle filenames with spaces, IME it's usually because they spawn a subshell in a naive way (system("rm " + filename)). To mishandle spaces you have to split an input w/ filenames by whitespace, which is not that common of an operation outside of a shell.
        InfiniteRand 2y ago
        My favorite file+space issues is spaces at the end of file names, especially when you copy and paste text, or text gets trimmed from an input box, or the person forgets to trim space from an input box...
      - nradov 2y ago
        The vast majority of Windows and MacOS programs get it right.
        consteval 2y ago
        No, no they don't - you just don't notice when they get it wrong, and you also don't name your files stupid things (I imagine). If you actually test this, you'll realize a ton of Windows programs get it wrong. Also, in general this is a poor argument. The goal of Linux isn't to be as much like Windows as possible, because Windows sucks ass. Nobody in their right mind would use Linux if it was just Windows but, presumably, shittier. The entire appeal of Linux is that it isn't Windows, and it isn't MacOS.
  - lifthrasiir 2y ago
    Simplicity doesn't always mean stupidity. The simple but functional shell that correctly handles whitespaces without much hassle was already available since 90s, namely rc which is also found in Plan 9. Adopting rc's string concatenator `^` in POSIXy shells shouldn't be too hard.
vbezhenar 2y ago
Yep, works today: sh-3.2$ f='Hello world' sh-3.2$ echo $f Hello world sh-3.2$ for i in $f; do echo $i; done Hello world sh-3.2$ f='Hello\xC2\xA0world' sh-3.2$ echo $f Hello world sh-3.2$ for i in $f; do echo $i; done Hello world
- stouset 2y ago
  Just always quote variable interpolation and you will never have problems. sh-3.2$ f='Hello world' sh-3.2$ echo "${f}" Hello world sh-3.2$ for i in "${f}"; do echo "${i}"; done Hello world sh-3.2$
chasil 2y ago
It would be really nice if there was a mount option that would quietly remove spaces in filenames, or convert them to an underscore. If I had it, I would use it today.

curt15 2y ago

Didn't Windows name "Program Files" with a space to force application developers to handle spaces in paths properly?

ape4 2y ago
Not to mention C:\Program Files (x86)
- account42 2y ago
  And C:\Programme and other localized variants to force people to go through the proper APIs instead of hardcoding paths.
pjmlp 2y ago
In theory yes, in practice to this day many people don't bother how to learn how to deal with pathnames in a proper way.
- inetknght 2y ago
  Top difficulties in computer science: 1. naming things 2. cache coherency 3. off-by-one errors ??? 4. quoting pathnames
  - nneonneo 2y ago
    Eh, maybe. In practice I usually do all my moderately-heavy filesystem scripting in Python these days, for which pathname quoting is just a complete non-issue. Of course, I still use a shell for quick-and-dirty stuff, but usually only for pretty simple tasks where the simplest quoting setup ("$i") suffices.
  - hawski 2y ago
    I would replace 4 with parameter expansion rules.
mmcdermott 2y ago
For the longest time you could get away with this in cmd: > dir c:\progra~1 So if forcing people to handle spaces was the goal, it took a long time to force it.

jonhohle 2y ago

Convince (force?) your team to use make and soon everyone will forget spaces in file names are even a thing!

taneliv 2y ago
My team already uses `make` but there's no reason for me to run it in my Downloads folders. File names in there are sometimes wild. Yet I expect command line tools to work with them. If they will cease to do so, I will have to start using non-POSIX variants of those tools, I guess.