Hacker News Reader

Comment by foxfluff | Hacker News Reader

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.

View on HN

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).

So much of computing is dedicated to solving problems that could be omitted.

I mean, that's precisely my thoughts on copyright and licensing in general but what can you realistically do?

Realistically, on an individual scale, you can pretend it doesn't exist and go on with living your life?

I very much would if only that pesky State didn't persecute me for that. Apparently, when I refuse to acknowledge the copyright and software license terms, other people get upset to the point of bringing the wrath of that Leviathan of oppression upon me! The nerve of some people!

Seriously. Just get up from the computer and go do something else. /s

We computer people are truly an odd bunch.

> and shell completion rarely works well if at all

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.

I run fish. I was able to get long-option completion for gcc, polybar, firefox, man, emacs, xrandr, and fish itself. The only command I was not able to get long-option completion for was xinput. You just picked a bad program to try.

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.

getopt_long (and thus most GNU programs) work this way. I think it's probably a misfeature though since it means that adding a new option can introduce ambiguity. Having both short (ex. -x) and long (ex. --exclude) options is a less problematic solution.

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.

Reply on news.ycombinator.com