[nouseforaname]

Fun fact: -v typically stands for verbose except when using any "grep-like" utilities such as pgrep, pkill, etc.

[edit] forgot to mention that for grep-like utilities -v negates the match.

This led to an unfortunate incident in which I attempted to get verbose output from pkill and instead killed every single process on the machine except for my target. To make it worse I had no console access so I had to email another team to reboot and explain what I did.

[mehrdadn]

I'll get crucified for saying this but this is one of the differences between a CLI and a GUI. A button/menu item/etc. always tells you what it does (even if it's just a brief description) before you click it. A command line parameter, well, reduces the information redundancy to near zero... you have to go out of your way to figure out its meaning.

[WhitneyLand]

Hasn’t anyone tried to add some kind of interactivity to command line typing to eliminate this advantage?

Not something simplistic like keyword completion, more like the best state of the art code editors or ides.

In those environments its just text based still, but can be incredibly rich and efficient. You can get seamless acesss to info on any language command or param, predictive code completion suggestions, based on machine learning, easily refactor/correct parts of a line you’ve already started typing, etc.

The thing is it doesn’t have to get in the way if designed right. So someone can also just sit down and blaze away typing and ignore it.

[vram22]

>Hasn’t anyone tried to add some kind of interactivity to command line typing to eliminate this advantage?

One example: /bin/rm has the -i (for interactive option). Some people alias 'rm' (or if they are newbs, it is sometimes aliased for them by someone senior in their org) to 'rm -i', which helps avoid deleting files by mistake, due to typos or typing too fast. With -i, rm asks for confirmation before deleting each file. This is more important in Unixes because most of them do not have any undelete utility; nor does Windows, AFAIK, except for 3rd-party ones like the Norton Utilities (does it still exist?), which need to be installed. And installing the utility (if you can get it) after an accidental delete, has some chance of the utility getting installed onto disk blocks earlier occupied by the deleted file.

[xtreme]

While not as powerful, a number of modern tools support a --dry-run option which can be useful in avoiding mistakes.

[ken]

Unless you use a keyboard shortcut in your GUI, in which case all bets are off. I remember being constantly frustrated back in the Adobe Illustrator 10 / Photoshop 7 days that the standard shortcuts (like cmd-H and cmd-M) did something completely different than I expected.

I think this is one of the big problems with both CLIs and (most) GUIs. We're stuck in a particular mode of thinking. For CLIs, it's that pressing a letter key must append that letter (and only that letter) on the screen, like a typewriter. Traditional GUIs have their own problems, which I'm sure half the crowd here can recite in their sleep.

When developing my app Strukt, I discovered I really needed to decouple "how you type it on the keyboard" from "what it looks like on screen". You get autocomplete on all operations and flags, so you can type just the first letter of a flag, but still see the whole thing on screen. It appears that some other modern editors (like Atom) have adopted a similar system, which is great. Emacs, of course, has had this forever (but has its own UI issues). :-)

[amaccuish]

That's why I prefer the more wordy -- alternatives, like --verbose

[ken]

I use one-letter flags when working interactively, to save time, but my shell scripts always use the --verbose form. It makes them much easier to read.

[dredmorbius]

ctrl-W