Name: cli
Description: Command-line interfaces, shells, terminals, TUIs
Category: tools
Similar tags: compilers, databases, vcs (ie classes of tools)
Recent stories that would qualify:
- In praise of Nushell (56) (programming)
- Useful Uses of cat (70) (linux)
- Ghostty Devlog 006 (46) (programming)
- s/bash/zsh/g (26) (devops, linux, unix)
- The Bun Shell (48) (javascript)
- Elvish scripting case studies (24) (programming)
- gitu: A TUI Git client inspired by Magit (35) (vcs)
- Ratatui 0.26 (27) (rust)
- I Just Wanted Emacs to Look Nice — Using 24-Bit Color in Terminals (52) (emacs, historical, unix)
- huh? A TUI form builder (67) (go)
- Has anyone found a robust way to test interactive CLI programs? (16) (ask, testing)
- Navigating around in your shell (45) (linux)
- fzf - The Command-Line Fuzzy Finder (26) (linux)
- fx – terminal JSON viewer (51) (go, release)
- mtm: Perhaps the smallest useful terminal multiplexer in the world (27) (c, unix)
And of course, a lot of the stories submitted by andyc (mostly but not limited to Oils): https://lobste.rs/~andyc/stories
Edge cases:
- nix-direnv is a huge quality of life improvement (34) (nix)
- Pipeline trick (42) (unix)
I think this much is clear:
- For many of us, CLIs are a big part of our everyday work experience and our preferred way to interact with computers
- CLIs are also a primary focus for the culture surrounding programming (most definitely for a big section of Lobsters users)
- Many (if not all) of the example posts above are missing a meaningful tag. huh? is tagged
gowhereas Ratatui is taggedrust, but the interesting thing about them is that they are TUI frameworks. - Likewise, Bun shell being tagged with
javascriptand a post about Nushell withprogrammingis not helpful - A post about cat is tagged
linux– makes no sense - Shells are the primary canvas for CLI culture, but they live in symbiosis with terminal emulators, command-line tools (both of ye olde unix variety and TUIs), multiplexers, dev environment tools etc.
Some might think command-line interfaces is too broad a category because that would include application-specific CLIs, but I’d say: that is going to be a very tiny minority of posts, and besides it would be welcome!
A lot of discussions about adding tags seem to revolve around people wanting to filter topics (at least they tend to be vocal), but I use tags for discovery, both by going through the tags page and when I’m just scanning posts. For example, if I saw “The Bun Shell” and it was tagged javascript and cli, I wouldn’t have to wonder about the meaning of “shell” and I would probably be less likely to miss the post.
Related proposals:
For the reasons above, I think cli is a better tag than shell:
- people who are interested in shells are interested in all the tooling above and below them
- we don’t need to nitpick what exactly belongs to a shell or not, and if there is a certain overlap with other tags (like rust), that is perfectly normal
YES: PowerShell, Oils, tmux, Bubble Tea, Elvish, pgcli, tmux
NO: Python, Perl, Homebrew, Docker
Do people really use the tag system this much?
Can only speak for myself, I have some tags filtered and also subscribe to the RSS feed for one tag I’m particularly interested in.
You have to choose a tag to post. Rather than having to choose the wrong or adjacent tag, a new tag can lets you be specific & relevant.
But users can suggest more relevant tags after the posting, so this isn’t a huge issue.
Everything a hypothetical cli tag would apply to is already covered by existing tags.
A minor caveat about the tag suggestion feature: it has the limitation that after any change to the story, such as removing cruft from the title of the story or adding one new tag, no one can suggest further changes. I have run into that limitation perhaps a dozen times. That makes incorrect tags slightly more of an issue.
Not precisely. Stories about useful command-line tools that run on Unix-likes (Linux, OpenBSD, macOS, etc.), and Windows can’t be tagged precisely right now. The combination of unix and windows would wrongly imply an article about those operating systems or how software runs differently on them. That combination may also cause users who filter out windows to unintentionally miss the story, though it isn’t Windows-specific.
In the list above, fzf - The Command-Line Fuzzy Finder (inaccurately tagged linux) is one such story.
Agree that further editing after the first being disabled is annoying and a bit of a bug, but one can always message a mod to address individual occurrences.
Regarding the fzf submission, I can’t see anything in the submission itself or in the comments that it’s available for Windows. So your hypothetical Unix-avoider would probably still be irritated that there’s a CLI application they cannot use, were the tag in place.
Regarding that specific submission, fzf is available for Windows. The example I gave was of a Windows-avoider, but here’s how a hypothetical Unix-avoider could learn that fzf would work on their Windows installation from the story’s linked article:
They could click the link in this part of the article:
Or, like I did, they might find the GitHub project by selecting an instance of “fzf” in the article and searching the web for the selected text.
They could scroll down and see the Installation > Windows section of the README. Or they could scroll up, click on Releases > 0.48.1 (Latest), and see files like “fzf-0.48.1-windows_amd64.zip” in the Assets section.
But I could believe that with some other article, a Lobsters user could be annoyed in the way you describe. The tag “cli” would not necessarily imply that the software works on all OSs, so if a story about a Unix-only program were tagged only “cli”, that might annoy a user who blocks the “unix” tag. This implies one of the following:
I would particularly seek out a
clitag as I’m always interested in these tools and bettering my productivity with them.Yeah, other people are talking about blocking tags, but occasionally I will browse a tag if I’m trying to learn about it. E.g., if you are learning a new language, it helps to filter to that language to get a feeling for the ecosystem.
Including TUIs in “cli” seems about as weird as including terminals in “shell”, to me.
Maybe
terminalwould be more correct. I wouldn’t mind!But then again, I’m not sure we need to read this as a strict taxonomy. I’m not trying to make the claim that “TUIs are a kind of CLI” or anything like that. Just that there are a broad collection of tools, technologies, practices and preferences that are centered on the command line.
IIRC, a major feature of the tagging system is its utility in blocking things that a reader doesn’t want to read about.
Make the case that people don’t want to read stuff about CLIs.
I’m not sure that case has been made for every single tag on Lobsters. Are there people who don’t want to read about
programming? Ordebugging? Or people who definitely never want to see a post aboutbrowsersoreducation? I suppose there might be some, but I’m sure I couldn’t make a solid case for it!Perhaps the people who don’t want to read about
cliare those same people who prefer never to hear aboutprogramming,unixoremail?(As I pointed out in the post: I personally use tags for discovery/scanning and don’t filter out anything.)
55 people are filtering
programming, 37 filterdebugging.https://lobste.rs/filters
Case made!
I only now read the guideline “make a case for why people would want to specifically filter [the tag] out” so will attempt a more serious answer: some people might be here for say the “interaction” topics (
a11y,designandvisualization) or perhaps with a focus onaiorformalmethods, and such a person might not be interested in fiddling a lot with the command line. Stated differently: some people with an orientation towards design or more academic topics might find CLI stuff irrelevant or boring.Sounds intuitive!
This makes sense to me.
Would
clibe better under “tooling” or “platforms”? It seems more like an alternative sibling to things like “browser”, “mobile”, or “web” than to “compilers”, “databases”, or “systemd”.That does make sense, but for me those things are more on the delivery side, whereas CLI tools etc are more on the production side (with some exceptions, as always).
As a submitter of one of the previously mentioned “shell” proposals, I like this.
I also think “cli” is clearer than “shell” and is closer to what I originally intended (though not what was in the original post). I think your strongest argument is that “Many (if not all) of the example posts above are missing a meaningful tag”. All of those posts would make sense with a “cli” tag, but not all of them would make sense with a “shell” tag.