Comment by martin-t
4 years ago
I find this attitude misguided. More descriptive names are more ergonomic for things you only use rarely but they need to be combined with much better autocompletion than most shells provide by default.
4 years ago
I find this attitude misguided. More descriptive names are more ergonomic for things you only use rarely but they need to be combined with much better autocompletion than most shells provide by default.
You state that as if that were objective.. but that's not my subjective experience at all. Somehow I have a hard time remembering these long names, (is it --conf or --config or --config-file or --config-path? -c would've done it for me. --set or --set-prop or --set-property or --prop or --property?), and I need to look them up in a man page anyway, and I make more typos typing them, and shell completion rarely works well if at all. I also find it harder to read and edit long lines that wrap.
Somehow these short letters stick much better for me, and the effort for finding them in the manual is the same, although in case of extra complexity as with xinput, it's even worse with the long names. I don't use either command often, but it's hard to forget xset m. The only thing I remember about xinput is that it's a horribly long lithany of things which I need to look up every time, and the syntax still feels weird.
The shell ought to be able to help with that. There's no need to remember if it's --conf or --config if you can press --conf<tab>.
One of the things I like about Fish is that by default it can tab-complete program options and also shows a one-line description of what each of them does. (It grabs that info from the man page).
I just tried fish. xinput --set-[TAB] and nothing. Apparently it doesn't understand the standard long-option format that is supported by xinput and documented in the man page. You have to know to omit the dashes and then it'll complete. And it's downhill from there.
Yeah I used to have all kinds of simple as well as supposedly sophisticated completion setups with zsh years ago but I've given up on it since then. It's always half-assed and half the time causes more problems than it solves. Same with bash. There are some places where I must resist the urge to try complete a filename because the shell starts trying to figure out which target it can complete from a Makefile in a large build system and just freezes. The only practical way out is to interrupt and type the command again or wait a stupidly long time. There are other issues like completion trying to be smart and filtering out things it thinks you don't want to complete. Nothing is more frustrating than a shell refusing to complete a filename that you know is there.
1 reply →
So much of computing is dedicated to solving problems that could be omitted.
4 replies →
> and shell completion rarely works well if at all
I'm with you. Terseness is paramount.
I could never overcome my repulsion for Java and ObjC because of that. On the other hand, I fell at home with crazy RegEx that look like line noise to most people.
I think shells could use something like a built-in eldoc[1], in addition to tab completion. It would make terse command line interfaces much more usable if you could see what the positional arguments were for.
[1]: https://docs.cider.mx/cider/config/eldoc.html
I hate .methodNameAsLongAsMyArm as well, but there's the opposite extreme:
As a beginner, I liked short variable names. When I came back a few months later, I learned my lesson. Years later? easier to just start over.
the most used options for properly written tools have both short single char option like -c and long-form version --config if you need verbose self-describing option.
If you are using cli tools of github written by a random person, then no wonder you will see non-standard approaches to UX.
PowerShell takes an interesting approach in that it accepts any truncated variant of a long-form flag as a short form, provided it isn't ambiguous (i.e. if the interpreter can't decide which long-form flag to expand a short-form flag to.)
For example, if a command features a "-ConfigFile" flag, valid short-form variants include "-C", "-Co", "-Con", "-Conf", and so on. But if the command featured an additional flag "-ConfigURL" for example, the aforementioned short-form flags would be ambiguous.
1 reply →
The few scripts that I've written for personal use generally lack documentation or help commands of any sort; instead, they take all possible straightforward variants I can think of for each command (`--config`, `--config-file`, `--cfg`, `--conf`, etc). They usually convert everything to lowercase before processing, too. It's easier to fail safely on too much/too little input than it is to provide actual help.
I like long form version. It helps me remembering what it does and why. Eg: `iptables --insert INPUT --protocol tcp --jump ACCEPT` was more helpful to me than `iptables -i INPUT -p tcp -j ACCEPT` when told how to allow TCP traffic.
For everyday command like `ls -l` I don't mind but anything more serious I take a more cautious approach.
Spaces don't make anything more descriptive, they just cause completely unnecessary quoting and escaping hassle.
The amount of time that has been wasted by Windows using "C:\Program Files" instead of "C:\Program_Files" far outweighs any highly questionable aesthetic benefit IMO.
On the other hand, how much broken code has been fixed to properly deal with paths just because of that? I'd argue that to be a major benefit. Same with Windows Vista forcing developers to write applications that work properly as a non-admin user.
Short option for interactive terminal. Long option in automation.
I’ll be damned if I have to remember or lookup what -n means to some obscure program, when reading someone else’s script. Exception given for super common tools where everybody knows like ls -la.
With the disclaimer that shell scripts, especially ls, aren’t exactly suitable for reliable automation in the first place.