What does the merit of spaces in file names matter? You still will need to deal with files with spaces in the real world. If your tooling doesn't support it, it's a non-starter for many.
A real world possibility.
If a user can’t paste any byte sequence, and expect it to work, then the tool is broken. I handle these cases.
When writing a shell script or makefile to deal with repetitive tasks if is easier to assume some things.
Even bash lets you escape unusual filenames for when you need them. Make will always explode your strings, and doesn't even attempt to let you escape them. I don't think it's unreasonable to expect a time-tested Unix tool dealing with files to actually handle all possible files.
Perfectly reasonable if spaces in filenames are a hard req.
In lots of scenarios they are not, and I prefer to assume that filenames have no spaces, and stick to make.
> touch "with<Ctrl+v><Tab>tab"
What about real world is, it is complicated.
Though I still feel it's a bit of "choose your poison". In any language, certain symbols will have special meaning. You pretty much have to pick which ones, and come up with rules about how to let their natural meaning bleed through. With unix shells, one such character is the space, and there's a number of rules about how to let their natural meaning bleed through - but they're all somewhat awkward, and they all need special care.
Most programming languages manage to get this right. You have a quoting syntax with an escape character that lets you express the quotes, the escape character, and any arbitrary character (as a byte sequence, as a Unicode codepoint in some encoding, etc.) as well. Now you can do everything. Why not do this?
I'm not going to say this won't be a pain if you decide to write out every file name possible, because it will be, inevitably. But you can supply alternative syntaxes by way of more convenient (if limiting) shorthand - Python has its r"""...""" notation, for example, allowing you to express the majority of interesting strings without needing to escape anything.
You might argue that I've just punted the problem on to the text editor and the filing system. You'd be quite right.
I have recently decided to stop using $ in passwords (defined by me) for that same reason: of course they are valid char, but they are such a big pain to support in usual contexts that it is simply not worth it.
(Thanks for correcting the nul reference)
But I'm going to go back to my original point. What I do have an opinion about is how reasonable it is for tools not to support a character that is valid in file names, when that character is straightforward to support with everyday, well known syntax.
And when that character is ' ', the standard English word separator, as straightforwardly supported by approximately ever kind of quoting or escaping syntax ever, my opinion about a lack of support is: it's crap.
Now do the same, assuming that the password can have a dollar in it.
You can do it. It is not as easy, readable or maintanable. Avoid it if you can.
Somehow we started with a single dollar in a string, and now I am dealing with sql, here docs, and TDD?
There is a place for everything in life: for small helper makefiles, which I write simply to support me in my workflow and even to remember some interesting commands that I need to run for a certain project, I can assure you that making some simple assumptions helps me staying halfway sane.
Extra complication to avoid if possible.