Unpopular opinion maybe, but that’s just called bad programming.
For strictly code we can’t use spaces obviously, user input, on the other hand, should be handled gracefully always, not doing so is like those platforms that only supported ASCII even after the international userbase was already very prominent because the devs were just too lazy to update their systems to use Unicode (Windows is still like that with Powershell I discovered recently… shudders)
It’s an unpopular opinion because you’re belittling programmers without proper considerations. You rather get features or you rather people spend their entire lives sanitizing the living hell out of their code to catch every scenario. That’s not to mention user input errors.
The problem stems from the fact that spaces are what’s used to separate command lines arguments. That’s your separator character. Using the separator character inside of an argument causes headaches for everyone involved. By avoiding the separator character, you will have less issues, the developers will have less issues, and you can keep getting features you actually want.
Keep in mind, this does not apply to anything beyond cli input. UIs have field input separation. URLs force a conversion of special characters using their own scheme as well. A different example would be the use of " inside a string wrapped by ". It’s doable, but you will have much less problems if you use a different string wrapper character assuming your language supports it.
As a programmer, I disagree. This isn’t the users fault, it’s the shells and filesystems for being too permissiv. Honestly the shell is a bad choice for pin point acting on files anyways. I say this as a heavy user but selecting files is the most annoying part of using the shell and the solution isn’t warping your filenames to make them easier to type without shell weirdness, it’s using tools built to prevent these issues. That can either be tab complete (with zsh it auto escapes shell characters) or a terminal file manager like lf.
Well yes, we use double quotes as you said, it may be annoying, but not difficult, sanitization is another matter.
I actually don’t remember of any terminal application that has issues with that, that’s why I made the original question
Edit: I understood now why you mentioned sanitization, double quotes shouldn’t be an issue because in filenames they are forbidden by the OS usually, that’s on the user if they try
Eh, they really don’t. Maybe in shell scripts or when using a shell interactively but basically any modern language (read post perl) supports spaces fine and without any issue. only shell scripts with bad quoting show problems.
Oh no, white spaces are horrible. They cause lots of headaches for programmers constantly. There are just plenty of other separators to use.
Unpopular opinion maybe, but that’s just called bad programming.
For strictly code we can’t use spaces obviously, user input, on the other hand, should be handled gracefully always, not doing so is like those platforms that only supported ASCII even after the international userbase was already very prominent because the devs were just too lazy to update their systems to use Unicode (Windows is still like that with Powershell I discovered recently… shudders)
It’s an unpopular opinion because you’re belittling programmers without proper considerations. You rather get features or you rather people spend their entire lives sanitizing the living hell out of their code to catch every scenario. That’s not to mention user input errors.
The problem stems from the fact that spaces are what’s used to separate command lines arguments. That’s your separator character. Using the separator character inside of an argument causes headaches for everyone involved. By avoiding the separator character, you will have less issues, the developers will have less issues, and you can keep getting features you actually want.
Keep in mind, this does not apply to anything beyond cli input. UIs have field input separation. URLs force a conversion of special characters using their own scheme as well. A different example would be the use of " inside a string wrapped by ". It’s doable, but you will have much less problems if you use a different string wrapper character assuming your language supports it.
As a programmer, I disagree. This isn’t the users fault, it’s the shells and filesystems for being too permissiv. Honestly the shell is a bad choice for pin point acting on files anyways. I say this as a heavy user but selecting files is the most annoying part of using the shell and the solution isn’t warping your filenames to make them easier to type without shell weirdness, it’s using tools built to prevent these issues. That can either be tab complete (with zsh it auto escapes shell characters) or a terminal file manager like lf.
Well yes, we use double quotes as you said, it may be annoying, but not difficult, sanitization is another matter.
I actually don’t remember of any terminal application that has issues with that, that’s why I made the original question
Edit: I understood now why you mentioned sanitization, double quotes shouldn’t be an issue because in filenames they are forbidden by the OS usually, that’s on the user if they try
Eh, they really don’t. Maybe in shell scripts or when using a shell interactively but basically any modern language (read post perl) supports spaces fine and without any issue. only shell scripts with bad quoting show problems.