6 ms·

Still way too many libraries and programs can't handle spaces in filenames. And shells and other programs still have problems with perfectly legal characters i

Still way too many libraries and programs can't handle spaces in filenames. And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'.

chrisseaton 5y ago
> And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'. Without asking you to always quote and escape every file name - what alternative is there? If they tried this you'd probably find you didn't like it.
- zeroimpl 5y ago
  Not exactly - the problem is mostly when doing variable expansion. The fact that bash treats "$x" and $x as different is a bit of a design flaw. Of course there's still an issue with evaluating dynamically generated code, but that problem is partly solved by working with arrays.
  - chrisseaton 5y ago
    I mean how do you want shells to deal with file names with spaces in? Do you think we should have to quote and escape all file names all the time? If not then how do you think it should work?
    - rcxdude 5y ago
      Shells should treat data as data, and not have the default behaviour be treating it as code (i.e. you should need to do 'eval $x' or some equivilant if you acutally want the string to be treated as a shell command). This would also mean having a real list type, instead of depending on arbitrary seperators in strings. This is exactly how other languages treat it, and it is not a significant challenge for interactive use (in fact, it would substantially reduce the opportunity for suprises when running commands interactively as well).
HenryKissinger 5y ago
> Still way too many libraries and programs can't handle spaces in filenames. "It's nothing." "What do you mean?" "It's nothing... It's empty space. I never taught the computer how to read empty space!" "I never taught Virgil how to fly."
danielvaughn 5y ago
yep, I still don't use spaces. I also don't use uppercase characters. Just underscores or hyphens.
- boringg 5y ago
  Sometimes I break the rule and use uppercase but never spaces.
  - ptha 5y ago
    I've had issues when moving between Window/*nix file systems, where Windows file names are case insensitive and *nix systems are case sensitive. Build script works fine locally on Windows, but then chokes in *nix test server, as it's effectively a different path.
    - cerved 5y ago
      file names aren't case insensitive, it's the windows API that is
      - ptha 5y ago
        I assume you mean that the Windows API (standard for Windows apps) is case insensitive, but if using the WSL (Windows Subsystem for Linux) it's possible to get case sensitivity: https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity https://docs.microsoft.com/en-us/windows/wsl/case-sensitivit...
        efreak 5y ago
        Even if you're not using WSL, you've always been able to turn on case sensitivity via a registry key. This has not been recommended in the past due to possible issues with windows itself as well as third party software. This history is mentioned here[0]. Everywhere that mentioned a registry key seems to be referring to windows nfs server, not to general file access, however I know that SFU (Services for Unix) installer had an option to do so, so it's certainly possible. As of sometime in 2018, fsutil can set specific directory trees to be treated case sensitive in Windows 10 without setting it for the OS. This ability is mentioned here[1] [0]: https://devblogs.microsoft.com/commandline/per-directory-case-sensitivity-and-wsl/ https://devblogs.microsoft.com/commandline/per-directory-cas... [1]: https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity#changing-the-case-sensitivity-on-a-drive-mounted-to-a-wsl-distribution https://docs.microsoft.com/en-us/windows/wsl/case-sensitivit...
jerf 5y ago
Was recently encoding my Stargate: SG-1 DVDs to move them to plex. I was encoding it on a system other than what was serving it, so I had to copy it. It's surprisingly difficult to "scp" a file with a colon in it directly. I also love when you're using bash and you have a file with ! in the name, and you accidentally fail to correctly backslash it, you not only get "bash: !rest_of_filename: event not found", but it also fails to add that command line to the history, so you can't just hit up and fix it. You have to actually go to the mouse and copy and paste.
- AnIdiotOnTheNet 5y ago
  It's almost like in-band signaling isn't a good idea or something.
- kerblang 5y ago
  That sounds like... Puzzle time! I had to cheat, sort of, by looking at the man page: > Local file names can be made explicit using absolute or relative pathnames to avoid scp treating file names containing ':' as host specifiers. So `scp foo:bar user@host:~` fails because it tries to find the host foo. But `scp ./foo:bar user@host:~` works just fine. I feel kind of stupid for not guessing as much.
- philote 5y ago
  Can't you usually just put quotes around the filename and/or path to prevent all those issues? Edit: nope, just tried it and scp still sees the quoted filename as a host + path
  - warkdarrior 5y ago
    That is just lazy programming. If the input "foo:bar" is ambiguous, the program should try both interpretations (HOST:FILE and FILE) and then present the user with a prompt that provides sufficient information. "Does foo:bar refer to the local file `foo:bar' (size: 102kB, date: 2021-11-11) or to the file `bar' on host `foo' (FQDN: foo.example.com, IP address: 1.2.3.4)? 1: local file `foo:bar' 2: file `bar' on remote host `foo' Your selection: "
- 5y ago
remram 5y ago
If you suspect that the file might be handed to a bash script at any point, being afraid of spaces is very healthy for sure.
Pxtl 5y ago
Colons are a problem on Windows, so it's reasonable to discourage creating files with colons in the name.
mywittyname 5y ago
Is "!" legal in Windows? I'm pretty sure it is not, but I'm not on a Windows machine to test.

