60
submitted 1 week ago* (last edited 1 week ago) by netvor@lemmy.world to c/linux@lemmy.ml

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)..

top 50 comments
sorted by: hot top controversial new old
[-] Ephera@lemmy.ml 10 points 6 days ago

I always thought openSUSE's package manager zypper has quite a few neat ideas:

  • It offers two-letter shorthands for subcommands, so zypper installzypper in, updateup, removerm.
  • When it lists what packages it will install or remove, it will list them with the first letter highlighted in a different color, kind of like so: fish git texlive
    This makes it really easy to visually scan the package list, and since it's sorted alphabetically, it also makes it easier to find a particular package you might be looking for.
    And while there's separate lists for packages to be added vs. updated vs. removed, they also color those letters in green vs. yellow vs. red, so you can immediately see what's what.
  • When it lists items (other than packages), it prints an ID number, too.
    So, zypper repos gives you a list of your repositories, numberered 1, 2, 3 etc., and then if you want to remove a repo, you can run zypper removerepo 3.
  • When you run a zypper search, it prints the results in a nicely formatted table.

Documentation: https://doc.opensuse.org/documentation/tumbleweed/zypper/

[-] brianpeiris@lemmy.ca 4 points 5 days ago

I like the trend of refining existing tools. You take tried-and-true commands and shave off the rough edges and quirks. I use ripgrep instead of grep, fd instead of find, scm_breeze on top of git, dust instead of du, duf instead of df, z over cd, and xh instead of curl

[-] mactan@lemmy.ml 5 points 6 days ago
[-] Benchamoneh@lemmy.dbzer0.com 1 points 5 days ago

Favourite CLI I'd say is Junos. Structured, hierarchical, flexible.

[-] Cyber@feddit.uk 3 points 6 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.

[-] JakoJakoJako13@piefed.social 3 points 6 days ago

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.

[-] helix@feddit.org 4 points 6 days ago

Ncmpcpp

Gesundheit.

[-] juipeltje@lemmy.world 2 points 6 days ago

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.

[-] StrangeAstronomer@lemmy.ml 2 points 6 days ago

No-one mentioned 'jq' yet.

Maybe there's a reason for that!

[-] jonathan@piefed.social 37 points 1 week ago

Not what you asked, but anything that uses a single hyphen for longopts can just fuck off. I'm talking to you Terraform.

[-] JakoJakoJako13@piefed.social 2 points 6 days ago

You think that's bad. You should try Ghostty and it's +foo options.

[-] davel@lemmy.ml 7 points 1 week ago

I blame Sun/Java for popularizing this. I give find a pass due to its age.

[-] netvor@lemmy.world 4 points 1 week ago

Did not want to respond but this is hilarious.

To be fair, really old CLI's, like from the time when X.org was the new stuff, this style used to be more common. That was before "GNU style" (using single dash for single-letter bundle-able options and double dash for long options) became prevalent.

But yeah, if you see -foo then you know the program is old enough that regular colonoscopy is recommended, and the original author is probably retired or "passed away at the ripe age of ..".

[-] thingsiplay@lemmy.ml 4 points 1 week ago

I hate that too. 7z does that and its horrible.

[-] richieadler@lemmy.myserv.one 3 points 1 week ago

So does Fossil. I love the program, but that irks me to no end.

[-] CodenameDarlen@lemmy.world 23 points 1 week ago* (last edited 1 week ago)

I like CLI tools that everything I need can be found in a short command --help call, if I don't need to use man command it's even better.

I've used poor CLI tools for example adb you type this and you get almost a scientific article with more than 100 flags to use. No I don't want to need to use grep.

A good one would be pacman it separates clearly what it does instead of shoving it all in a single command.

[-] unwarlikeExtortion@lemmy.ml 2 points 6 days ago

This is where a man page comes in but alas, but some (perhaps even most) of them are fucking horrible. The core incantation is either too dumbed-down or (more often) too long-winded.

Some good ones I can praise are netcat, ghostscript and 7z. Special praise goes to the Library Funtions Manual entries like signal and exit.

Bad ones ones in my book are vim (too short), ffmpeg (a simple reordering of sections would make it quite a bit better, like moving the less common flags lower down the page) and git starts of strong but ends up being way too detailed and unstructured.

I could go listing examples for days, so I might as well stop now.

[-] carmo55@lemmy.zip 4 points 1 week ago

Pacman flags not being idempotent (-SS, yy, uu and such existing) is so unbelievably horrible that I can't use arch just because of it.

[-] jonathan@piefed.social 1 points 6 days ago

I've never used Arch, can you explain how it behaves?

[-] carmo55@lemmy.zip 3 points 6 days ago

The flag -y refreshes the package list (like apt update). For some reason, you use the flag -yy to force it to clear the whole package list and redownload everything.

