and steve's & edy's taxes.xls and 10" deck.doc and Surprise!.mov and... all the other shell active characters which are otherwise just normal characters that normal people will want to use.

If it's on the keyboard, they expect to be able to use it.

I disagree. There's also a Return key, but you don't want CR in file names. A file name is not a document's title.

> There's also a Return key, but you don't want CR in file names.

I don't want CR in file names, but someone somewhere will want it for some strange formatting reason (I've seen things).

> A file name is not a document's title.

You say that, other people have other ideas. When you let non-technical people use your too technical system, it will crash.

---

A software tester walks into a bar.

Runs into a bar.

Crawls into a bar.

Dances into a bar.

Flies into a bar.

Jumps into a bar.

And orders:

a beer.

2 beers.

0 beers.

99999999 beers.

a lizard in a beer glass.

-1 beer.

"qwertyuiop" beers.

Testing complete.

A real customer walks into the bar and asks where the bathroom is.

The bar goes up in flames.

1, Return is not a glyph.

2, Never the less, people do actually expect to use even that.

And they're not even wrong. It's not their fault that it breaks things.

In Windows they get away with it beacause for most users there is no such thing as a command line which is actually at least 2 little programming languages combined with special syntax (the shell itself and readline, and maybe even the tty line discipline and stty settings count as yet a 3rd little dsl in there, maybe even the terminal emulation counts as yet another!).

All input, including entering filenames, even when you have to type them, goes through fully managed input widgets that allow almost everything, and they catch and reject the few things they must right on input.

I've written things that take user input and url-encodes it for the matching filename myself, so that the user can do whatever they want, yet the the filename remains convenient and safe, yet still directly human legible & meaningful unlike base64 or random hashes.

That interface with I guess no less than 4 different layers of special syntax which is a shell, is useful but it's really not something to expect anyone but a programmer or technician to have to deal with. All the cases where a "bad" filename breaks something are just examples of the application's internals leaking out and being exposed to the user, which was always wrong since that's also the basis of all security exploits.

It's like taking that urlencoded data I mentioned and dropping it directly into printf, segfault, and complaining that the user should know better than to include %d in a text input.

I don't understand if you agree or disagree with me. When you say that you have written things to encode user input so that no "bad" characters (among which I assume you include CR) end up in the filename, you seem to agree that it's not enough for CR to be in the keyboard for it to be automatically allowed in filenames. Which was my point.

Yeah the big mistake was thinking spaces in file names was a good idea. It's not it's a terrible awful idea.

Course not have a hard separation between paths and file names is also not good.

  ./folder_what/folder_x/folder_zee:file_name.whatever

The above would be better

I mean, I don't see why I should work around legacy limitations of 1970s software today, whenever I use a computer. Otherwise we might as well decide that file names should have no capitalization and be eight characters long, or that paths should be limited to 127 characters, etc.

How would it be better? Lots of names for people & things include spaces, so file names related to those people or things naturally would also include spaces. John Smith's name is John Smith, not John_Smith or JohnSmith or johnsmith or any other mangling.

Yeah and still you shouldn't break your encoding in such a gross way just because of that.

Also please for the love of god do not use peoples names as file names because they are not unique and they change oftener than you think.

Not every usage of files is going to be at a scale where we have to worry about collisions, and anyway it's tangential.

Whatever the concern, the ship has long since sailed on spaces in filenames, it's not going to be undone, and we are obligated to handle them.

> I know that I found it quite disorienting when I first started interacting with Windows/macOS users who regularly used spaces in their filenames and thought nothing of it.

At least most Windows users are "trained" by the Windows that asterisk, question mark, vertical bar, double quote, prefix and suffix spaces "aren't valid characters for files" (in a weird way, it's a Windows limitation, not a NTFS one). I expect only the worst (case insensitive stuff) naming schemes when the files comes from a macOS user.