[HN Gopher] Ask HN: What are the best and worst command-line int...
___________________________________________________________________
Ask HN: What are the best and worst command-line interfaces you
have used?
I am interested in learning what makes a great (or terrible)
command-line interface. What are some of the best and worst
command-line interfaces you have used?
Author : de_keyboard
Score : 20 points
Date : 2021-11-24 13:07 UTC (9 hours ago)
| sergiotapia wrote:
| 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.
| amznbyebyebye wrote:
| Agree it is one of the most unintuitive cli I have ever used.
| If it's really just manipulating a DAG, I wonder if a rewrite
| is possible with this in mind.
| linspace wrote:
| Some day I will burn a day of my life to learn it inside out
| and be done with it. Meanwhile I use magit.
|
| Mercurial was much better IMO but people argued about
| performance, because, you know, the CPU is the bottleneck when
| I merge code. How much time has been wasted navigating Stack
| Overflow?
| MontyCarloHall wrote:
| The worst thing about git is how commands are inconsistently
| overloaded.
|
| `git reset` both unstages files (opposite of `git add`,
| straightforward enough) but also can move the current HEAD
| pointer to an arbitrary commit. You'd think it could then also
| discard unstaged changes, but nope, that's `git checkout --
| ...`, which incidentally has nothing to do with `git
| checkout`'s other functionality of switching branches.
|
| There are so many other examples of this. `git rebase` can not
| only rebase but also combine and reorder commits via `rebase
| -i`, which seems totally unrelated to rebasing. `git branch`
| and `git checkout` have overlapping but also distinct
| functionality. I could go on for hours.
| zombietfk wrote:
| 100% agree with this. The nomenclature of the commands always
| felt too similar for different things to me, i.e. reset vs
| revert, checkout vs fetch vs pull. Feel like there could be
| much more descriptive and distinct names.
| horstbort wrote:
| Obligatory: https://git-man-page-generator.lokaltog.net/
| bduffany wrote:
| 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 `-`).
| BoxOfRain wrote:
| `find` is definitely one of my least favourite among the
| traditional Unix tools in terms of interface. `dd` is also a
| little weird with its syntax but at least I rarely have to use
| `dd`.
| thiht wrote:
| I don't know, once you take the time to learn \find` it's ok.
| You always use mostly the same flags anyway.
|
| \fd` is a worthy successor of \find` though.
| _dain_ wrote:
| >I don't know, once you take the time to learn \find` it's
| ok.
|
| this could apply to literally anything. my time is not
| infinite.
| discord23 wrote:
| > 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
| gerbercj wrote:
| I recommend reading this site: https://clig.dev/
| codemusings wrote:
| 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.
| MontyCarloHall wrote:
| A lot of people forget that the default shells of many *nix
| systems through at least the mid 90s did not support any of
| these. No line editing, no interactive history (primitive
| !-based history doesn't count), no completion.
|
| Occasionally I'll still encounter an environment that only has
| a minimalist implementation of sh (e.g. some busybox builds)
| and be totally stymied. It amazes me how much people
| accomplished on old *nix systems with such abysmal usability.
| rwmj wrote:
| 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.
| qsort wrote:
| Honestly that's the drawback of unix-ish interfaces. Don't get
| me wrong, text first is usually a sane default, but there is
| also value in an interface like Powershell, where you would
| write your program as a Cmdlet that returns an object-like
| response.
| frou_dh wrote:
| One that's unfortunately quite common is unconditionally
| outputting ANSI colour escape sequences even when the output
| isn't the terminal.
| BoxOfRain wrote:
| 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.
| cr3ative wrote:
| I generally dislike interfaces which don't react well to terminal
| resizing, usually because they're trying to do something fancy
| with progress bars.
| jasode wrote:
| 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...
| cozzyd wrote:
| well, use convert instead. It's the only difference...
| captn3m0 wrote:
| > mogrify - resize an image, blur, crop, despeckle, dither,
| draw on, flip, join, re-sample, and much more. Mogrify
| overwrites the original image file, whereas, convert(1) writes
| to a different image file.
|
| The whole reason for mogrify's existence is that it overwrites
| the original image file.
| linspace wrote:
| > The whole reason for mogrify's existence is that it
| overwrites the original image file.
|
| Then it should not exist. To save one "rm", doesn't look like
| a good idea to me.
| MontyCarloHall wrote:
| It would be much safer to take the sed approach and put
| mogrify's functionality under `convert -i[backup extension]`,
| and dispense with standalone mogrify altogether.
|
| Imagine having the command "sedd" aliased to `sed -i`. It
| would be a usability nightmare.
| makeitrain wrote:
| 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.
| gaws wrote:
| Do you have more details about software?
| [deleted]
| amznbyebyebye wrote:
| 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
| stackedinserter wrote:
| 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.
| sam_lowry_ wrote:
| Nah. Kubectl is so verbose that it reminds me of typing xslt in
| my younger years.
|
| k9s would save us all from carpal syndrome, but it's a curses
| UI, not a cli.
| urxvtcd wrote:
| openssl reminded me of gpg, wow, this one is horrible, and
| manuals don't help at all.
| Cicero22 wrote:
| 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.
| sam_lowry_ wrote:
| 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.
| gaws wrote:
| Why use screen when tmux, an improved version, exists?
| urxvtcd wrote:
| 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.
| LittlePeter wrote:
| Relevant xkcd comic: https://xkcd.com/1168/
| cozzyd wrote:
| tar --version
| rspoerri wrote:
| tar -czf ./file.tgz ./*
|
| edit: i do hope that is correct without checking :-)
| urxvtcd wrote:
| So the dash in `-czf` if optional? Which reminds me: why
| does ps have two sets of options again?
| atsaloli wrote:
| Don't laugh, it's actually three sets of options now:
|
| - UNIX options, which may be grouped and must be preceded
| by a dash.
|
| - BSD options, which may be grouped and must not be used
| with a dash.
|
| - GNU long options, which are preceded by two dashes.
|
| Reference: https://man7.org/linux/man-
| pages/man1/ps.1.html
| tombl wrote:
| As an alternative to atool I've always used The Unarchiver's
| cli version[0] which has been able to handle basically anything
| I've thrown at it correctly.
|
| [0]: https://theunarchiver.com/command-line
| Ristovski wrote:
| A very handy tool for this is https://www.nongnu.org/atool/
| doteka wrote:
| Long ago someone taught me this memory trick for tar: imagine
| an angry German stereotype saying "eXtract Ze Vucking File",
| thus -xzvf. No idea what it stands for but it does what I need
| most of the time.
| timbit42 wrote:
| x = extract, z = compress/decompress, v = verbose (list files
| added or extracted), f = filename follows.
|
| You can leave off the 'z' if it's a tar without compression.
| If it's compressed, the extension is usually tgz, tar.Z, bz2,
| or something else other than tar.
|
| You can leave off the 'v' if you don't want to see a list of
| which files are being added or extracted.
| mvkg wrote:
| In recent versions of (maybe only GNU?) `tar` you can leave
| off the `z` flag and it will still decompress based on the
| filename.
| thunderbong wrote:
| This is a pain in the GUI tools as well
| notacoward wrote:
| 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.
| cpach wrote:
| Two of my favourites are Watson and Homebrew. Very well thought
| out.
|
| https://tailordev.github.io/Watson/
|
| https://brew.sh/
| randomluck040 wrote:
| Watson seems interesting, I'll take a look at that. Thanks for
| sharing!
| speedgoose wrote:
| 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.
| bjourne wrote:
| Maybe cli's aren't good for interacting with computers? Heresy
| I know. ;)
| blakesterz wrote:
| Does something simple like htop count? I believe there's a bunch
| of other good stuff that uses ncurses as well.
| nikivi wrote:
| Best is probably https://github.com/cli/cli
| visiblink wrote:
| 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.
| matthewmacleod wrote:
| 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.
| runjake wrote:
| 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.
| BlackLotus89 wrote:
| 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...
| notacoward wrote:
| Megacli is definitely one of the examples I was thinking of
| when I said many of the worst CLIs are embedded into physical
| devices. What a piece of trash.
___________________________________________________________________
(page generated 2021-11-24 23:03 UTC)