To allow package downgrades when upgrading you use -uu.

These are very commonly suggested fixes to arch package management problems, for example when you leave your arch install to suit for too long, it will be impossible to update it because of dependency problems. So you google it and people are saying to run "pacman -SSyyuu" or other such commands.

Those additional options should be their own flags, command line flags should be idempotent (it should flip a switch on, doing it multiple times shouldn't change anything).

[-] jonathan@piefed.social 1 points 6 days ago

Okay yeah that's terrible

[-] Obin@feddit.org 20 points 1 week ago

I think git is 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.

[-] JayleneSlide@lemmy.world 6 points 1 week ago

But maybe I’m just using it so much I don’t recognize the sharp edges as much anymore.

Nah. I used to think that GUI git clients were The Way. But they all fall short, especially when the ***slightest ***thing goes sideways. Once you get your head around the paradigm, the git CLI is how you get real shit done and quickly. If anything, the GUI clients are all sharp edges and half-measures; the only reason I pull out a GUI client is to get a visual on all the branches in progress/already merged.

load more comments (3 replies)
load more comments (5 replies)
[-] Mordikan@kbin.earth 14 points 1 week ago

A well-designed CLI? Maybe sed. A badly designed CLI? Probably also sed.

[-] harsh3466@lemmy.ml 5 points 1 week ago

sed is great. I use it all the time, and I love it, but sometimes, I hate it.

[-] Cyber@feddit.uk 9 points 6 days ago

sed -i 's/༼ つ ◕_◕ ༽つ/¯\\\_(ツ)\_/¯/g'

[-] harsh3466@lemmy.ml 3 points 6 days ago

Hahahaha. Best comment.

[-] wewbull@feddit.uk 1 points 6 days ago

┬⁠─⁠─⁠┬⁠◡⁠ノ⁠(⁠°⁠ ⁠-⁠°⁠ノ⁠)

[-] bricked@feddit.org 9 points 1 week ago* (last edited 1 week ago)

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 -xzvf just 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 flags over short ones, because they are self-documenting.

load more comments (5 replies)
[-] non_burglar@lemmy.world 7 points 1 week ago

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 --help entries 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.

[-] HelloRoot@lemy.lol 5 points 1 week ago

uuuuh just bash with some simple bashrc and inputrc settings

[-] chrash0@lemmy.world 4 points 1 week ago

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 cd for me since it does everything cd does but also keeps a small db of your most commonly visited directories so you can just do z Downloads or z my_project or whatever from any directory

[-] hades@feddit.uk 3 points 1 week ago

Wanted to mention jj too. It follows a fairly standard pattern of ‘ ’, e.g. ‘jj bookmark create’, allows to abbreviate unambiguous commands (e.g. ‘jj b c’), has a lot of QoL features (such as highlighting unique prefixes of change IDs in the output). Really a lot of thought went into CLI design specifically it seems.

[-] slazer2au@lemmy.world 4 points 1 week ago
[-] hades@feddit.uk 4 points 1 week ago* (last edited 1 week ago)

I think it depends a lot on what kind of application you’re thinking of. Here are some examples of tools that I particularly remember for having nice CLI interfaces, but they are all slightly different in terms of the number of operations/entities they support.

Single operation, a lot of different types of data: httpie

httpie is a CLI HTTP client. It allows to generate fairly complex requests, choose which diagnostic information you want to see, etc.

Examples:

$ https httpie.io/hello
$ http PUT pie.dev/put X-API-Token:123 name=John
$ http -v pie.dev/get

Several operations, a lot of parameters: Bazel

Bazel is a build system. There are only a handful of operations you typically perform (build, run, test, query), but they all follow the same pattern.

Examples:

$ bazel build //app
$ bazel --quiet build //app -c opt
$ bazel --quiet run //app -c opt -- --port=1234

Multiple entites, multiple operations: LVM

I really liked the interface of Linux Volume Manager tools. They consist of multiple commands that follow the same pattern, and use the same flags for options.

Examples:

# vgcreate -n vg_name
# vgs
# pvcreate /dev/sda
# vgextend vg_name /dev/sda
# lvcreate vg_name -n lv_name -L5G
# lvresize vg_name/lv_name -L+1G
# lvs
[-] bodaciousFern@lemmy.dbzer0.com 1 points 6 days ago* (last edited 6 days ago)

LVM is in your favorites? It's essential command(s) for sure but every time I use it it's trial and error because I didn't use the correct flag case and/or argument order

[-] digdilem@lemmy.ml 3 points 1 week ago

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.

load more comments
view more: next ›
this post was submitted on 26 Mar 2026
60 points (96.9% liked)

Linux

63789 readers
1091 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS