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)…
Honestly, incus.
I know it’s not strictly a utility, but holy cow, Stephane Graber and his team have put the work into that product, such that anything you can do in the ui can be done in the CLI, and more.
Tab completion entries for all the resource types (storage, instances, image repos, etc), help entries for everything, it brings a tear to the eye.
I once thought it was cool to have standardised man entries, but even better is context-sensitive
--helpentries that work well. Almost all the discovery I’ve made using incus, I’ve made using the commands themselves.It’s a real testament to how putting in the documentation work might be tedious, but it is a boon to both users and devs.
Favourite CLI I’d say is Junos. Structured, hierarchical, flexible.
Ncmpcpp. I’ve been using it for so long that using other cli music players is almost a no go. Learning a new muscle memory wouldn’t be worth it. Album art would be nice but I’m listening to music and staring at the album art for hours. The metadata editor is really nice. It’s old reliable.
My RSS shell script that simply dumps the XML’s content nicely formatted on stdout. Seriously, why do all of them have to impose some opinionated TUI on me? Terminals can do bold, dim and underline, that’s enough.
Sorry no, not public. It’s faulty and ugly and is missing features (multiple sources for one) and i want to rewrite it in python since at least 2 years.
Pure cli or also TUI? When it comes to TUI probably yazi is my most used tool right now, use it pretty much every day. For pure cli i would probably give my vote to sed. I use the crap out of it in a bunch of scripts. For example i switch my themes with it by replacing whatever import i had in the config to the desired theme, then reload the programs.
I think
gitis the obvious choice, both in ergonomics and flexibility (custom commands). But maybe I’m just using it so much I don’t recognize the sharp edges as much anymore.docker’s cli makes a lot of sense to me. Anything that supports “application logical-command --help” gets a big tick.
But yeah, bash itself is great.
A well-designed CLI? Maybe
sed. A badly designed CLI? Probably alsosed.findandrename/perl-rename/prename(depending on your distro), are two of my favorite cli tools. I generally find both well designed and easy to use. For me, they are indispensable.I think
findUI is so bad every time I use it I think about hacking a script just to make it simpler for my use case. At the same time I am very reluctant to use one of this new versions of standard commands trying to reinvent the wheel.Some things I don’t link about
find:-
How the directory needs to be the first argument. I get the reasoning but it is such a pain, specially if you are using it with the same query repeatedly in different paths.
-
The parenthesis to set order of matches, you are doing it in the shell so you have to escape them which is never fun.
-
The fact that
-namedoes not match partial names and there is not a version that do so you have to keep doing stuff like-name "*foo*"and of course you have to escape that shit or risk you shell expanding it. Having the GLOB version is nice but there could have a more ergonomic way to do this type, which I assume is a very common use case. -
Actually, doing more complex logical matches is always a pain and it would be nice to have a easier way to do some common operations.
-
The fact that when you do some complex match then the
-printis not automatic anymore or the the behaviour is kinda weird. And is a pain to add it in all logical branches or do it in a way that you do not repeat a lot.
Anyway, sorry for the rant.
Hahaha. No apology needed. And honestly, all fair points.
-
No-one mentioned ‘jq’ yet.
Maybe there’s a reason for that!
what do you mean? jq is great!
man
man man
nmonThat, along with
tmuxandhtop, are installed on everything I have.nmonthenld-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.
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.
Ok, fair point
-
i’ve been a big fan of Jujutsu (
jj) since adopting it a few weeks ago. things i used to avoid with git like proper rebasing and focused commits become so much easier, in addition to the benefits of conflicts being easier to handle. the learning curve i thought was going to be grueling only took a couple days to get used to, and honestly interop with GitHub and my team’s particular workflow were the hard parts. so not only is it useful, powerful, and becoming more important to my workflow all the time, it’s a joy to use compared to git.i guess honorable mention to zoxide, which has basically replaced
cdfor me since it does everythingcddoes but also keeps a small db of your most commonly visited directories so you can just doz Downloadsorz my_projector whatever from any directory




