Okay that was /s to some extent but I gotta rant, I’m totally convinced that there’s still new software today that completely trip over themselves when files or paths have non-ASCII characters, or sometimes even a space. Incompetence didn’t go anywhere.
Spaces in file names will always be fiddly though. It’ll work, but it’ll still be wrong, because arguments are space separated, and having spaced file names totally messes with that.
I try to just always put files names or paths into quotes in CLI or tie it to a variable in programming. This way it also accepts spaces and knows how to separate it from arguments.
Unicode in filenames can be a bad idea, since there are more than one way to achieve what looks like the same character. So matching patterns could fail if you think it’s one way, but it’s actually another representation in unicode.
Good point. Do filesystems use a normal form to at least prevent having two files with effectively the same name?
I should point out the flip side though, that there’s no avoiding Unicode in filenames. Users in languages that don’t use the Latin alphabet (such as Japanese, Chinese, Korean, Hebrew, Arabic, Greek and Russian, and the list could go on) can reasonably expect to be able to give a file a name they can read and understand with no extra effort. All the software woes that come with it - too bad, software needs to deal with it.
I’m assuming Unicode anyway, and UTF-8 is by far the most natural because most files will be in ASCII. A “normal form” (see link above), you might think of it as a canonical form, is a way to check if two strings are equivalent, even if they encoded the text differently. Like the example mentioned on Wikipedia:
For example, the distinct Unicode strings “U+212B” (the angstrom sign “Å”) and “U+00C5” (the Swedish letter “Å”) are both expanded by NFD (or NFKD) into the sequence “U+0041 U+030A” (Latin letter “A” and combining ring above “°”) which is then reduced by NFC (or NFKC) to “U+00C5” (the Swedish letter “Å”).
Unicode in filenames? Are you crazy?!
Okay that was /s to some extent but I gotta rant, I’m totally convinced that there’s still new software today that completely trip over themselves when files or paths have non-ASCII characters, or sometimes even a space. Incompetence didn’t go anywhere.
I still use underscores for filenames, basically muscle memory at this point
Spaces in file names will always be fiddly though. It’ll work, but it’ll still be wrong, because arguments are space separated, and having spaced file names totally messes with that.
I try to just always put files names or paths into quotes in CLI or tie it to a variable in programming. This way it also accepts spaces and knows how to separate it from arguments.
Yeah. It’s a good idea to guard against it, but I would still never put spaces in filesnames that I myself choose.
Unicode in filenames can be a bad idea, since there are more than one way to achieve what looks like the same character. So matching patterns could fail if you think it’s one way, but it’s actually another representation in unicode.
Good point. Do filesystems use a normal form to at least prevent having two files with effectively the same name?
I should point out the flip side though, that there’s no avoiding Unicode in filenames. Users in languages that don’t use the Latin alphabet (such as Japanese, Chinese, Korean, Hebrew, Arabic, Greek and Russian, and the list could go on) can reasonably expect to be able to give a file a name they can read and understand with no extra effort. All the software woes that come with it - too bad, software needs to deal with it.
I’m not sure. A few years ago I remember that OpenBSD expected ASCII for files, but I think Linux expects utf-8. I could be wrong though.
I’m assuming Unicode anyway, and UTF-8 is by far the most natural because most files will be in ASCII. A “normal form” (see link above), you might think of it as a canonical form, is a way to check if two strings are equivalent, even if they encoded the text differently. Like the example mentioned on Wikipedia:
Now that’s certainly true, but the beauty of open source software is that we can fix bugs when we encounter them.