What's the straight dope regarding spaces in file names?

In many fonts it may be hard to distinguish a space in a file name from two adjacent characters (at least for my eyes) - if you use underscores you’ll never have this problem. This happened to me today, not for file names but for another name.

I know when I’m using terminal on Linux I use a backslash () followed by a space to signify a space is there. For example *cd ./.wine/drive_c/Program\ Files/
*
It’s not that big of a deal even when using a terminal, however I do try and avoid spaces and prefer an underscore.

When I’m typing a single filename on a Linux terminal, I use the shell’s filename-completion feature and usually need neither type nor escape any special character myself.

In other contexts, creating a batch of filenames with the necessary escapements is much less convenient.

I disagree. While graphical interfaces for Linux (KDE, Gnome etc) are becoming visually somewhat like the Windows/Apple default (well, prior to Windows 8), the fact is these GUI interfaces are considerably more flexible and complete in functionality.

For example, both Gnome and KDE use proper file typing, rather than relying on a 3 character file extension for file ID. They don’t hide characters (the aforementioned hide known file extensions). I find them complete in ways that Windows interfaces still dream of.

As for writing scripts to handle filenames with spaces - my rule is Quote Data. If I get a file list from somewhere (a directory list query, say) and I am passing those names to a new command, then I use quoting so I know where a file name ends and a new one begins, and not rely on the shell. Always remember little Bobby Tables, and also, Bobby isn’t just for SQL, he’s for any input stream.

As for NTFS file name limits, the kicker is when you move a nice big file tree with really long names (a parts maintenance records system for a power station, as I recall) from one server to another, and the new shared directory is deeper on the disk than the source. The files copy (as the 256 char limit is never breached), but cannot be accessed on the new server as they are too deep to be referenced :smack:

Si

These sorts of things.

Typing commands, whether to the command shell or to FTP or any other command line interface, gets to be a PITA if you need to deal with files with spaces in them (and sometimes other unusual punctuation). Building programs or scripts or other automated processes to do it, and get it right with odd names, can be a PITA. Imaging typing DIR /B > XXX.BAT to get a simple list of file names, which will then be input to some process that creates a batch file with those names. Getting the names properly quoted is a PITA.

There were opposing opinions in posts above, as to whether my script (downloading files with FTP) suffered from a bug, or suffered from a change in the specs. You could take either attitude. But the fact remains, either way, it’s a PITA.

There’s vast amounts of software out there, in particular all those little quickie simple-minded scripts that people write, that would not deal with odd names, and would be not-so-simple to make them deal with odd names. We’ve had threads here where people ask how to write a script to process a list of files, and have gotten many quick and easy suggestions. Some of those would not be so easy if someone had to deal with truly arbitrary names that might contain spaces.

Odd names work if all you do is point-and-click on the names in some list in a GUI, like in a Windows Explorer window. And maybe they work if your CLI can do auto-expansion, as suggested above. (Does it quote or escape the spaces as needed? I’ve never tried it.)

If you create files with spaces, you’re making very limiting assumptions about how those names will be used. If all you ever do if point-and-click, that’s fine. If you use file names in any other way, you’re just asking for trouble sooner or later.

If you don’t like underscores, you also have the CamelCaseOptionForLongFileNames.

…or if I’m referring to a file in the middle of a paragraph or making a hand written list of files, it’s easier to decipher MyFinance2012.txt than a my finance 2012.txt file name.

I love underscores

I_Know_Nothing

Yes, it seems one must always bear in mind to quote file names (and other similar data). But there are any number of apps out there, including shells and other CLI’s, and it’s a crap-shoot which of them you can count on to parse quoted names correctly.

My example was FTP. I never knew that FTP could accept quoted files names. I had never had occasion before to try it or even think about it. When the problem arose, FTP just quietly died. (Well, maybe there were error messages but they weren’t getting captured anywhere.) It took a while to figure out WTF was happening. Then I just tried quoting the names and found out they work. But there’s never a general assurance that will always happen.

Spaces have been used as word or token separators in computer command syntax since the days of Charles Babbage. Modern parsers have additional syntax to deal with spaces in names, but it’s almost always messier, involving typing quotes or escape characters around names. PITA. We need to have some universally agreed-upon character (like a comma maybe?) that can always be used as a separator, and can NEVER be used in a file name.

Wait a minute. We’ve always had such a universally agreed upon separator, and it was always the blank space character. Then some genius from another reality decided to allow file names to have spaces, and that broke everything, and has been a PITA ever since.

