/Why\ I\ hate\ spaces\ in/filenames –v1

by debianjoe

Sometimes, the modern conveniences of command-line computing give rise to terrible and horrible practices.  In order to combat the ever-growing and changing world of monoliths of file-storage and users having the freedom to name or rename files and directories as they see fit, our shells have greatly ‘improved’.  So have most scripts.  This is all for the best, right?  Now there is freedom and freedom is good and everyone can add lines of meta information right into the name of a file.  “I spit on (your) tradition &don’t care.ogg” is less than 255 characters, and can totally be used.

…but should it?

Keeping in mind that I’ve spent the past few days completing everything in Plan9’s rc shell, I’ve been reminded of many of the reasons that things just can’t be as simple as they once were.  (I feel like the mother in some sitcom yelling “This is why we can’t have nice things!”)  The benefits of better auto-completion, tab-completion, and *gasp* graphical file management have sometimes obscured exactly how Unix-like systems deal with things like odd characters and spaces in file names.

In rc-shell, tab moves the cursor to the right.  Nothing magical happens, so if you need to invoke a file to perform an operation on it, then you simply have to type it out correctly.  This is not a big issue, until you run into a file that contains 124 characters and 27 spaces, which all need to be individually escaped.  It may just be me (I doubt it), but I normally make at least one typo.  This is fine, right?  “Just hit the up arrow and you can fix the command,” says the command-line guru.  Incorrect!  You’ve become accustomed to GNU’s Readline (or OS-specific equivalent) and have forgotten that this functionality has not always existed either.  I end up using carats (“^old^new”) to fix it, before renaming the file to something far simpler.

“But, that’s your fault for using a shell that was developed in the 1980’s.”  Ok, I’ll give you that one.  I could simply be using a totally different setup.  That being said, I can assure you that every single script that has been written in the last 10+ years has taken one of 2 stances on file-names.

1). Sanitize all possible user input using creative parsing or xargs to ensure that spaces within file-names are handled properly, forking extra processes and writing extra chunks of scripting for the sole purpose of dealing with variations.

2). Don’t care about the user.  They should not have spaces in file-names!

While I think that #2 is far more entertaining, most scripters and programmers err on the side of caution and go with option #1.  In all, possibly millions of lines of code have been written in everything from large applications to small one-off scripts to deal with something that could have easily been avoided.

“Ok, Joe, I admit it…I want to be rid of these crazy spaces in my file-names, but it’s so much work to change them all!” – enlightened one.

Well, for the most of you using bash, this will quickly sanitize spaces in a directory for you by replacing them with underscores:

for f in *\ *; do mv -- "$f" "${f// /_}"; done

May your computing be precise.