On the command line, space is what separates each argument. If a path contains a space, you either have to quote the entire path, or use an escape character (e.g. the \ character in most shells, the backtick in Powershell because Microsoft is weird, or the character’s hexadecimal value), otherwise the path will be passed to the command as separate arguments. For example, cat hello world.txt would try to print the files hello and world.txt.
It is a good practice to minimize the character set used by filenames, and best to only use English alphanumeric characters and certain symbols like -, _, and .. Non-printable characters (like the lower half of ASCII), weird diacritics (like ő or ű), ligatures, or any characters that could be misinterpreted by a program should be avoided.
This is why byte-safe encodings, like base64 or percent-encoding, are important. Transmitting data directly as text runs the risk of mangling the characters because some program misinterpreted them.
but what does the command line matter for dates? sure every once in a while you’ll have to pass a date as an argument on the command line but I think usually that kind of data is handled by APIs without human intervention, so once these are set up properly, I don’t see the problem
If the date command returns an RFC-3339-formatted string, the filename will contain a space. If, for example, you want to iterate over the files using for d in $(find...) and forget to set $IFS properly, it can cause issues.
But $(date) does return a string with spaces, at least on every system I’ve ever used. And what’s so bad about the possibility of spaces in filenames? They’re slightly inconvenient in a command line, but I haven’t used a commuter this century that didn’t support spaces in filenames.
Ok, I just reread it. I don’t see what you think I’m missing. You mean an improperly written find command misbehaving? The fact that a different date format could prevent a bug from manifesting doesn’t seem like much of an argument.
will process the space-separated parts of each path as separate items. I had to work around this issue just two days ago, it’s an obscure thing that not everyone will keep in mind.
Yeah? I once spent an entire week debugging a plaintext database because the software expected the record identifiers to be tokenized a certain way, but the original data source had spaces in those strings.
The software was the ISC DHCP server, the industry standard for decades and only EOL’d a year ago.
I’m not exactly fond of the space either, but man, the T is noisy. They could’ve gone with an underscore or something, so it actually looks like two different sections.
You’ve just become the nemesis of the entire unix-like userbase for praising the space.
What’s the issue with the space?
On the command line, space is what separates each argument. If a path contains a space, you either have to quote the entire path, or use an escape character (e.g. the
\character in most shells, the backtick in Powershell because Microsoft is weird, or the character’s hexadecimal value), otherwise the path will be passed to the command as separate arguments. For example,cat hello world.txtwould try to print the fileshelloandworld.txt.It is a good practice to minimize the character set used by filenames, and best to only use English alphanumeric characters and certain symbols like
-,_, and.. Non-printable characters (like the lower half of ASCII), weird diacritics (like ő or ű), ligatures, or any characters that could be misinterpreted by a program should be avoided.This is why byte-safe encodings, like base64 or percent-encoding, are important. Transmitting data directly as text runs the risk of mangling the characters because some program misinterpreted them.
but what does the command line matter for dates? sure every once in a while you’ll have to pass a date as an argument on the command line but I think usually that kind of data is handled by APIs without human intervention, so once these are set up properly, I don’t see the problem
rsync -a "somedir" "somedir_backup_$(date)"If the
datecommand returns an RFC-3339-formatted string, the filename will contain a space. If, for example, you want to iterate over the files usingfor d in $(find...)and forget to set$IFSproperly, it can cause issues.But
$(date)does return a string with spaces, at least on every system I’ve ever used. And what’s so bad about the possibility of spaces in filenames? They’re slightly inconvenient in a command line, but I haven’t used a commuter this century that didn’t support spaces in filenames.Bro, literally re-read the comment you replied to. It has an example of what might happen.
Ok, I just reread it. I don’t see what you think I’m missing. You mean an improperly written find command misbehaving? The fact that a different date format could prevent a bug from manifesting doesn’t seem like much of an argument.
Both arguments are surrounded by
", which should be space-safe.At least in the shells I use, putting
"makes spaces inside paths a non-issue.For the
rsynccommand, yes. But this:for d in $(find . -type d); do echo "$d" donewill process the space-separated parts of each path as separate items. I had to work around this issue just two days ago, it’s an obscure thing that not everyone will keep in mind.
Hm, I guess I just don’t agree that CLI usablity comes before readability.
Again, it’s not just CLI, it’s an insurance against misinterpreted characters breaking programs.
honestly, if a space breaks your program, it’s kind of a shit program.
Yeah? I once spent an entire week debugging a plaintext database because the software expected the record identifiers to be tokenized a certain way, but the original data source had spaces in those strings.
The software was the ISC DHCP server, the industry standard for decades and only EOL’d a year ago.
I’m not exactly fond of the space either, but man, the T is noisy. They could’ve gone with an underscore or something, so it actually looks like two different sections.