3 ms·

I disagree partly here: hitting tab twice in a shell usually lists available commands, possibly with some prefix. A GUI has the advantage of context, in that

I disagree partly here: hitting tab twice in a shell usually lists available commands, possibly with some prefix. A GUI has the advantage of context, in that eg menu items of the disk utility make sense as you know they’ll be some operation on disks. On CLI eg I don’t remember the mkfs command for a file system, I type mkfs and hit tab twice. It could be better though, of course.

pjmlp 8y ago
That is the problem right there, you need to know mkfs exists to start with.
- kurtisc 8y ago
  apropos file system You'll be searching (or using previous knowledge) for what you need to format it as, anyway.
- marmaduke 8y ago
  Well one needs to know the Disk Utility exists as well, or disk management thingy in Windows.
  - pjmlp 8y ago
    Sure, but that is available on a simple right mouse click on the device. In any case you are focusing too much on mkfs, I can think of plenty of other examples, many of each aren't even portable across UNIX environments. While GUIs at least can offer navigation and visual cues as means to discover features.
vram22 8y ago
A major issue with GUIs is that they are not scriptable [1], at least in the way CLIs are, like with a bash-like shell and all the stuff of the Unix philosophy [2] (I/O redirection, pipelines, wildcards, other Unix special characters that expand to, or mean, something (all of which you can use in your command pipelines). [1] I mean, I know there are some tools to automate GUI tasks, like AutoHotkey, AutoIt, etc., but due to various window-related issues, they are fragile, I've heard. Not saying that this makes CLIs superior for all uses, of course. Just better for some. [2]: http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html
setr 8y ago
One issue is that cli apps expect a man page to be available, and that you’ll be willing to read it, so options by name alone tend to be more obtuse. Better if you already know it, worse when you dont. Eg ffmpeg is confusing no matter what, but the cli is particularly obtuse in how options interrelate (or even the format string required for them!). A gui for ffmpeg will naturally have fewer options (less expressive), related features to an option will be grouped by windows, and might even do things like visibly disable options based on current flags set, or even a preview mode. You could probably get by to a certain degree, when new to the program, on an ffmpeg gui for simple operations; even the most basic action of cli will be difficult just reading the options appearing by 2xtab. There’s simply a lot more a gui can do to help the learning/interactive process than a cli can (tui is a different story: its just a gui that happens to be in your terminal, and offers the same positives/negatives that any other gui does).

pjmlp 8y ago

That is the problem right there, you need to know mkfs exists to start with.

kurtisc 8y ago
apropos file system You'll be searching (or using previous knowledge) for what you need to format it as, anyway.
marmaduke 8y ago
Well one needs to know the Disk Utility exists as well, or disk management thingy in Windows.
- pjmlp 8y ago
  Sure, but that is available on a simple right mouse click on the device. In any case you are focusing too much on mkfs, I can think of plenty of other examples, many of each aren't even portable across UNIX environments. While GUIs at least can offer navigation and visual cues as means to discover features.

vram22 8y ago

A major issue with GUIs is that they are not scriptable [1], at least in the way CLIs are, like with a bash-like shell and all the stuff of the Unix philosophy [2] (I/O redirection, pipelines, wildcards, other Unix special characters that expand to, or mean, something (all of which you can use in your command pipelines). [1] I mean, I know there are some tools to automate GUI tasks, like AutoHotkey, AutoIt, etc., but due to various window-related issues, they are fragile, I've heard. Not saying that this makes CLIs superior for all uses, of course. Just better for some. [2]: http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html http://www.catb.org/esr/writings/taoup/html/ch01s08.html

setr 8y ago

One issue is that cli apps expect a man page to be available, and that you’ll be willing to read it, so options by name alone tend to be more obtuse. Better if you already know it, worse when you dont. Eg ffmpeg is confusing no matter what, but the cli is particularly obtuse in how options interrelate (or even the format string required for them!). A gui for ffmpeg will naturally have fewer options (less expressive), related features to an option will be grouped by windows, and might even do things like visibly disable options based on current flags set, or even a preview mode. You could probably get by to a certain degree, when new to the program, on an ffmpeg gui for simple operations; even the most basic action of cli will be difficult just reading the options appearing by 2xtab. There’s simply a lot more a gui can do to help the learning/interactive process than a cli can (tui is a different story: its just a gui that happens to be in your terminal, and offers the same positives/negatives that any other gui does).