Who on earth insists that? Only Windows programmers, I expect! But it's easy: make sure they're expressible in your syntax, then pass them through as part of the file name. Just like spaces. If there's a problem, you'll get an error back from the OS.
Yes, of course you're right. My apologies, it was a stupid comparison.
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.
I expect you mean NUL (ASCII 0) - but that's typically not a good choice, because POSIX decrees it invalid, along with '/'. But anything else is fair game, sure. Handling every Unicode char might be a pain, but that's the filing system's job, not yours!
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.
Depends very much on your programming environment: on Python I don"t care, but when doing bash scripting or makefiles (very often) I very much care.
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.
No, not really - I have no particular opinion about what POSIX chooses to support or not.
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.
Please write a makefile that uses an environment variable as a mysql password to connect to a mysql server and perform an arbitrary administrative task.
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.
No, not just because of the dollar. Because it's easier to test in isolation and allows you to use things like here docs which are useful for dealing with sql.
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.
