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

  • juipeltje@lemmy.world
    2·
    5 hours 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.

  • Ephera@lemmy.mlEnglish
    3·
    10 hours ago

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

    • It offers two-letter shorthands for subcommands, so zypper install→ zypper in, update → up, remove → rm.
    • 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/

  • jonathan@piefed.socialEnglish
    30·
    23 hours ago

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

    • netvor@lemmy.worldOP
      4·
      21 hours 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 …”.

  • non_burglar@lemmy.world
    7·
    18 hours 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.

  • JakoJakoJako13@piefed.socialEnglish
    3·
    15 hours 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.

  • Obin@feddit.org
    18·
    22 hours 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
      5·
      21 hours 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.

      • Obin@feddit.org
        2·
        21 hours ago

        I’m a huge Emacs user and while I love some of the convenience features (editing the rebase-history, smerge-vc-next-conflict, etc.), but I rarely use magit, one of Emacs’ killer features, because I just still prefer the CLI over it. I usually know exactly what I want to do and menus, popups and hotkeys, no matter how good they are, just slow me down.

        • littleomid@feddit.orgEnglish
          2·
          20 hours ago

          How does pressing s to stage, cc to commit, pp to push slow you down in contrast to git add file, git commit -m etc?

          • Obin@feddit.org
            1·
            15 hours ago

            It comes down to my ADHD brain being unable to handle the context switches with windows popping in and out, staged diff views, unstaged diff views, and the mental model of which state everything is currently in. Whereas with the CLI I type out the whole operation in advance and get a nice history of the steps I have taken before, with magit I need to build up on the fly with interactive feedback I have react to, or at the very least can get distracted by. My “just slow me down” maybe sounded like “I am so fast, magit can’t keep up”, whereas I meant it more like “I can’t keep up with magit and constantly have to recheck things and correct mistakes”. For example my preferred workflow is relatively git (add|reset|checkout) -p heavy, where I can make sure the changes that get staged match exactly what I want, with undo/redo working as expected since it’s just a normal text buffer, whereas with magit I’ll go into the diff and press s/u on lines/regions with things just popping in and out of existence and I have to go over to the opposite diff and reparse that to fix a mistake I made.

            It’s very similar to other GUIs in that way for me. Or modal editing for example: I can’t for the life of me keep track of what mode the editor is in at any moment. With vim/evil I even had the muscle memory going at one point, but I would constantly type commands in insert mode and text into normal mode leading to all kinds of random things happening. I could be the fastest typist in the world and vim would still slow me down. However Emacs is perfect for designing a workflow to mitigate this, since it allows me to harmonize and simplify many of the keybindings to do similar things in all modes, customize window management (display-buffer-alist) to be less distracting and disable other distracting commands I don’t need entirely.

  • SayCyberOnceMore@feddit.ukEnglish
    2·
    14 hours 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.

  • CodenameDarlen@lemmy.world
    22·
    24 hours 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.

    • carmo55@lemmy.zip
      4·
      21 hours 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.

        • carmo55@lemmy.zip
          2·
          5 hours 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).

  • Bricked@feddit.org
    81·
    22 hours 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.

    • Liketearsinrain@lemmy.ml
      2·
      18 hours ago

      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

    • Archr@lemmy.world
      1·
      18 hours ago

      Anything to replace firewall-cmd? (I know about ufw but it just feels too simple for my use case).

      firewall-cmd commands are all fucked up and it feels like they use different verbs for very similar actions. Plus - - help is a few miles long which is not helpful. I just wish that it would have subcommands. Something like firewall-cmd zone public info

    • Black616Angel@discuss.tchncs.de
      1·
      19 hours ago

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

      • hobata@lemmy.ml
        3·
        17 hours ago
        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
}
        • Coriza@lemmy.world
          1·
          15 hours ago

          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 tar would 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.

  • harsh3466@lemmy.ml
    2·
    17 hours ago

    find and rename/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.

    • Coriza@lemmy.world
      7·
      15 hours ago

      I think find UI 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:

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

      2. The parenthesis to set order of matches, you are doing it in the shell so you have to escape them which is never fun.

      3. The fact that -name does 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.

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

      5. The fact that when you do some complex match then the -print is 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.