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)…
There are many modern alternatives to common Unix commands, often written in rust, or provided in Nushell, that showcase that. Here are some common themes I like:
Good defaults: You shouldn’t have to memorize
tar -xzvfjust to extract a tar file; The thing you’re most likely to want to do should be the default. But other use cases should still be achievable through the use of flags. Make simple thing easy and difficult things possible.Subcommands: It helps separate and discover the different functions of a CLI. Paired with a help subcommand, you can quickly look up information for the subcommand you’re actually interested in.
Domain specific languages: Many problems already have a solution in the form of a DSL, such as Regex or SQL. My favourite example for this is
httpie, which lets you specify the type, body and parameters of an HTTP request without touching any flags.I also much prefer long options over ones, because they are self-documenting.
Does no one read man pages anymore? This is not a personal attack but I am baffled people don’t set up bash completion correctly and then can’t “discover flags” (or just read the manual).
I would not want tar that automatically “does what it thinks I want” useful… am l out of touch or the kids being wrong
Anything to replace firewall-cmd? (I know about ufw but it just feels too simple for my use case).
firewall-cmdcommands are all fucked up and it feels like they use different verbs for very similar actions. Plus- - helpis a few miles long which is not helpful. I just wish that it would have subcommands. Something likefirewall-cmd zone public infoI actually like tar. Yes, it could have a default, but its also from another time. And remembering Xtract Zip File is not that hard. (v is for verbose for those wondering)
extract () { if [ $# -ne 1 ] then echo "Error: No file specified." return 1 fi if [ -f "$1" ] ; then case "$1" in *.tar.bz2) tar xvjf "$1" ;; *.tar.gz) tar xvzf "$1" ;; *.tar.xz) tar xvf "$1" ;; *.tar.zst) tar axvf "$1" ;; *.xz) xz -kd "$1" ;; *.bz2) bunzip2 "$1" ;; *.gz) gunzip "$1" ;; *.tar) tar xvf "$1" ;; *.tbz2) tar xvjf "$1" ;; *.tgz) tar xvzf "$1" ;; *.lzma) unlzma "$1" ;; *.rar) unrar x "$1" ;; *.zip) unzip "$1" ;; *.Z) uncompress "$1" ;; *.7z) 7z x "$1" ;; *.exe) cabextract "$1" ;; *.deb) ar x "$1" ;; *.jar) jar xf "$1" ;; *) echo "'$1' cannot be extracted via extract" ;; esac else echo "'$1' is not a valid file" fi }You don’t even need to specify the decompression algorithm anymore, I don’t even know if it was mandatory at some point but since I was introduced to Linux like 20 years ago
tarwould already extrapolate the decompression from the filename extension. Now for the compression I think you do need to include the algorithm, it would be nice if it would default to the extension on the supplied filename also.