Ask HN: What are the best and worst command-line interfaces you have used?

Worst: sqlplus by Oracle. No autocomplete, no backspace, no history function. It's like nobody ever inside Oracle ever had to use this craptastic piece of software to accomplish anything.

EDIT: Oops backspace works. Might have been a combination of putty and sqlplus. Nevermind.

My niggle is with commands that cannot be composed, ie. consumed by other tools or shell scripts or built into pipelines. There are lots of small things that break composition: Not exiting with a non-zero code on error, sending error messages to stdout, not producing output that can be easily parsed by another command. Too many commands suffer from one of these problems, unfortunately.

worst is git by far.

i'm used to it now but when I was learning, "what the fuck did `git reset --hard` do? where is --soft? Is there a no-flag version? What the fuck did I leave mercurial for. God damn I miss svn."

I still kind of miss Mercurial and TortoiseHG.

I recommend reading this site: https://clig.dev/

I'm rather fond of pgcli at the moment, though I haven't used it long enough to get a brilliant feel for it yet.

I generally dislike interfaces which don't react well to terminal resizing, usually because they're trying to do something fancy with progress bars.

The ImageMagick utility mogrify.

By default (without specifying extra command-line options) it overwrites the input files. [1]

In decades of computer use, that is the only command line tool that tricked me into destroying my data because I didn't realize it works differently from all the other tools I use that don't do that.

Usually, a command line utility with less options specified is relatively "safe" and you have to add extra syntax to make it "unsafe".

It was definitely a violation of: https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

EDIT reply to: >The whole reason for mogrify's existence is that it overwrites the original image file.

Sure, I understand that but many other destructive tools will have safety UI features such as creating ".bak" backup files. That's what many other command line tools do including image utilities. So something like mogrify could have been designed with hypothetical syntax as "mogrify -nobackups". The principle is to type extra syntax to make it more dangerous while still accomplishing the (observable) goal of changing the original files.

[1] https://superuser.com/questions/1575004/imagemagick-how-to-a...

R dplyr is one of the best interface I have ever seen for manipulating data. I think one of Hadley’s biggest contribution to the world of data science. It feels like my brain can breathe out dplyr code

To me, openssl and nmap are the worst.

Kubectl is among the best: commands make sense and have internal logic, interface is discoverable, output is configurable and supports different formats.

The combination of mosh and screen has been a big productivity booster for me. The shell alias server1='mosh root@server1 -- screen -xRR -D' keeps the connection forever even if I change networks.

The only pity is that mosh breaks compatibility with earlier versions once in a while.

Nearly everything that packs or unpacks stuff. tar, gunzip, and else. I can never remember if they are going to unpack everything into a subdirectory or spill everything into my home, and conversely I never know if after zipping there's gonna be a directory inside or not. Luckily dtrx and atool do the thing you want most of the time.

From the time I was a teen I think I remember that mount was difficult to use, and mounting a CD image required passing some arcane options, though maybe I just didn't know how to use it (on the other hand I didn't know how to use Daemon Tools either, and it just worked).

I don't have a problem with git though. I don't think it's the command-line interface that's hostile, it's git itself if you don't know what you're doing. After taking some time to learn it I actually enjoy solving difficult problems with git.

Does something simple like htop count? I believe there's a bunch of other good stuff that uses ncurses as well.

Best is probably https://github.com/cli/cli

Not the worst (I think `tar` and `unzip` probably take the cake) but `find` is pretty atrocious IMO. The order in which you specify certain flags like `-maxdepth` relative to other option flags matters (not just relative to plain arguments, but relative to other option flags starting with `-`).

The best: an old CD player called Workbone on Slackware. It made great use of the number keys for pause/play/ff/rw/eject.

The worst: I used to work with an awful custom-built industrial computer.

You had to enter the 10-character alphanumeric codes of 98 rail cars into a command-line interface that didn't permit backspacing. One mistake. Car 97. Do it all again.

