this post was submitted on 12 Feb 2026
773 points (97.4% liked)
linuxmemes
29983 readers
2258 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. 🇬🇧 Language/язык/Sprache
- This is primarily an English-speaking community. 🇬🇧🇦🇺🇺🇸
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Good GUI are hard to make while a good cli is rather easy.
Nothing wrong with a GUI that does what it needs without fluff.
The cli has one other benefit which I think is rarely recognised: it's pretty easy to tell someone you need to run "xyz -a -b -c" (bringing the safety risk with it to be fair), but it gets a lot harder to be like "so in the top left there is a cog button that opens a panel on the right where you're looking for the 2nd tab and there'll be a checkbox".
The things I appreciate even more than a good gui are programs with a good gui and a cli.
Good UX is the best, whether that's CLI or GUI. UX is under-appreciated.
It's also far easier to automate and use a CLI in a script - as long as it isn't a TUI.
A well documented CLI is easy to generate a GUI from.
Wait what?
I don't know about well documented, but if you use a standardized argument parser, you can even generate a gui from that.
https://github.com/chriskiehl/Gooey
Most screen recording programs are actually just ffmpeg in the back.
It is very easy to tell someone type this and shut up. I've never seen an explanation of why -a -b and -c are necessary or what they do. Although I recognise that a lot of people just want magic, and running "xyz -a -b -c" is the next best thing.
I would love to see what cli commands the gui uses, they would be much easier and faster to learn.
As the other comment says, use TLDR. it doesn't tell you everything, but it does usually explain the most common uses. If you need something more advanced than you need to do more research anyway.
While it is an improvement, it's aimed at people that already knows the commands.
For example:
What is that [.gz|.bz2|.xz] at the end? to someone that knows the tool it's too obvious to even think about, to anyone else, it's just there to mess with you because there's zero reference to it and some examples include it and others don't.
That's one of the things I like about yt-dlp-nis on android. You can select all the options you want through the UI and grab the resulting yt-dlp cli command.
man xyz | grep -E "^ *\-(a|b|c)"alternatively try tldr, which lists the most common options and explains them. It's a livesaver for noobs.
Edit: oh i see it was already recommended lol
More cryptic commands to the rescue! Lol
A decent number of modern TUIs do that, lazygit for example. I also find that tldr and navi do a great job of explaining those inscrutable options.
Grsync too
Also CLI are more accessible for blind people.
And dude has changed icon set, so its not a cog, its a wrench and screw driver
Tbh a lot of things are just easier to show/explain with images and icons in addition to text.
And in many cases mouse control is just super handy and fast
And while a terminal can show all these things… its just not comparable, IMO.
I wouldt want to write my job application in the terminal, or design a product, or whatever else requires just a smidge of graphics
I'm just a faster typer and when I have to go back to the mouse controls I feel sluggish. Of course, the right tool for the right job, I will never find myself with a tui to manipulate 3D objects or editing images but I will go to vim for editing documents using latex
LaTeX and Typst enter the job application chat
Yea that made me laugh; I just updated my resume from LaTeX to typst a few months ago actually
So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.
I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.
But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.
Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:
‘tool read_cfg’ reads from the device and prints the config to stout
‘tool write_cfg’ reads a config from stdin and sends to the device.
Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.
The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.
"I am the commander of the CLI! The CLI Commander!"