Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs).
And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.
Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI...
But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting.
> Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting.
Ah I see, you have a file "new 2.txt", I was a bit confused.
Not sure what you mean by only 1 level of quoting being a problem, sorry.
That's a great point. Computers sure have the potential to deal with spaces just fine. But if textual interaction is a requirement, we can only have one of arbitrary filenames and clutter-free syntax.
Window and Linux shells have the same ideas about spaces in file names, which is that if they appear they need to be quoted or the space character needs to be escaped.
Outside of Make which has long and boring historical reasons for not supporting spaces well, just about every program is fine with spaces.
To be fair to modern desktop users, a command line that doesn't redefine the word "command" to fit the constraints of the system would look something like this:
$ take this list of transactions and for each group of duplicate names show me the name and total dollar amount spent, sorted from highest to lowest
$ I think I have a SQL command for that. Are you feeling lucky? [y/n] y
> Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs,
A similar trend is happening in electronic communication: from letter to email, to text, to emoji's. The text is just one historical communication way and there's no reason it should be of any real interest to modern communicator as long as we have emojis ... wait, we've been there before.
There is such a thing as a cluttered graphical interface, and some complexity cannot just be abstracted away.
> The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.
That would be like saying that because I am able to write "First open this app by clicking on the upper-left icon, then click File, new File", would mean that text is a superset of the GUI because it can describe visual cues. An abstraction can always replace another, it does not mean it is a superset of it.
Take the source code for your GUI application, this is pure text. In the early days, there was shell code that would describe terminal GUI of sort to configure the linux kernel. This shell code is still commands read token per token with matching behavior. Because an abstraction can be traded for another (which could be argued to be a founding principle of computer science), does not mean that one is a superset of the other.
And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.