Many of the worst ones I've used have been embedded in physical devices - ethernet or fibre channel switches, disk arrays or controllers, etc. I've been around long enough that I don't expect every CLI in the universe to have things like history, command line editing, or autocomplete, so that's OK. On the other hand, many of these interfaces are wildly inconsistent and that bugs me. Some commands are object-verb and some are verb-object. Some are abbreviated, some are verbose. One command produces an identifier in format X, but the next command consumes it in format Y so you can't even use your terminal's copy/paste function. Excessive modality is another common problem in these interfaces. Which sub-sub-sub-mode was the command I needed in, again? Can't know without actually entering that mode, and then the next related thing you have to do is in a completely different part of the tree. Using such interfaces directly can be painful, and automating them is often inordinately difficult too.

Why is nobody hating on megacli? It's the only tool I use where I actually need a wrapper script. There are other horrible command line experiences, but nothing anyone here listed I would describe as horrible...

The Windows Resource Kit binaries come to mind. They were distributed together in the same ZIP, but:

1. They used differing return values for success and failures. Sometimes, a 0 was a success, sometimes 1 was a success, and sometimes only 4 was a failure, but everything else was a success.

2. They used different command-line switch formats. Some utilities used a hyphen, others used a forward slash.

> worst command-line interfaces

If you mean TUI wise as in curses, nearly all of them.

Command line parameters however, there are so many examples. Tar, unrar and unzip take the cake, all in the same category of tools. "unrar x" whatever it is, I always have to look it up. dd because of the way its parameters are specified: dd if=/dev/zero of=foo.bar bs=4096 count=1024 . It's all historical and I can live with it, but many of them at least have the saving grace that they have excellent manpages or you've used them so often it becomes second nature.

There should be a special place in hell for tools that combine short and long style command line options with a single dash. Like "foo -b a -r -baz 123" with "-baz" being a single option, because I will automatically add an extra dash there out of habit.

Coworkers discovering ncurses or some library around it tend to go on a TUI frenzy for a while, and it inevitably ends up being some convoluted mess nobody wants to use. I'll admit there's a few indispensable curses based tools, for instance top (and some variants along that line), but they're far and few in between. At most dialog comes to mind for dealing with prompts for end users, but I personally abhor it in anything but a setup or installation context.

Those very same coworkers also make tools with indecipherable command line options, often because they don't know the language they're working in has a standardized option parser library or module.

> best

I don't remember which tool it was, it could be "crm" (for failover, think like heartbeat and pacemaker) but I might be mistaken. It's been years since I've used it. The command line had options like so:

tool [options] section action resource_src resource_tgt

But the best part was, if you just started the tool without any options, it'd drop you into a pseudo-shell. It'd show you a blank prompt ending in ">". If you then typed "section" you'd end up with a "section>" prompt.

I remember for what I was doing with it, it felt really intuitive. At any point I could type "help section" and it'd list the available actions for that section, together with short example.

I've forgotten the real syntax, but you'd have commands like:

tool node status

tool node standby servername

tool service stop dns

tool service migrate dns secondary

If you were in the pseudo-shell, you could do:

$ service

service$ migrate dns secondary

service$ up

$ node

node$ status

node$ exit

I worked in a campus bookstore with an old terminal system to access the inventory database. It was a simple text interface. What I loved about it was that the commands to navigate were quick to learn (key was first chars in command) and the response time was instant. So you could jump to any part of the system with a few keystrokes ingrained in muscle memory.

I find it very easy to remember many terrible command line user interfaces, they are already mentioned in the discussion, but very hard to name a single great one.

Maybe a good command line user interface is one you don't notice nor remember. It just work smoothly. So I will start with cat.

I detest the MikroTik cli. I suppose the cli itself isn't terrible, but the fact that it's coupled with the mikrotik scripting language leaves a very bad, nearly rotten, taste in my mouth.

Two of my favourites are Watson and Homebrew. Very well thought out.

https://tailordev.github.io/Watson/

https://brew.sh/

rsync is probably my least favourite. I literally don't think I have ever correctly written a command that does what I intended on the first attempt.

I do like anything that's a nice well-structured representation of an API though – things like the AWS CLI are pretty good in practice, IMO.