Comment by ReleaseCandidat
4 years ago
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 ':'.
4 years ago
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 ':'.
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.
It's almost like in-band signaling isn't a good idea or something.
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.
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
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: "
WinSCP currently has a bug that crashes if it tries to sync a folder with a space in the name
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.
yep, I still don't use spaces. I also don't use uppercase characters. Just underscores or hyphens.
Sometimes I break the rule and use uppercase but never spaces.
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.
3 replies →
I’ve had issues with git when changing a filename, if the only change is the casing.
> 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.
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.
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?
1 reply →
Is "!" legal in Windows? I'm pretty sure it is not, but I'm not on a Windows machine to test.
Colons are a problem on Windows, so it's reasonable to discourage creating files with colons in the name.
> 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."