Regardless of what the app does and whether the thing that does is particularly useful, powerful or important for what you need to do (or even well implemented), what is a command-line interface that you had a particularly good experience both learning and working with?

In other words, I’m thinking about command line interface design patterns that tend to correlate with good user experience.

“Good user experience” being vague, what I mean is, including (but not limited to)

  • discoverability–learning what features are available),
  • usability–those features actually being useful,
  • and expressiveness–being able to do more with less words without losing clarity,

but if there’s a CLI that has none of those but you still like it, I’d be happy to hear about it.

Edit: Trying to stress more that this post is not about the functionality behind the tool. Looks like most of first responders missed the nuance: whether app x is better than app y because it does x1 ad x2 differently or better does not matter; I’m purely interested in how the command line interface is designed (short/long flags, sub-commands, verbs, nouns, output behaviors)…

  • SayCyberOnceMore@feddit.ukEnglish
    3·
    11 days ago

    nmon

    That, along with tmux and htop, are installed on everything I have.

    nmon then ld- give me a system health page that shows me where the bottleneck is.

    It’s interesting to see how a system behaves when you’re doing something like a backup… it’s not always what you think.

    • netvor@lemmy.worldOPEnglish
      1·
      1 day ago

      Don’t want to sound unappreciative, but the apps you refer to (and others in these threads) are not actually CLI’s but TUI’s.

      • CLI (command line interface) is when all interaction actually happens in the command line, ie. command + arguments. CLI’s are much simpler to implement, have little dependencies (pretty much just argument list, two data streams—stdout and stderr–and exit status) and typically one invocation means one independent task. All this makes CLI’s ideal as building building blocks of (semi-)automated workflows, but many CLI’s are also optimized for direct invocation from interactive shell, eg. by adding features such as output coloring, interactive yes/no steps or command completion (although that part is actually driven by the shell, and is quite independent from the execution of the app.)

      • TUI (text user interface, i think) on the other hand, is more like GUI but replicated within the confines of terminal emulator. The interaction heavily depends on terminal features such as moving cursor, resize notifications, etc. Also when TUI is ran, it’s normally used for zero to may tasks: e.g. I could start htop and investigate no process, 1 process or many, before quitting. Unlike CLI’s, TUI’s pretty much make no sense within automation.

      Don’t get me wrong: I love TUI’s (htop is one of my favorite and thanks for recommending nmon, i’ll have a look)–and often prefer them to GUI’s (eg. my text editor is nvim, which is a TUI app!), but in my post I was specifically interested in exploring CLI’s. I would actually love a similar post to mine but focusing explicitly on TUI’s as opposed to CLI’s.

      Sorry for long post – I hope it can kind of serve as explanation for people who are new to this and stumble upon this thread and aren’t quite familiar with the distinction.