As someone who teaches these things occasionally to non-tech people I think the hard thing about CLI tools are the following:
1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that)
2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc.
3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy.
But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.
The biggest issue I’ve see , particularly regarding your first point, is simple discoverability of capabilities.
It is very difficult, at least initially, to even begin to discover what’s possible in a terminal environment.
There are so many important things that a new user simply needs to be taught, or they will likely never discover basic functionality - such as how to even open, read, and navigate the manual.
The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity.
GUI applications (generally) solve the initial discoverability barrier by simply showing you what’s possible.
I remember being a kid looking at DOS and wondering “what do I even do?” It was essentially a blank screen with very little indication of how to proceed. My dad had sticky notes on the monitor with the commands to enter to run games.
I never really looked at a command line again after I started using the Windows desktop until I started really learning programming after college, and it was just as daunting at first.
While I understand (and agree) with your point about a GUI "showing you what's possible", I would like to add some nuance:
1. People have to learn the basics of the GUI. Take someone who lived 50 years without seeing a computer and show them Windows. They will have to learn that they can move the mouse, left/right click, and even move while clicking. They will have to learn that some parts of the UI are interactive (e.g. buttons) and others aren't. It is not as intuitive as people tend to imply. My father still double-clicks on elements that - to me - obviously don't require a double click (like a hyperlink). And many people are completely lost if you move them from their Windows to macOS or some Linux UI. Or even between two flavours of Android.
2. Once you know the basic of GUI ("there is a start menu", "I can click on buttons", ...), the UI does not show you that there exists apps like Photoshop to edit pictures, or like Slack to talk to people. You have to somehow learn about the app from somewhere, install it, and only then you get their UI that "shows you what's possible".
I would argue that the CLI is actually quite similar. Once you have learned the basics ("I can change directory", "I can `man cmd`"), then you have to discover apps somehow (e.g. a friend saying "install git with `apt install git`"), and then you can just open the manual with `man git`, and it will most definitely show you what's possible.
The difference, I think, is that people generally don't really want to learn the CLI (it "looks old", I guess?), and many apps don't provide proper manpages (pretty sure most developers don't know how to even create manpages, or package their app for their distro).
You missed the big difference between the GUI and CLI. Even if the GUI is completely unfamiliar, and you have to learn it, you can still see the different buttons, menus etc. They often have icons or text that hint at what they do, even if you don't know exactly what they mean.
With a CLI you have absolutely nothing. There is nothing to see at all, nothing to even begin to interact with to discover the capabilities.
> Even if the GUI is completely unfamiliar, and you have to learn it, you can still see the different buttons, menus etc.
Unless the GUI uses some material style nonsense. Then you have to guess where buttons are. Menus are so uncool. Every modern emacs distro starts with disabling them. Mobile apps have replaced the menubar with the hamburger button by necessity. Modern desktop GUIs have copied that despite it clearly being worse on a desktop than a menubar.
I kindly disagree :-): I would say that with the CLI you have the exact equivalent: man pages.
Just like for a GUI you have to know that by hovering the cursor about an icon you will get some text description, with a CLI you have to know that there are man pages. And just like a bad GUI may have cryptic icons without any description text, a bad CLI will have no manpage. But we should compare a good GUI to a good CLI, to be fair.
I agree. In the CLI I have a blinking cursor. If I press keys I see characters. If I press enter I get a response[0]. I do need a further invocation to get help, but that's easy enough.
[0] admittedly a holdover from the typewriter, but even presented only a keyboard and a screen I've had a kid realize that one special key makes the words go vertically instead of horizontally.
There is no reason why a better shell couldn't show tool tips over command names or flags, assuming there is support for it in a terminal emulator. Even without support from the tooltip it would be possible to show some info about the thing below the text or mouse cursor in a designated area of the cli.
Hi, I've never used a computer before and my first time will be a CLI. What is a man page? How would I discover what it is without first knowing it exists?
I believe this is a wrong assumption. People have to learn the basics even to use a GUI. Because they grow up with GUIs does not mean they have not learned they way around them.
I disagree that GUIs show what is possible. I am often baffled by my iPhone as to how to get it to do something. Even Apple's own apps are wildly inconsistent.
Once you learn "man" and "man -k" the cli environment is emminently explorable, and it's not just "try poking at it and see what it does" it's all laid out in written documents that you can read in advance.
> I remember being a kid looking at DOS and wondering “what do I even do?”
The DOS we had came with a few-hundred page manual. The same for any major programs that ran on it. These must have been exhaustive, as I don't remember being stuck at any point, honestly.
Jup. But where in the terminal does it tell you that (A) there are man pages and (B) how to look at them?
The answer is: It doesn't tell you anything. So either you grew up in a time where computers with terminals were new and interesting enough for you to try, or you were a teenager that was bored enough to try, or you had somebody show/tell you.
> The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity.
I dunno if it is all as high as it appears. I learned to navigate and use Unix type systems in the mid 90s, with only terminal access.
Internet was practically non existent and gopher was still (barely) in active use.
So, yeah, for a start, I don't know if extensive online resources are necessary. For example, I learned most of bash from the bash manages.
Imagine if people had to discover algebra instead of learning it. We'd probably still be subject to the whims of kings and priests.
(to what extent have we made progress in software by standing on each others' shoulders instead of each others' toes, and to what extent have we been fortunate that the EEs have been standing on each others' shoulders this short century?)
Note that I'm not anti-discoverability in general — it's just the ticket for GUIs. I just happen to believe that attempting to make CLIs discoverable would nerf their greatest power: that single-character changes can have drastic effects on behaviour. We have high display bandwidths, even in our pockets, so why not have GUIs for infrequently used software and CLIs for power used software?
(1) is an important point, but I think it doesn't go far enough. The terminal offers no help at all to a casual user (the funniest case of this is watching a new user trying to quit vim [0]).
There are a specific set of skills required to learn how to use the terminal - a combination of knowing when and how to read man pages, when to look up Stack Overflow, when to look up YouTube videos, and where to hang out to learn about more esoteric commands exist like `parallel`.
Without those skills - and there is no recommended path on how to get them - the terminal is unusable. It isn't a case of people thinking it is hard, it is actually logically impossible to learn how to learn terminal commands without getting lucky at the start.
Software has two phases - a learning phase and a using phase. A lot of great software ideas died quietly because there wasn't a sanctioned route to scale the learning curve.
> The terminal offers no help at all to a casual user (the funniest case of this is watching a new user trying to quit vim [0]).
I think that's because casual users did not learn how to look at a terminal. If you start `vim`, it shows you a few lines that say "type :help for help". The help starts with "how to move around" and "how to quit". But people ignore that.
One could say "people don't ignore it, it's just not intuitive". But I have seen many casual users struggle with GUIs, too. The difference, IMO, is just that they learned the basics of GUIs, and never had to learn the basics of CLI. I don't really believe in something fundamentally harder with CLIs.
To add on to (1), expeeienced hackers trying to educate new users really should first immerse themselves into descriptions of the "bad old days" of utility programming to help get back into the mindset of the novice they're trying to relate to. Your ed link is good, and I like the "Power Tools for Power Fools"/"Teeminal Insanity" chapter of The Unix-Haters Handbook for something slightly more modern: https://simson.net/ref/ugh.pdf#page=185
Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page:
>Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes.
>This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.”
In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all.
The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it.
Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.
> 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc.
One of the interesting things Plan 9 did differently is that its terminal is rather more like a standard graphical text editor that happens to have the ability to execute a line. As someone used to unix terminals this was super jarring, but I can see where it would be nice.
The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options. With more than a dozen options, you start having special cases like "it does foo when the bar option is used, baz otherwise". In a GUI, you generally express exclusivity or inclusivity with the use of the correct UI elements – a checkbox can become disabled when something else is selected.
With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super useful for e.g. ffmpeg, cc, curl, etc. Especially for people unfamiliar with the program....
Early on (late 90s and early 00s) there were a lot of command line to gui kinds of tools (there were also a lot of tries at web-ifying, CLI tools also). I can't remember the name, but there was even a terminal emulator that tried to present commands as dialogs.
* There is no enforced standard for commands other than using a file name to invoke them.
* Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse.
* The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui.
* It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc...
That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
The idea is that you'd build it into whatever command-line parsing tool you use. Presumably this would be runtime-specific. And yes, the entire point is to escape the terminal and rely on native interface constraints (e.g. disabling/enabling) to reflect the usage of the tool.
Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).
It doesn't even need to be a full GUI, just having an interactive interface for weaving commandline-spells on the fly would already improve the access. But then again, this would demand a more complex interface than a commandline. I'm not sure how easy this is implementable with your average shell&terminal.
a good shell completion function is like 80% of the way there, it can even include descriptions for flags, and the smart ones will know about exclusions and such
> The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options.
Which is actually also a problem with GUIs. Many times, with a few CLI commands you can do a ton of stuff that you just cannot represent in UI without having tons of buttons...
I know people write these kinds of programs and I write these kinds of programs, but the obvious solution to this predicament is that we should have more, simpler tools so that instead of a combinatorial mess of options, you get a collection of composable tools.
That would be an interesting interaction to explore with a colourised terminal. Essential have contextual colouring on input so that mutually exclusive params are either shaded in the case of clear precedence or highlighted for conflict. It's not an area I've played with but wonder if that could be hacked into exisiting autocomplete mechanisms?
I was hinting/hoping at something beyond what fish does.
Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.
So do you think a terminal that works more along the way of thinking of non-technical people, or maybe similar to other text-based applications, could provide an entry point to non-technical power users?
I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.
VSCode's command palette is a great example of this-
1. fuzzy search through different options
2. Show lots of suggestions as soon as you focus in the text box
3. have a ? or other "learn more" option available
I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
I think using text to interface with computers is a genius idea and if it didn't exist someone would have ro invent it. But the way text interfaces on computers look nowadays are mostly shaped the way they are for historical reasons.
It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc.
I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else.
Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool.
Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead.
I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.
1. You teach so your experience is probably very different from us SWE/SREs who only work with other technical staff for the most part.
2. You can add cursor and mouse control to your .nanorc. I'm not sure if bash, etc have that. With that said, I have cursor enabled in my .nanorc along with a bunch of other stuff. The cursor thing.. I'm kind of confused on how you use it, but I rarely use it. It's (to me) weird. I think I just havent used it enough to really know its capabilites.
I think as a teacher it'd be super helpful to you to have a base set of dotfiles that your students just git clone when they start the class. Or even better, have them write their own and just provide them the settings you want them to enable. When I bring new SREs on board, without the base dotfiles for them to grab on day 1 it takes practically a week for someone to get setup and ready to work.
Have each of them commit their dotfiles to their own repos, probably forked from yours. That will get them familiar with github. Then try to get them to actually build out a github portfolio. I spent 6 months interviewing for a few positions last year and I was really surprised how few people had githubs with anything on them. It's not my main criteria but it's nice when someone has put effort into their gh/gitlab/etc profile and projects.
Also please teach them about filesystems. Most of the younger people (20s) I interviewed knew very little linux/containerization/filesystems.. I think the filesystem thing is from them growing up with MacOS and iPhones. They don't need to dig into anything beyond their "folders" if even that.
3. Absolutely one of my CLI annoyances here. I wrote another comment explaining why it frustrates me.
Related to your last sentence- I'd say 99% of the CLI/TUI apps I write are things that give you an easy front end (TUI and simple commands/flags) to perform backend systems tasks. So I have a ton of them as an SRE. The main reason I like to put things in a TUI and not just CLI flags is that ANYONE can hop in and use it because the options are all displayed to you front and center. You just use arrows or numbers to navigate.
I do TUI *AND* command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps.
This lets me democratize the various apps I've created and let anyone who isn't me use them. It's great.
Here's one example of my TUI+CLI apps. This is super old it's much prettier now.
> I do TUI AND command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps.
YES, this is the way to go! I've written a couple of internal tools that work this way and it's the best of both worlds IMO.
I’ve worked with helping beginner students set up their environments a bit. I’m skeptical of the idea of providing too much in the way of custom dotfiles or anything like that. Students will come with their own systems. Mac, or Windows, usually. So a professor or grad student who naturally uses Linux and isn’t really a software deployment expert might have trouble getting a rock-solid portable collection of scripts. It might seem like an odd difficulty for smart and technical people to have, but administrating other people’s systems is a totally different skill from research after all!
More importantly, in a class of a couple hundred, somebody will find a way to get off the happy path. No matter how well you design it. Hopefully they’ll come to a teaching assistant or something, but there’s a good chance they’ll go to YouTube or something instead. In that case, it is best if their installation is as standard as possible.
Also the filesystem problem is such a thing and you have dredged up some feelings, hahaha. In particular, I think operating systems and VSCode have gotten way too good at hiding the fact that the file somebody is editing is, in fact, still in a zip archive. Until they go to save it or run it.
It'd be fun (and a bit scary) to use an LLM as a shell replacement. We'd give it the history of our commands as per the recent post [0], as well as their outputs, and it would turn natural-language commands into proper bash. The xkcd comic [1] would be solved instantly. "Tar these files, please." "Delete all the temporary files but please please please don't delete anything else." I'm sure people have implemented this, but my searching isn't good enough to find it.
I have briefly told ChatGPT 3.5 about the syntax of a CLI tool I wrote, then asked it to perform a few operations. It did a surprisingly good job, even when I said "and format the result as JSON with fields named Command and Description where the latter explains what the command does".
If I was to actually use this in a real system, I'd definitely build a restricted shell to execute in, and probably run it inside a Docker container with just the essential files mapped in, because I don't trust an LLM not to describe what it's doing as "updating timestamps" or whatever but actually the command is "rm -rf ~"
I love CLIs, i try to find inspiration in the one simon willison makes. His CLIs extremely good on the DX side.
Llm, sqlite-utils and datasette are all very thoughfully thought of tools/clis.
So good that I have been thinking to mail him to see if he wanted to write a blog post about his way of thinking about it. Its top notch from naming the subcommands the plugin systems.
I always try to think along the lines of: I've i'm going to use this CLI a 1000 times each day. How do i want to use it. And if i want to automate it, how can i script it.
Also CLI commands are basically contracts, since people will program against it.
Good CLIs are very interesting puzzles bringing human ux and scriptability together. Aws cli's also have an interesting approach to it.
>Discoverability: Reminding ourselves how to perform what we know (or assume) can be done isn’t the same as guiding us towards the full gamut of what’s possible.
I started with text mode CLIs on old 40-column computers like IBM PC DOS and Commodore 64 so I fully understand the techie's bias towards TUI command lines over GUIs. Lightweight, embed commands in scripts, command history, etc.
However, the tension between CLI power vs GUI ease-of-use really hit me when I'm the user of personal utilities I wrote. Coding a console utility that uses command line arguments is always faster and easier than a GUI app. So, being lazy, 99% of my utilities are CLI.
But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc.
That said, I still like CLI tools. E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. I really don't want to click around the bank's website or use a smartphone app.
It's funny, I started in the C64 era and have probably used a CLI for something roughly every day since then. But for me, using a CLI is still just a necessary evil - give me a GUI (or TUI) instead and I'll always take it.
The reason is that my memory sucks, and has always sucked. If I'm not typing a command every day, I'll forget it very quickly. If I am typing a command every day it's probably an alias or a script I've written to save myself some time so the "real" command is already forgotten. So in reality if it's not cd, ls, less, sudo or grep the chances are that I've forgotten it.
Where the CLI really shines is automation. Software I can control with a CLI in a script is amazing. So what I really want is for everything to have both a GUI and a CLI. I realise I'm asking a lot.
- spaced repetition for stuff that you use sporadically. I use Anki, it's great. For how to use it, this article is great: https://borretti.me/article/effective-spaced-repetition. I've found a positive feedback loop where the more I know how to do things without looking anything up, the more I use the CLI, the easier I remember things, the more things I discover, etc. I read once that when learning a new language, you should aim for content where you know 80%/90% already. It seems to be true for learning the CLI, and especially for integrating that learning into my day to day job.
- sd (https://github.com/ianthehenry/sd) for lowering the cost of creating a "documented alias". Before that I made aliases with either alias, or bash functions, all starting with "," to quickly see all which are "mine" (I read that trick in an article that I can't find), now the more complex stuff is in sd with some documentation.
w.r.t. forgetting CLI commands- I'd consider increasing the size of your shell history and setting up a way to fuzzy search through that history. I've been using FZF for this but am considering moving to atuin
It's great to be able to find the weird JQ filters or kubectl patch commands I ran last year when I need them
> But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc.
A better question is why OP isn't using a library that will do it for them!
Python's argparse is pretty good in this respect. Even if you don't supply help text and good metavar names, it'll at least give you --help output showing which options are supported, and adding help text and helpful metavar names is not much additional effort.
argparse has inspired a number of knockoffs in other languages, and the ones I've used are pretty good at --help output too. (Or you can write your own! If you've done this not only long enough to not only forget the syntax of command line tools you've written, but also often enough to have recognised this as a repeated trend, the effort involved could be worth it.)
It takes like 2 seconds in almost any language to do it too, just do it when you start your code, youll thank yourself later.
I even have a sort of template for shell scripts, if any arg will be on the commandline, it gets implemented.
For python (using argparse obviously), in my current project i built a toml file that handles the args. It allowed me to do more, like generating code blocks for js for the web frontend, documentation for both the cli and remote api, etc. Actually, now that I think about it, i might chunk that out to its own library.
> E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions.
Really, it'd be nice if they offered any upgrade from the 80s beyond a smartphone app. How does the rest of the world have better peer-to-peer payments than we do? How can I still not fully deny all transactions to a bank account? Why can't this banking app ask my permission before letting charges go through? Why is over-drafting a debit card possible at all? Why can I not ensure that a PIN is necessary to use my debit card in all situations and not just at a physical point-of-sale or ATM? Why do they all use SMS for 2FA—which has already bitten my twice?
I hate that Venmo and cashapp basically leech off the incompetence of our banking industry. Banking is a joke of an industry in dire need of regulation.
> But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is.
I try to avoid this in two ways:
1. I use the history in my terminal to search for previous invocations of the command, which tends to give me a good set of examples of how it should be used.
2. For anything but the quickest and dirtiest CLI tools, I like to use a declarative parameter parser like docopt or argparse. This forces me to spend a couple extra minutes writing some docs and makes the --help useful.
If there's a combination of options that I use for a command and catch myself forgetting it, I either make a script or an alias that I name appropriately.
All the scripts are in the same folder, so I can look through them if I forget which one. Same goes for aliases by using:
The consistency rule I follow in any CLI tools I write: options are optional, required are commands or arguments.
Anything with `-` or `--` is an optional. Just like all the basic unix/linux tools. You don't have to `ls --thing` to list a folder, just `ls`. Or `cat --magic --args the_file` and so on.
If I require an 'option', it becomes a command or an argument for the command, i.e. `tool --list-files` becomes `tool ls`. Copy for example: `cp src dest` works, `cp` on its own, doesn't.
I even tend to write extensible CLI tools, `tool-ls` will drop into the same folder as `tool` and running `tool` will detect `tool-ls` and present it in the list of commands. Just like git.
This only works with CLI that take a few arguments. If you're writing a CLI that requires 5+ arguments, then positional arguments are very hard to remember the order of. -- arguments make that easier.
The name option is misunderstood. You have options. Sometimes you just have to pick one.
Try going to the ice cream shop and ask for an ice cream but refuse to give them the size, flavour or the type of dip. Tell them it's optional and you shouldn't need to provide this information on order to get ice cream.
Chances are you're suddenly getting a new set of options. A. Kicked out. B. No ice cream. C. Gigantic truck size vanilla icecream with garlic dip and tuna flavour. That'll be $79.99.
You have options but sometimes you have to pick a few.
If you argue for positional arguments, try ordering ice cream: large chocolate strawberry.
One of my huge frustrations is the inconsistency between various apps or even in the same app.
Sometimes it's "executable -help" or "executable --help", sometimes it's executable -h, or --h.
I also find it really annoying when running a bad/wrong/typoed command doesn't give you a "You wrote fkuc but did you mean ...." those are super helpful.
IMO, if you use --help, you also should be using -help, and -h --h, unless you're using C and c to seperate two different commands. Which I don't like AT ALL. Don't make --help show help but --HELP show something different. Use a different word/letter.
I write TUI apps ALL the time and it's not hard to do ANY of this. It's super easy in go and ruby. There are two big things I do - I add CLI flags that you can run directly - "executable --help" which does the same thing as opening the TUI app with a nice little TUI menu where anyone can use it and select their options and put a couple of inputs in to get what they want done. So, if you DON'T want the potentially slighty slower of uising the TUI vs a CLI command with a few flags you can just run the commands directly.
Hell, if someone puts the wrong CLI --flag in instead of letting it just bomb with a *nix error have it echo the actual command flags. Don't make me have to dig around for commands.
And don't send me to your manpage with --help. God I hate that. Manpages sometimes are absolutely awful. I want ONE command flag that you made some esoteric word for, I want a nice concise list of the flags. I do NOT want a 5 page manpage written so dry and cumbersome that it's such a pain to read that we have other cheatsheet apps.. I ONLY want the manpage if I ask for the manpage.
> IMO, if you use --help, you also should be using -help, and -h --h
I tend to go by the paradigm of single dash for single character options, and double dash for full words (and common things like —-help should have aliases like -h).
That's interesting. Did you come up with that yourself or is that a common standard?
I've always wondered why the style of command flags wasn't "more" standardized after 32 years of Linux being around (not that thats the first time flags were introduced, just an easy stop so I don't have to dig into that since it's not super relevant).
So, maybe it is somewhat/completely standardized and I'm just not aware of where that information is?
I think your style would still frustrate me. I'd first type "executable -help" thinking that was probably the - and -- option, and get a command not found error. I wouldn't think that think we're using - and -- differently.
That used to be a fairly common standard. You'll notice nearly all the old GNU / BSD tooling use this paradigm. It is even codified in GNU's coding principles. In fact, when you do that, you can even merge all the single character flags together. For example, I can type, `ls -lah` instead of `ls -l -a -h`. Pretty handy.
My pet peeve is commands not supporting -h for help and making me write --help. This is especially worse when the command already supports single character arguments.
I've never even thought about this. I think this is kind of strange
> An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, -o foo and -ofoo are equivalent.
Thanks this is super helpful I never knew this was a GNU thing.
That only holds when 'o' and 'f' are both boolean "flags" taking no arguments. If 'f' is more like --file=x then it takes an argument.
More specifically, getopt(3) in POSIX lets programmers very this by giving a format string. "o:f" would make your example parse as "-o" "foo" while "of:" would make it parse as "-o" "-f" "oo" and an "of" format would make it parse as you describe, "-o" "-f" "-o" "-o".
Also, while --long-option is GNU, gcc which is perhaps the aboriginal GNU command-line utility uses single dash as in, e.g. `gcc -pipe`, though it also accepts `gcc --help`. CL syntax remains quite varied in the wild.
Definitely not my idea, but is encouraged by built-in tools like python's argparse [0] or node's util.parseArgs [1] which definitely guide you toward's this "short"/"long" style.
This is funny on multiple levels. For one, it is IRC that introduced these commands decades ago, as others have observed. The second is that the Discord "UX", especially for Midwinter, is atrocious. You couldn't pay me to use it.
I think pr337h4m is pointing out that Discord commands can return much more than text. Unlike in a terminal, the result of a command can be rich text, images, videos, and syntax highlighted code.
I'd like to make a correction. I meant to say Midjourney. Midwinter was an interesting game set in a snow-covered post-apocalyptic world induced by a meteorite strike in 2040.
Huh? The UX is pretty much the same as in the terminal; "Here is a command, a small snippet of help text and a bunch of options, figure it out", not sure what Discord improved upon here. Autocomplete?
> Ultimately we would like to formalize this schema and a protocol to extract or expose it from apps. This which would allow Trogon to build TUIs for any CLI app, regardless of how it was built. If you are familiar with Swagger, think Swagger for CLIs.
It's mostly just a README right now, and I'm still iterating on it, talking to friends, but I think I'm getting close. It's definitely not yet written for the average developer to consume yet either. My hope is within the next month or two I might have a usable alpha release of it. I have a use-case for it now so I think it’s finally ready to happen.
Ive sort of managed to implement something to this effect in python, and from another comment made me consider yanking it out to its own library.
I made a process where args are now in a toml file, with some various data for different operations, like whether its available in the CLI or API library, its arg flags, help text required value type, etc. From that, i can generate argparse args, documentation, code for other things, etc. Right now im generating args, docs, and a js code block from the same structure.
You probably already know, but just in case you don't, you might read about http://docopt.org/ It seems to me a lot of your usage ideas could be refinements of / tooling around docopt-style interfaces.
Yeah I investigated. I don’t think it works well that direction. It is appealing and you can see some elements of it in my current design, though that’s a particular part I’m still unsure of.
It gets way too complicated real quick and a lot of things you _dont_ want to expose in documentation. It’s better to generate docs from a spec than the other way around, I’m pretty sure of this now.
There is also generating the whole thing from a function signature (e.g. https://github.com/c-blake/cligen ) since then CLauthors need not learn a new spec language, but then CLauthors must add back in helpful usage metadata/semantics and still need to learn a library API (but I like how those latter two things can be "gradual"). It's a hard space in which to find perfection, but I wish you luck in your attempt!
My goal is that one day framework authors will adopt this (they might do it quickly since it’s a hell of a lot easier to dump a usage spec and generate completions than it is figuring out how to write completions for each shell).
At that point it would make sense for them to also make scaffolding generators, meaning the cli author only has to write one spec and don’t have to repeat the effort for their code so much.
I think there are 2 ways usage will be used, either as an under the hood format used by frameworks to make frameworks better, or directly by users to scaffold framework code
Ah sweet, I have been wanting to do pretty much the same thing, have found one or two bits of prior art but nothing that has caught on. Very interested.
Powershell cmdlets make the CLI really nice to use; you declare the variables in your program parameters and then hitting tab will auto-suggest/auto-complete them for you, and you can generate help docs for each cmdlet as well
Most projects design CLIs wrong, CLIs should be interactive by default to maximize discovery, everything from the command selection, to option selection, to specific parameter enum or even searchable resource ids. A -y flag should force it to be non-interactive. This is what I did with seam-cli and the usage of command line tools over eg postman for interacting with our API exploded- a good interactive CLI is all you need. It helps to use a well-defined schema, or for an API company an OpenAPI schema, to keep the CLI up to date and to maximize it’s capabilities.
“Most” would be an awful experience. You wouldn’t be able to pipe anything in a terminal or write a script without polluting everything with a bunch of `-y` all over the place.
An annoying thing is if CLI tools don't exit with non-zero if the tool is used incorrectly.
It's pretty standard to print the usage string if the tool is invoked with invalid arguments. However the program should then also exit with non-zero, otherwise it can be inconvenient to use in scripting.
As all computer interfaces evolved in the past decades (from text to graphical interfaces, to touch screens and voice commands), the users' expectations have changed and the CLIs need to evolve as well. Today's users don't have time or willingness to learn something before they can use it. The number of tools in daily has grown as well, so they really don't have the mental capacity for that.
We will always need CLIs for things that are to cumbersome or rare to add into GUIs; but they have to become easier to use, and provide immediate value.
That's why we built an interactive CLI by default at Diversion. It's not a revolutionary tool (there are other similar CLIs), but it has shown to help our users get started with Diversion much faster - the feedbacks are overwhelmingly positive.
From my experience, interactive CLIs are the worst of both worlds.
They are not as pretty and intuitive as GUIs, since the user has to learn terminal idiosyncrasies (e.g. unable to ctrl+c, or edit text in the middle of the sentence by mouse).
And, at the same time, they tend to be pretty bad for automating things (in the worst case, even unsuitable for automation) since now, you have to map the interactive commands to the non-interactive ones.
It depends on tool. If this is some generic utiliy that interacts streams, it most probably should not be interactive. But for example if this tool is some kind of control shell for subprocess (like Quagga vtysh or FW control CLI) it would be much easier to use in interactive fashion (autocompletion, interactive help and hints system).
You're right in that an interactive CLI's interface is not trivial to nail. We're spending a lot of dev time on that actually.
And of course there always also has to be a non-interactive version for automations.
I think your linear evolution theory might be a bit too simplistic. There must be a branch somewhere (says the CS nerd). Where does AR & VR go? Before or after touch screens?
seems like wrong case study, cli power (at least for me) is in comments and record keeping what has been done months if not years ago, and an "easy way" to script repetitive tasks, I just don't see how same thing can be achieved with GUI:
record video and then comment it ?
have detailed logs what button, and what fields where edits/pressed ?
Maybe I'm getting old and nostalgic, but in my times I really enjoyed reading Linux howtos. That's how you discovered stuff. Then man pages for the more uncommon options. Everything was preinstalled you just had to spend some time reading it.
I'm not sure I like this modern idea where everything has to come to you without any effort.
I think it all comes down to the instant gratification offered by modern world that has reduced people’s attention spans. Almost like if something takes longer than a few minutes for people to get started, that move on. Don’t blame them when there are so many alternatives to choose from. Doesn’t matter if you offer a better long term solution if your users don’t even stick around long enough to experience that.
The "subcommand" approach is the one popularised by Git. It makes sense for complex tools that incorporate many different actions. Every action is essentially its own CLI tool. That approach isn't suited well to the traditional Unix mindset where a single tool is supposed to do one thing and do it well – "ls" is meant to list files and "tr" is meant to replace characters, and you should be able to pipe them together.
Not to challenge anything you said, but rather expand upon it.. git just followed a grand tradition of software version control systems in general (sccs/cvs/svn/..): https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k
This is why I believe that more CLI applications need to be built using a solid TUI alongside a CLI. This will enhance discoverability - imagine embedding a help screen inside a TUI when invoking `somecommand --help` or just simply `somecommand --tui`.
We need more TUI. Before there were GUI OSes, almost every application had a TUI of some sort (think back to DOS, etc.).
As someone that spends 99.99% of their working day in the terminal with CLI's, here are the things I want -
- clear documentation, eg --help
- order of parameters should not matter
- clear, helpful error messages (git is great at this)
- consistent outputs
That's all I want. It can be as complicated as you want it to be, as long as you do this stuff I don't really care. One tool that comes to mind I use a lot that does not do this well is jq. It's very unintuitive, at least to me.
I think it's very user friendly. As a user I can easily access functionality when the application's modules are organized as a little taxonomy of commands. Hierarchy is good.
> Among other things it makes the shell’s ! commands harder to use.
I write a lot of tui/cli apps and I've never even considered doing sub commands. I always do --my-action-1 and --my-action-2.
I can't think of any huge positives from using subcommands. I know for a fact that that will take longer to write and add some complexity to --args-* and I also feel like getting a quick --help option would be a lot more cumbersome.
Maybe a good way there is to list commands then tabbed/dashed indented under the root command list its subcommands.
I like that sub-commands usually have a different --help output
git --help
git add --help
The former returns general information about the whole git executable, while the latter returns specific details about the add command.
It also gives an immediate intuition of entering a whole different flow that can not be composed with other flows, something that you don't have with --args
There is a hierarchy between commands and options that is not expressed when both use the -- syntax
There are a lot of super useful "!" commands documented in the bash manual in the section entitled 'History Expansion'
!! which you know runs the previous command in your history. It's just short for !-1
!123 runs the 123th command in your history
!gi runs the most recent command in your history that begins with letters g and i
!* is the args to the most recent command
!$ is the last argument to the most recent command
!:0 is argv[0] of the most recent command (i.e. the program name)
These can be combined:
!g:$ is the last argument to the most recent command that began with g
They are also really handy in backquotes since you can do things like grep foo `!find | egrep .cc` because your find command was almost right
Sometimes you can get away with a ^ substitution:
git add foo.cc bar.cc
oops
^add^reset
There are a lot of such commands that let you use the basename of the argument etc. After a short while they are so automatic they are easier to type than the actual command name ("I just want to do that thing again but with this filename"). These have actually become so deeply wired that I had to think to write them down because I use them “without thinking”.
So this is handy with normal commands:
git-add foo.cc
<do some stuff>
!g:0 bar.h
git-add foo.cc bar.cc
<do some stuff... oh wait, I didn't mean to do this>
git-reset !g:*
But with subcommands, you end up matching against all the git operations; !* matches all the arguments to the `git` command including the subcommand so you can't conveniently say "yes, that last git command but I want to change the subcommand"
I don’t care if you have `git add` as long as you also have git-add, which is more easily scriptable and simply easier to use.
The `git add’ approach always reminds me of using a mouse and a menu (ugh): select the git option, drag down until you get to the “add” subotion and then…. Supposedly that’s more “discoverable” and maybe it is, but you don’t need discoverability for the things you use every day!
I've never understood how people manage to use ! in a useful way. Primarily I think because if you get anything wrong, repeating the command does something completely different. But maybe I'm not fully familiar with all the functionality because I don't understand why sub commands would make a difference?
Minor point, but on a recent project I stepped around Clap, looking for something that was small, focused, and fewer silly edge cases. Argp works really well. Highly recommend.
Linux will be eternally doomed to <5% market share as long as it's developers harbor their masochistic fetishization of the linux terminal.
You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal.
The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language. Imagine an LLM better than GPT-4, but the devs only speak Klingon and refuse to implement English because Klingon is more efficient on paper. Then they constantly groan about low adoption and training data availability, while death gripping Klingon as the superior way of interfacing.
Please, for the sake of humanity trapped in Microsoft's dungeon, please come down off your CLI high horse and make a user friendly OS.
> You have ostensibly "user friendly" distros like Ubuntu, that still, in 2024, refuse to implement the standard ctrl+v for paste and add a modern cursor to their terminal.
The user-friendly distros - correctly - aim to solve this by making terminal use optional, not by taking on the nigh-impossible task of completely changing how input works in the terminal.
> The OS is kept artificially difficult to use, just because it's maintainers get off on knowing it's cryptic interface language.
Also, that's not the reason. It's not some superiority complex or fetish, it's that the existing terminal paradigm is really good for what it's good for and there's no point in sacrificing the existing user-base in order to try and appeal to a wider audience who will never use it anyways.
You are correct. If you use a computer to check your email from your grandkids because you somehow still don't have a smartphone - yes, the terminal is optional.
But please, enlighten me how an average modern desktop computer user could install a free media codec pack on a user friendly distro without opening the terminal?
Linux has this problem where if you want to do anything above the absolute most basic tasks, you have to start goolging and copy+pasting cryptic lines of text into the terminal and cross your fingers that it does what you hope it will. As soon as you break away from the tasks that 95% of users do, you're in for punishment.
Mind you, I have been using ubuntu for 18 months now. And have been using Linux on and off for 20 years. I do it because...Micorsoft, but holy shit am repeatedly stunned by how average-user hostile linux is. They just refuse to stop speaking Klingon except for the most absolute basic things.
In my favorite distro, the KDE spin of Fedora, tested on a fresh install.
Click the Discover button on the toolbar, or click the "Start" menu -> System -> Discover (Software Center).
Type codec in the search bar. Browse the results, the GStreamer codec packs are in the top 10 results and have descriptions about what formats they add.
No terminal needed.
Of course, on my own installation of Fedora, I've actually uninstalled the GUI package manager and use dnf in the terminal. :)
EDIT - And if the new user doesn't find the Discover app by browsing around, it will be the first result if you use the search bar in the start menu and search for "install". This aspect is truly easier than Windows. EDIT 2 - Oh, actually the Welcome/onboarding thing that pops up on a new install explains what Discover is for...
> But please, enlighten me how an average modern desktop computer user could install a free media codec pack on a user friendly distro without opening the terminal?
Do you need to? I thought Ubuntu shipped codecs by default these days. But if it's an extra package, I was pretty sure Ubuntu shipped a GUI frontend to package management these days, and if that's not good enough you can use it to install synaptic and do whatever you need[0][1].
> but holy shit am repeatedly stunned by how average-user hostile linux is. They just refuse to stop speaking Klingon except for the most absolute basic things.
To marginally overextend the metaphor, you speak English (which is a terrible mess of a language[2], but it's familiar to you), immigrated into the Klingon Empire, appear to understand that Klingon is actually a more efficient language, and still want the Klingons to stop speaking Klingon and convert to using English, because you want it to be easier to flee the Terran Empire[3] if they did even though most people won't do so regardless.
[2] I say this as a native speaker: English is a horrible mess of a language, mostly because it started as 3 other languages in a trench coat and never stopped tacking on bits and pieces of other languages.
[3] Okay, the metaphor is way more than marginally overextended, but it's not like people would flee the Federation...
For the simple case, the option is there (Ubuntu and Fedora have their software centers and GUI control panels, SUSE has YAST), just most native users don't use them. For the complex case, it's not practical because that would mean overhauling the long tail of packages.
Around 1999, I said to someone, "You cannot be 'l33t' and also have the Year of the Linux Desktop."
And some people really love that l33t feel, right down to git. I've had people here tell me that "reflog" is just as intuitively obvious as "undo." You can't reason with those people.
I'm scratching an itch right now to make a wizard-driven application, but in the CLI. Right now I am noticing little subtle bits of friction driven by Arcanery, such as things which aren't easily possible in Windows being available in Linux, but locked behind a hoop or two. Even the input prompt itself in my chosen language is slightly sad.
I'm genuinely curious what you see as an ideal state here? Most end-user oriented Gnome and KDE-based desktop OS's (Ubuntu, Fedora, Mint etc.) are already mostly configurable from menus, for most features an end-user would need to care about. (If I'm mistaken - what feature did you have in mind which isn't?) Outside of that, just run the application you're trying to run.
Why would the user need to worry about the ergonomics of the terminal? Is that something people worry about on Windows and MacOS?
1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that)
2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc.
3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy.
But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.