As do almost all programmers. That’s why we’re trying to tell you to do the safe thing that won’t cause you endless frustration. The small subset of programmers you should be upset at, are the ones who write user interfaces that allow you to do dangerous things like putting spaces in filenames.
That small subset include the programmers who set the rules for Windows and Apple file-naming conventions. My point remains that if the operating systems that virtually every naive user uses allow for something, then only a self-righteous fool decides to stand on principle against it.
I only skimmed the thread; is there a self-righteous fool in this thread standing against users, or are you just debating a strawman?
Programming for general use must support all legal filenamings – did you think someone here was arguing differently? To the contrary, one programmer mentioned that special support may be needed for spaces (or other special characters) precisely because lazier programmers do not handle them.
Nor, I think, is anyone advocating a return to earlier days with better designed interfaces. That ship has [del]sunk[/del] sailed already.
But the simple fact is that, for many of us, long filenames with special characters are a pure nuisance with no redeeming value. Once the longest pathname on my machine was something like
/usr/septimus/src/back_gammon/pipcount.c
On the Windows machine where I’m typing this, I might be hard-pressed to find a pathname that simple and short.
It isn’t users versus programmers, it is people who live in GUIs and can’t think of anything else versus people who still use command lines. The people who will be using the files I convert with my space remover aren’t anything like programmers, they are engineers who want to look inside a file without an editor - and the files are so large that this might not even be feasible.
If you allow spaces in filenames there is no way you can parse a command line unless you use painful escapes to tell the OS where the file actually begins and ends.
And don’t knock command line. In one line you can do things with massive files which would be time consuming and a real pain in your standard application.
No, it isn’t, because all you have to do is put the filename in quotation marks. That’s the standard. If your program does not adhere to it, it has bugs.
This is not an opinion question. Telling people that using spaces is a problem is factually wrong for any program designed to work with a modern operating system. Saying it is wrong because you don’t like typing quotation marks, or that it’s wrong because you refuse to update your thinking and adhere to the standards for your programs is just your opinion.
The answer to the OP is that all properly maintained programs can handle spaces. You are unlikely to run into problems unless you use really old programs or shoddily coded ones. In Windows, even this isn’t really a problem unless you’ve turned off short filenames–you just have to figure out the 8.3 version of the file you want to use. You can do that on the command line, too.
In Linux, it’s more complicated because no such compatibility was built in. But most of it’s code is open source, so not only can you fix the code, it’s probably already been fixed by someone else, you’ve just got to find it.
TL;DR version: Factual answer is that it’s perfectly okay with modern, properly written programs. Don’t worry about it.
Don’t expect to find many command-line fans among the hyper-modern cliques. In another forum I once mentioned a ‘rot13’ command to exemplify Unix versatility
and was rebuked for my ignorance: Web-browsers have ‘rot13’ plug-ins available for download. :smack:
Works unless the filename itself has quotation marks! Yes, I realize Windows forbids " in names, but it doesn’t forbid some other symbols (e.g. $) which are troublesome.
I’m not afraid of special namings – in my [del]malicious[/del] adventurous youth, I was happy to access raw disk and overwrite ‘.’ links 
– but find them a pointless nuisance.
On more than one occasion I’ve booted Linux for no reason except for its convenience in renaming a large batch of ridiculously-named Windows files.
All you people who think it’s a “bug” that some programs might not be able to handle spaces in names – or who think that any benighted neanderthal who actually types command lines any more – you need to be aware that there was quite a large body of software existing that was written before spaces were allowed in file names. It was a very well-established standard that spaces were the universal separator character between words or tokens on a command line. And pretty much all interactions with computers happened via command lines. That was all very entrenched at one time, all before somebody decided to allow spaces in file names. (To be sure, it was also well entrenched that file names had rather short limits on how long they could be.)
Then Apple went and allowed spaces in names, and long names. When Microsoft came out with DOS (after the Apple II), they stuck with the short naming rules (8.3 names) with no spaces. When Windows came out, they allowed long names with spaces. This seriously broke nearly all then-existing software, and almost guaranteed the need to re-invent just about everything that had ever been written before that.
As things got re-written, little-by-little, the result was a sorry hodge-podge of syntax rules, and lots of inconsistent ways to dealing with the problem. Little by little, things have settled down, which is the only reason it works as well as it does. But as various people have noted above, there are still pockets of trouble here and there.
On the surface, GUI users see no problem with odd names – mostly, you see lists of names in your Explorer window (or similarly elsewhere), and you just point and click on one. That’s just your ignorance, thinking that that’s all there is to it. In fact, you are well aware that nearly all programs can run and communicate with various programs. This is largely done, behind the scenes, with command line style communication. Most of those programs have it all worked out by now, that they put the right quotes around file names, so most of the wrinkles have been smoothed out.
If I write a program or script that doesn’t handle spaces, I might not necessarily agree that it’s a bug. If I don’t feel the need to handle spaces (depending on what the program’s mission is), I might just say that I don’t handle file names with spaces. I might not necessarily feel that I need to handle any odd names that anyone throws at me.
I’ve actually seen a thread on this board where the OP claimed to understand how a GUI could move files, since you could see the file being picked up and moved, but had no idea how it was possible for a command-line program to move a file. Not, didn’t know how to do it, but didn’t know how it could even be possible.
Yes, but most of us don’t use software what predate Windows-95 or the original MacOS.
Now, I agree that filenames with spaces can cause problems with old (and not maintained) software and poorly-written software. I usually try to avoid spaces in filenames when doing data analysis for work, because most of the analysis software I use are written by scientists (like me) and not professional programmers.
But generally in Windows, I see no reason to avoid spaces in filenames. As others already pointed out, the path names to most of your programs and data already contain spaces.
I guess it’s not a “bug” if it is the intended behaviour of your program. But i would still consider it a flaw. We’ve had twenty years to get used to the radical idea that file/path names might have spaces in them. Spaces in file names are a good thing, from the user’s point of view. The fact that operating systems from the 80s and before were designed with the assumption that a space is a delimiter should be beside the point by now.
To be on the safe side, I still tend to avoid them if I see any prospect of the file being read by some external program, but things like documents that only I will read? Spaces galore.
A mildly interesting note on this topic: with Windows, be careful with leading spaces in file names. The command prompt allows them with a quoted file name, but the UI strips leading spaces and leaves trailing spaces.
If a script creates a file with leading spaces and you rename the file but leave the leading spaces in (intending to alter some other portion), then the file name will have it’s leading spaces stripped.
Slight problem with this: users use programs that are written by programmers.
Use spaces if you like them, but every now and again (with decreasing frequency nowadays), something will blow up - and the presence of a space in the filename will be the very non-obvious culprit.
Yeah, but any programmer who can’t handle file names with spaces is almost certainly out of work. The only software left that does this is poorly ported open source software, and someone will usually come by and fix that, even.
Plus, it’s far easier to make exceptions for poorly written programs than to base your entire computer usage around a (now) 19 year old paradigm. Chances are, you’re going to have to make a lot of odd concessions for that likely ancient program, anyway.
Spaces in filenames is the standard now. “Every now and again” greatly overstates the frequency of programs that have problems with it, probably by an order of magnitude or two.
You neglect to consider that most command-line processors in both Microsoft OSs and Linux/Unix world still treat the space as a seperator first, and as potentially part of a filename only when specifically ordered to (by escaping, or by quote-wrapping the entire parameter).
And that’s not changing any time soon.
Spaces in filenames are lovely, but you’ll have to handle them with kid gloves if you have to work with them in a CLI.
I just spent several days with a Microsoft supplied CLI tool trying to script a task using VisualBasic.
The problem: trying to find the correct way to escape quotes so that the utility would correctly see the space containing filename. Did you know there are multiple escape mechanisms used in cmd/CLI/vbscript, and not all work depending on context. I didn’t, but I do now. At least on Linux/Unix, it is consistent and manageable.
Space of course is not the only troublesome character that needs to be “escaped.” And when results are passed to another stage (as they likely will be for anything complex), the escaping symbol will have been removed so more escaping is needed.
Here’s a real example in my simple world to show what I mean about iterative escaping. I have a file in which the ‘&’ character frequently occurs simply because I want to print, eventually, a ‘&’. However that character is treated as special by a 2nd processing stage. If it were special in the first stage, I’d replace ‘&’ with ‘&’ to “escape” the special significance of ‘&’. But since the significance is in the 2nd stage I need to write ‘\&’. The 1st stage will replace this with ‘&’ and, after the 2nd stage, I finally get the ‘&’ I desired. I think most programmers will agree things like this are routine.
It gets even more humorous than this! To locate those special escape sequences (e.g. ‘\&’) I might type the command
grep \\\\
The command-line interpreter treats ‘’ as an escapement, so each ‘\’ becomes just ‘’. So grep is finally presented with ‘\\’ rather than ‘\\\\’, but grep also uses ‘’ as escapement so it treats the ‘\\’ as ‘\’, as desired! There are multiple ways to escape. For example, instead of
grep \\\\
I could have used
grep “\\”
Escapement details may vary depending on what character is being escaped; the " would be no use escaping a " character! Parentheses are also troublesome, though that doesn’t stop “friendly” applications from scribbling them into file names.
See? If we were in the Pit I’d say those blaming programmer’s laziness for any filenaming fuss don’t know what they’re talking about.
Wow! This helps explain the huge difference in perspective between users and programmers in threads like this one.
My experience has been different - I’ve seen it arise maybe three or four times in the last 5 years (I deal with hundreds of third party software applications and systems in my work - some of them are from comparatively small companies where they have been in development by the same small team for over a decade - probably with quite a lot of legacy code and practice being carried along)
The comparative rarity of failure from spaces in filenames nowadays actually makes it a worse problem when it does occur - because it’s not something we think to suspect so much any more.
I’m not against spaces in file names, but we’re not yet quite in a world where they cause no problems.
In case it hasn’t been explicitly spelled out in this long zombie thread, the issue isn’t “professional” software, or even big FOSS projects. It’s homemade software and scripting.
Yes. People – users – occasionally still use their computers to compute(!), and not just as glorified televisions. They write scripts, they create macros, they run batch files. They might even play around with Python, or C. These people are not professional programmers who understand the ins and outs of every operating system, not even their own. They code just until it works for their own use case, and no more.
Furthermore, these people often pass around these scripts and programs to their friends. Yes, free software in all but name, these people are carrying out what once was a proud tradition among academic programmers, but has now been obsoleted by the EULA.
The fact is, if you want to make your life easier, and the lives of others, you’ll use short, descriptive file names without spaces or other special characters. But it’s certainly not necessary and hasn’t been for decades.
Be conservative in what you output and liberal in what you accept as input.
My computer just makes a burping noise… is possible to activate this explosion feature on a Mac? 
Any programmer on Windows who uses the “English” version of those folder names, instead of the cannonical form (which does not contain spaces, and is a signature, not a sentence) is absolutely begging for inevitable trouble.
If you depend on the “English” version of those folder names, any user, any virus, can change the user-version of those names, redirecting your program to malware or just making it not work. Let alone French-Canadian or Spanish versions of the same thing.