Still way too many libraries and programs can't handle spaces in filenames. And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'.

chrisseaton 5y ago

> And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'. Without asking you to always quote and escape every file name - what alternative is there? If they tried this you'd probably find you didn't like it.

zeroimpl 5y ago
Not exactly - the problem is mostly when doing variable expansion. The fact that bash treats "$x" and $x as different is a bit of a design flaw. Of course there's still an issue with evaluating dynamically generated code, but that problem is partly solved by working with arrays.
- chrisseaton 5y ago
  I mean how do you want shells to deal with file names with spaces in? Do you think we should have to quote and escape all file names all the time? If not then how do you think it should work?
  - rcxdude 5y ago
    Shells should treat data as data, and not have the default behaviour be treating it as code (i.e. you should need to do 'eval $x' or some equivilant if you acutally want the string to be treated as a shell command). This would also mean having a real list type, instead of depending on arbitrary seperators in strings. This is exactly how other languages treat it, and it is not a significant challenge for interactive use (in fact, it would substantially reduce the opportunity for suprises when running commands interactively as well).

HenryKissinger 5y ago

> Still way too many libraries and programs can't handle spaces in filenames. "It's nothing." "What do you mean?" "It's nothing... It's empty space. I never taught the computer how to read empty space!" "I never taught Virgil how to fly."

danielvaughn 5y ago

yep, I still don't use spaces. I also don't use uppercase characters. Just underscores or hyphens.

boringg 5y ago
Sometimes I break the rule and use uppercase but never spaces.
- ptha 5y ago
  I've had issues when moving between Window/*nix file systems, where Windows file names are case insensitive and *nix systems are case sensitive. Build script works fine locally on Windows, but then chokes in *nix test server, as it's effectively a different path.
  - cerved 5y ago
    file names aren't case insensitive, it's the windows API that is
    - ptha 5y ago
      I assume you mean that the Windows API (standard for Windows apps) is case insensitive, but if using the WSL (Windows Subsystem for Linux) it's possible to get case sensitivity: https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity https://docs.microsoft.com/en-us/windows/wsl/case-sensitivit...
      - efreak 5y ago
        Even if you're not using WSL, you've always been able to turn on case sensitivity via a registry key. This has not been recommended in the past due to possible issues with windows itself as well as third party software. This history is mentioned here[0]. Everywhere that mentioned a registry key seems to be referring to windows nfs server, not to general file access, however I know that SFU (Services for Unix) installer had an option to do so, so it's certainly possible. As of sometime in 2018, fsutil can set specific directory trees to be treated case sensitive in Windows 10 without setting it for the OS. This ability is mentioned here[1] [0]: https://devblogs.microsoft.com/commandline/per-directory-case-sensitivity-and-wsl/ https://devblogs.microsoft.com/commandline/per-directory-cas... [1]: https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity#changing-the-case-sensitivity-on-a-drive-mounted-to-a-wsl-distribution https://docs.microsoft.com/en-us/windows/wsl/case-sensitivit...

jerf 5y ago

Was recently encoding my Stargate: SG-1 DVDs to move them to plex. I was encoding it on a system other than what was serving it, so I had to copy it. It's surprisingly difficult to "scp" a file with a colon in it directly. I also love when you're using bash and you have a file with ! in the name, and you accidentally fail to correctly backslash it, you not only get "bash: !rest_of_filename: event not found", but it also fails to add that command line to the history, so you can't just hit up and fix it. You have to actually go to the mouse and copy and paste.

AnIdiotOnTheNet 5y ago
It's almost like in-band signaling isn't a good idea or something.
kerblang 5y ago
That sounds like... Puzzle time! I had to cheat, sort of, by looking at the man page: > Local file names can be made explicit using absolute or relative pathnames to avoid scp treating file names containing ':' as host specifiers. So `scp foo:bar user@host:~` fails because it tries to find the host foo. But `scp ./foo:bar user@host:~` works just fine. I feel kind of stupid for not guessing as much.
philote 5y ago
Can't you usually just put quotes around the filename and/or path to prevent all those issues? Edit: nope, just tried it and scp still sees the quoted filename as a host + path
- warkdarrior 5y ago
  That is just lazy programming. If the input "foo:bar" is ambiguous, the program should try both interpretations (HOST:FILE and FILE) and then present the user with a prompt that provides sufficient information. "Does foo:bar refer to the local file `foo:bar' (size: 102kB, date: 2021-11-11) or to the file `bar' on host `foo' (FQDN: foo.example.com, IP address: 1.2.3.4)? 1: local file `foo:bar' 2: file `bar' on remote host `foo' Your selection: "
5y ago

remram 5y ago

If you suspect that the file might be handed to a bash script at any point, being afraid of spaces is very healthy for sure.

Pxtl 5y ago

Colons are a problem on Windows, so it's reasonable to discourage creating files with colons in the name.

mywittyname 5y ago

Is "!" legal in Windows? I'm pretty sure it is not, but I'm not on a Windows machine to test.