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.
Spaces can exist in filenames. The only problem is that they have to be escaped. As the comment that you reread explained, cat hello world.txt would print the files hello and world.txt. If you wanted to print the file "hello world.txt" you’d either need to quote it (cat"hello world.txt") or escape the space (cat hello\ world.txt)
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.
Sounds like a weekend that you could have saved if the software was just implemented properly and accepted spaces.
Something being an industry standard does not necessarily mean it’s good. Sometimes it just means it was the cheapest, or sometimes even just because it was used for so long. How long did it take for Torx to somewhat replace philips head screws despite being better in most cases?
I think date strings are made for human and machine readability. Similar to XML or JSON. So, why not improve systems so that we can have more human readable date strings? If you don’t care about human readability and want to make sure there is no confusion with spaces, you can just use epoch timestamps.
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.
Spaces can exist in filenames. The only problem is that they have to be escaped. As the comment that you reread explained,
cat hello world.txtwould print the fileshelloandworld.txt. If you wanted to print the file"hello world.txt"you’d either need to quote it (cat "hello world.txt") or escape the space (cat hello\ world.txt)Oh, the horror!
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.
Sounds like a weekend that you could have saved if the software was just implemented properly and accepted spaces.
Something being an industry standard does not necessarily mean it’s good. Sometimes it just means it was the cheapest, or sometimes even just because it was used for so long. How long did it take for Torx to somewhat replace philips head screws despite being better in most cases?
I think date strings are made for human and machine readability. Similar to XML or JSON. So, why not improve systems so that we can have more human readable date strings? If you don’t care about human readability and want to make sure there is no confusion with spaces, you can just use epoch timestamps.