I firmly agree that control characters, including tab and newline, should have been shown the door decades ago. All they do is make problems.
But spaces in filenames are really just an inconvenience at most for heavy terminal users, and are a natural thing to use for basically everyone else. All my markdown files are word-word-word.md, but all my WYSIWIG documents are "Word word word.doc".
The hassle of constantly explaining to angry civilians "why won't it let me write this file" would be worse than the hassle of having to quote or backslash-escape the occasional path in the shell.
Spaces in file names are the cause of countless bugs in shell scripts, even C code which uses APIs like system() or popen(). Yes, solutions exist to those issues, but many people forget, and they add complexity which otherwise might not be necessary.
For non-technical WYSIWYG users, there is a simple solution: auto-replace space with underscore when user enters a filename containing it; you could even convert the underscore back to a space on display. Some GUIs already do stuff like this anyway - e.g. macOS exchanging slash and colon in its GUI layer (primarily for backward compatibility with Classic MacOS where slash not colon was the path separator.)
If you have the power of a wish, why do you wish to make the world worse without such a common thing like spaces instead of wishing for the legacy APIs to have a better solution?
Why wish the world to be more complicated by insisting a character do double duty both as a valid character in file names and also a delimiter in lists of file names, such as commonly occur in command line arguments?
By allowing a character to do double duty in that way, you make necessary all the complexity of quoting/escaping.
If the set of file name characters, and the set of file name delimiters, are orthogonal, you reduce (possibly even eliminate) the need for that complexity.
Also, allowing space in filenames creates other difficulties, such as file names with trailing spaces, double spaces, etc, which might not be noticed, even two files whose names differ only in the number of spaces.
A character like underscore does not have the same problem, since a trailing underscore or a double underscore is more readily recognised than a trailing or double space.
Because the land of cli args is inconsequential compared in scale compared to the general world of computer use (so it's better to wish for a tiny segment to have better design), and banning spaces does not remove the complexity of escaping (how do you escape _?)
Your trailing/double space issue is also easy to solve (in the world of wishes) with highlighting or other mechanisms, so making the world much worse by banning spaces is not the appropriate remedy
> Because the land of cli args is inconsequential compared in scale compared to the general world of computer use
Not really true - the “general world of computer use” uses that stuff very heavily, just “behind the scenes” so the average user isn’t aware of it. For example, it is very common for GUI apps to parse command line arguments at startup (since, e.g., one way the OS, and other apps which integrate with it, uses to get your word processor to open a particular document, is to pass the path to the document as a command line argument)
> and banning spaces does not remove the complexity of escaping (how do you escape _?)
You don’t need to escape _ unless it has some special meaning to the command processor/shell. On Unix it doesn’t. Nor for Windows cmd.exe
> That means they're not using it since they don't have to deal with spaces as spaces vs as separators
The end-user isn't consciously using it. The software they are using is.
We are talking here about programmer-visible reality, not end-user-visible reality. Those two realities don't have to be the same, as in the "replace spaces with underscores and vice versa" idea.
> So how do you differentiate between a user inserting a space and a user inserting a literal _ in a file name?
Underscores are rarely used by non-technical users. It isn't a standard punctuation mark. Back when people used typewriters, the average person was familiar with using them to underline things, but nowadays, the majority of the population are too young to have ever used one. I doubt many non-technical users would even notice if underscores in file names were (from their perspective) automatically converted to spaces, since they probably wouldn't put one in to begin with.
I'm talking about the general reality (that you keep ignoring) and pointing out that it's much bigger than the programmer-visible one. For example, the "not many" non-tech users who would notice the broken unescaped underscores is a bigger group than all the programmers given how much bigger the base group is. You're just fine breaking their workflows just because a small group of professionals can't fix their APIs
But spaces in filenames are really just an inconvenience at most for heavy terminal users, and are a natural thing to use for basically everyone else. All my markdown files are word-word-word.md, but all my WYSIWIG documents are "Word word word.doc".
The hassle of constantly explaining to angry civilians "why won't it let me write this file" would be worse than the hassle of having to quote or backslash-escape the occasional path in the shell.