The problem is really that space is an argument separator, so to safely handle filenames with spaces you need to handle them special, either by escaping them, quoting the entire thing. This means that the filename with spaces can’t be just copy pasted wherever you want, you have handle them special. It adds complications that are resolved by just using a separator that isnt used for other things, like underscore, or dash. Dot I also don’t like as much as it’s used as a separator for extensions, but that’s a far easier problem to handle by just ignoring all but the last dot, leaving only one really bad edge case (a file that does not have an extension, that uses dot separator in its filename having the filesystem imply a wrong extension.
That’s a problem with the shell though, not the filesystem. It doesn’t matter which files filesystem you’re using; most interactive shells use spaces as token separators and therefore spaces in filenames need to be enclosed in quotes or escaped.
I’m with the person you’re replying to, what’s an example? I haven’t had a problem working with filenames with spaces in at least ten years on windows, Linux or Mac…
It’s also really good practice to account for weird characters in programs and shell scripts you write because then you don’t have injection vulnerabilities or unicode problems.
Seriously, what’s an example of spaces in filenames causing a problem?
Will error for example. It works fine for filenames without space, but if the filename has space in it, it will be interpreted wrong. But if your testing batch doesn’t have spaces in the filename, you won’t see the issue until it’s used on a file that does.
Note ‘cat’ is a placeholder, any function/script that can be used on a file here will have the same issue.
Something similar to that caught me last week while I was unzipping multiple mods in bulk for a game.
You should know that in most filesystems that are not NTFS, spaces in file names are not well supported.
Can you give examples? Linux and Mac have no real issues as far as I’m aware. Nor exFAT or FAT32
The problem is really that space is an argument separator, so to safely handle filenames with spaces you need to handle them special, either by escaping them, quoting the entire thing. This means that the filename with spaces can’t be just copy pasted wherever you want, you have handle them special. It adds complications that are resolved by just using a separator that isnt used for other things, like underscore, or dash. Dot I also don’t like as much as it’s used as a separator for extensions, but that’s a far easier problem to handle by just ignoring all but the last dot, leaving only one really bad edge case (a file that does not have an extension, that uses dot separator in its filename having the filesystem imply a wrong extension.
That’s a problem with the shell though, not the filesystem. It doesn’t matter which files filesystem you’re using; most interactive shells use spaces as token separators and therefore spaces in filenames need to be enclosed in quotes or escaped.
I’m with the person you’re replying to, what’s an example? I haven’t had a problem working with filenames with spaces in at least ten years on windows, Linux or Mac…
Have you ever written a program or simply used a terminal?
Escape characters and autocomplete exist.
It’s also really good practice to account for weird characters in programs and shell scripts you write because then you don’t have injection vulnerabilities or unicode problems.
Seriously, what’s an example of spaces in filenames causing a problem?
for f in *.txt; do cat $f; doneWill error for example. It works fine for filenames without space, but if the filename has space in it, it will be interpreted wrong. But if your testing batch doesn’t have spaces in the filename, you won’t see the issue until it’s used on a file that does. Note ‘cat’ is a placeholder, any function/script that can be used on a file here will have the same issue.
Something similar to that caught me last week while I was unzipping multiple mods in bulk for a game.
I’m not at a bash terminal, but I think “$f” fixes that. I’ll look tonight.
You are correct, that is how I worked around the issue and why I mentioned that work around in my original post