It wasn’t Microsoft by the way. The first I ever saw file names with spaces was in the Apple II computer in 1980, before the IBM PC was ever invented.

As long as Linux has ratpoison, this complaint is invalid.

In a larger sense: This is only a problem for people who refuse to stop using the defaults a few of the big ‘mass-market’ distros pack in, cannot use (or appreciate) a command line, and don’t know about package management systems.

Oh, come on! After being bitten by that a couple of times, you write another simple little script so that your old DIR /B > XXX.BAT becomes DIR /B | QUOTIFY > XXX.BAT. Always quoting the path will get you out of (that kind of) trouble 99% of the time (Unless you have an O/S which accepts newlines within filenames - in a world where Befunge exists, that level of evil wouldn’t surprise me)

If you create filenames with spaces, be prepared to mitigate for programmers making the limiting assumption that a user won’t use all of the features of their filesystem. Most people use those extra features (long and mixed case file names, punctuation, spaces) in a fairly predictable way - to enhance readability - the text elements remain the differentiation point. So long as you don’t create filenames that only differ in their spacing (ie both “My File.txt” and “MyFile.txt” or a truly pathological filename with multiple consecutive spaces), then all that is needed for that mitigation is a preprocessing step that copies and renames your files so that the readability scaffolding is removed.

What will really make your computer blow up is creating Program.exe in the root of your C: drive. This is related to the way the Windows command line handles unquoted paths that contain spaces (it only actually opens c:\program files after trying to run “c:\program” files - exe, bat and com can all be run without extensions)

Exapno, you seem to be under the apprehension that programmer problems only affect programmers. Quite to the contrary, programmer problems affect anyone who uses programs. In fact, they affect non-programmers more than programmers, since non-programmers won’t know what the problem is, or how to fix it.

I’d say instead that in the ongoing war between programmers and users, I side with users.

Users will use their computers naively, as should be evident in any thread where a user asks questions. Putting spaces into files is a trivial but interesting example of this. It was touted as a feature many years and versions of Windows ago, when the hated eight character filename barrier was broken. I’m old enough to remember that the advice then was to always continue to use eight character filenames because doing otherwise might create problems. (As it did for a while with legacy programs.)

As Jragon said, if programmers do not expect that users of Windows, the overwhelmingly favorite OS of naive users, will think the way Windows thinks, they are slitting their own throats. You cannot tell a Windows user to think of the consequences if their file someday comes into contact with a Linux thinker. They will be both uncomprehending and furious. Properly so. Programmers must conform to users in these instances. There is never an excuse not to.

None of this has anything to do with Linux. You might as well drag in VMS and VM/CMS while you’re at it.

The OP stated he uses Linux.

My answer is that if, as a user, you’ve never had an issue with a space in your file names, then carry on. You may want to keep in mind the fact that there are (diminishing) situations in which they may cause a problem, but by and large if you haven’t had a problem yet you’re probably safe.

Since standingwave asked for the straight dope though, he should expect the excruciating detail about outlying cases, and **Exapno Mapcase **should relax.

Yeah, it’s the dope. No problem. I welcome pedantry. Anyway, I don’t do a lot of work at the CLI and it’s never been an issue for me. Yet. But I am tempted to write a script to replace all those spaces with dashes or something. About 125K files in /home so that will be fun. Curious how long it will take. And yes, before anyone cautions, everything is backed up.

Well, Linux may be an outlying case, but website links turning your spaces into messes of %20s, or programs trying to auto-hyperlink web links breaking, or proportional font legibility issues aren’t that outlying, I don’t think.

The most hilarious thing about writing that script is that in the process of writing it you must use the special tools for handling spaces, all so you don’t have to worry about programs not handling spaces :p.

Linux was also mentioned by gnoitall, Musicat, septimus, si_blakely, C6541, Senegoid and some guy named Derleth.

Complaining about the pedantry of Dopers has an equally long history and by custom someone must bring it up in every excruciating detail thread.

Indeed. It’s very ironic and meta. :smiley:

Ok, but we are several hundred miles from the point where users can expect programmers to deliver guaranteed stability and reliability. As an intermediate user, I like to avoid problems. Also as I noted earlier humans can get confused with my reports on october 23 meeting.doc file. Even humans can find parsing tricky at times.
Props to the OP for asking the question: just yesterday I ran into some problems while exporting a file from an application which used more than one period. The thread taught me while spaces often cause problems and so will periods on occasion, underscores are generally pretty safe. So when breaking up words with capitalization becomes awkward, underscores it is.