Many of the points raised point to real glitches, cruft, and frustrations with using the CLI. Those get more frustrating for people who only occasionally use the CLI, and less so for those of us who live in the shell.
Many of the same kinds of problems exist in GUIs. I rarely use Windows so when I do I can’t find or discover what I need.
Over time you remember the commands and flags, write aliases, set up config files, and mostly it becomes second nature.
This comment is a good distillation of my frustration with Unix ideologues. Unix and the CLI can never fail, they can only be failed; any possible unhappiness is a "skill issue"; it's your job to memorize a thousand arcane and badly-systematized program names and flags, created in an era of RAM and disk space limitations which have no relevance today, etc. And going "many of the same problems exist in GUIs" is a "no u" tier of response.
Do you expect to go inside a plane and fly it with no training? Or pick up a violin and play a sonata? The terminal have its flaws, but all other interactions models have their own. But when people don't try to learn the basic tenet and just ask why it can't be like $other_system_they've_learned_first, you bet that they're going to point you to the manual.
I expect that pilots are allowed to have opinions about systems in the plane as being user unfriendly, like MCAS of 737 Max fame. I expect violinists to be allowed to complain when their bow is rosined wrong. Sure, we should expect users to at least read parts of the manual, but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation, haven't you got to ask to yourself that there's a chance we're making this unnecessary hard on ourselves for no reason?
> but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation
That was an unnecessary spend then. You should ask yourself why ffmpeg still exists if if it's that hard to use. There's a plethora of simpler tools that exists for simple uses (handbrake, XLD,...). The truth is that if you want versality, there's no better than ffmpeg and it's core usage is relatively simple. It's an input | filter | output pipeline, with various options to fine tune each one. If you don't have the domain knowledge, it will be hard, just like a layman inside a plane cockpit. But if you do, everything makes sense.
Same with a lot of other software. There are bad design out there, but if something persists with no other incentive than its users, you should probably ask why first.
I expect a light switch button on a plane act like any other light switch button everywhere else - switching the light when pressed. The fact that the you can point to the terminal manual that states that you must use --- triple tap for that is irrelevant - that's still very bad design, and you've just dismissed a real issue with an bad analogy.
> I expect a light switch button on a plane act like any other light switch button everywhere else
Me too, which was why I was very surprised when I discovered light switches in the USA worked backwards[0]. :D
(When I initially read your comment I didn't notice the use of "button" by which I guess you're referring to a push-button toggle style switch? But either way I still think light switches are an interesting example of non-obvious things that don't work the same way in all environments. (Even ignoring the "one light controlled by multiple switches" situation.))
Unix and the CLI tools represent a huge part of the foundation so much newer software sits on. No one can just change the commands and flags to make them less "arcane" or more "systematized" without breaking millions of lines of scripts and tools and workflows.
Anyone can make their own tools if they have a better idea, and sometimes those take off and get adopted -- look at vim and now Neovim, rg (ripgrep), even Python pushing Perl and bash scripts out of the way. And plenty of people will call those things arcane too.
If you manage servers you know that RAM and disk space and other limitations have lots of relevance today. I'll quote you the next time my boss or customer asks me to explain a huge AWS bill.
If you don't like Unix or CLI tools, or don't want to spend the (admittedly signficant) effort to master them, no one will force you. I think the effort pays off. I have dodged more than one round of layoffs because I can work from the command line and keep legacy scripts and code working.
Dismiss or make fun of us "Unix ideologues" if you want, but I don't worry about losing my job or customers like my friends who have "mastered" VSCode pasting in LLM-generated snippets of React.
You also forget commands and flags over time, leading to the responses you denigrated as a skill issue.
And this is not from a "rarely use" crowd like in your Windows example
Sure. That's why --help and man and info exist, along with the volumes of online and printed documentation. The Unix/Linux shell and command line tools have to rank near the top of most-documented software in use.
When I wrote "skills issue" I had in mind the mentality that equates learning the standard tools, mastering the environment, and always improving skills with a waste of time, a few minutes or hours diverted from pasting together API calls or prompting an LLM. I have watched programmers spend hours setting up color schemes and fonts in their IDE, and then complain that they can't remember a flag for grep.
Years ago I worked at a software company where everyone used the Eclipse IDE. I tried it but it felt too slow and buggy, so I fell back to my usual vim in the terminal. Every week or so the team came to a halt when Eclipse got an update to the Subversion SCM plugin (this happened before git took over). Eclipse would have a version of Subversion incompatible with the version on the servers, causing the team to stop to deal with that. I used svn from the command line, same version as the server, so I could keep working. Eclipse broke down so often I couldn't understand the team-wide devotion to it. And they made fun of my "arcane" and obsolete workflow. Now I work with teams who use VSCode and I see the same kind of thing play out -- plugin updates that break the whole environment, weird problems from the bowels of npm that no one can figure out. And they tell me they don't have time to learn vim.
Seems a bit harsh to call out the developers of all that software like that.
But I do agree that software interface design and empathy are both skills that many software developers might benefit from developing further.
In their defence, developers unfortunately often don't seem to have access to many resources for upskilling themselves in these areas either--people don't seem to realise that simply telling someone to, say, just "git gud" at empathy is actually a form of gate-keeping that doesn't really benefit anyone.
Admittedly, if I was feeling snarky I might be tempted to say being able to create software interfaces that may take a person from four to twenty-one or more years[0] to learn could be considered a "skill" of sorts, I guess, but that wouldn't be very empathetic of me.
----
[0] "40% of people answering this survey have been using the terminal for 21+ years / 95% of people answering the survey have been using the terminal for at least 4 years"
I meant that people who struggle to use basic CLI tools have a skills issue. The tools date from decades ago, got embedded in millions of scripts and workflows, and so their UI won't change. Like it or not we have to accept those tools have become part of the background, so complaining about grep or awk or bash just goes nowhere.
The people who wrote the shells and tools like vi(m) and awk didn't suffer from skills issues or lack of empathy. They wrote tools for themselves and other skilled programmers, in environments that no one under 50 can remember or imagine. Monochrome 80x24 displays, 8 MB of RAM, floppy disks (or worse) -- major hardware and software constraints. Blaming them for not anticipating modern hardware and software (and attention spans) seems like blaming Henry Ford for not inventing the electric Mustang.
> I meant that people who struggle to use basic CLI tools have a skills issue.
I very much understood that's what you meant.
(And assumed you meant "skills issue" in the dismissive sense--if you didn't, ummm, feel free to skip to the last line of this comment, I guess...)
My comment was written in a manner to "humorously" imply I misinterpreted your comment as criticising presumably much older individuals rather than the actual intended targets of the criticism. This was in an attempt to prompt a possible reconsideration of the statement.
Seeing as I obviously failed in my attempt, let me restate my point less delicately but more clearly:
Unlike the tools from decades ago that can be & often are useful today--in spite of their less than perfect interfaces; attitudes that lead to shallow criticisms of people's skills are outdated, should be deprecated & removed from use--because such gate-keeping serves no useful purpose. In fact, it never did.
----
I mention this because I happen to care about our shared hobby/industry and those who have chosen to be part of it--because the technology is really fucking fun and/or fulfilling and/or frustrating.
And if the technology can be really fun why wouldn't I want as many people who are interested in it to have some of that fun? Or, heck, earn a living with making it less frustrating?
Humans are often already fantastic at self-critique of their skills--they don't need other people to shit on their skills too. (And I'm intentionally writing all this in case some of those humans are "in the room with us now".)
----
Besides, these survey respondents were primarily people who have stuck it out with our imperfect technologies for at least four to twenty or more years.
Not only were they prepared to admit that they didn't know something (something I personally find challenging to do, at times *cough*) they were kind enough to do so in the context of a survey that would help Julia Evans create an effective targeted resource to help people learn the very skills that are apparently of such importance!
----
I would also note, for example, one might consider it reasonable if only ~7-10% of people might know to use `cmd1 |& cmd2` for redirection of both stdout & stderr given it has apparently only existed since Bash v5.0, a mere six short years ago--and, coincidentally, probably one of my favourite Bash tips I've learned in the past five years because I could never seem to remember which order the `2>&1` went in--and seems maybe I wasn't the only one?
Why, if I was feeling petty, I might even point out that the existence of `|&` might even suggest that decades-old tools can in fact change their UI and that even complaining about bash might not just go nowhere.
Why, if I was feeling optimistic, I might even imagine that maybe attitudes can change!
----
On a definitely related & probably incredibly condescending sounding note:
What's a useful CLI tool tip you'd suggest would be valuable for people to know?
You can read skills issue as an insult or call it gatekeeping. I meant it literally: not learning common and fundamental skills of the craft of programming. Worse, dismissing tools as arcane or poorly-designed rather than learning how to use them. And blaming laziness or poor memory on the tools.
People actually frequently fail to self-critique their skills, leading to what we call the Dunning-Kruger Effect, the Expert Beginner, the 21-year-old "senior engineer." Listening to and learning from someone who has mastered a skill -- a mentor -- describes one of the best ways to learn something. Interpreting criticism as a personal insult, then blaming inanimate things like Unix CLI tools, doesn't seem productive or professional.
Calling command line tools poorly-designed, arcane, cryptic, etc. blames the tool, and perhaps by extension the author. I have managed to remember 0=stdin, 1=stdout, 2=stderr for decades, and I expect anyone who wants to get into programming can remember three file descriptors. If they can't remember those things, or look them up when necessary, and then blame the operating system or tool, what would you call that if not a skills issue?
As for the survey results that started this thread, I interpret them in the context of my own (40+ years) experience programming. Some people master the Unix CLI well enough to get things done with it. They appreciate the original intent of composability, "everything a file," plain text as the common format. Many other people have learned to type a few commands they don't understand, or copy and paste one-liners found online. Those people "use" the command line in the same sense that I "use" TurboTax -- infrequently and without motivation to master it. I have and continue to work with programmers who have a terminal window open all the time in their IDE, but can't actually do much with it. Then they get on threads like this to complain that command line flags "lack discoverability," as if the man tool didn't exist.
You can criticize what you perceive as my attitude. I have mentored and taught enough programmers how to improve their command line skills over the years to feel OK with myself when I tell complainers to stop blaming the tools. I got lucky early on and had mentors who taught me this stuff, the concepts and design behind Unix and its tools, and got me through my skills issues. Now when I run into something I don't understand I interpret it as my own skills issue, not as a sign that another programmer didn't know how to predict the future or didn't care about correct "design," as if that described anything real.
If I could change two things about terminals it was thesd:
1. Make text editable with a cursor and mouse selection like in any other modern text application
2. Make use of the normal and expected text shortcuts for copy, cut, paste, select all etc. Make ESC *escape* the current program.
And I am a heavy terminal user who has no issues with how it currently is, but I also have to teach these things...
I am aware that such a change would probably be 1000 times more complex to pull off than most people would think, but every time I have to explain to beginners they can't edit the text I die a little inside.
The use of a terminal is to communicate with an application (the shell mostly, and other REPL software). The text shown is a log of that interaction, not the interaction itself. We could probably design a better interaction model (smalltalk, plan9) but the current one is the most simple.
I understand that. But there is no reason (other than legacy cruft) why I shouldn't be able to fix a typo mid-command with arrow keys instead of backspace before sending that command as a default.
I am perfectly fine with having sent commands uneditable and responses uneditable as well.
The frustrating thing is that the code for mouse move/selection already exists, but it's a total rathole to get it working, and I don't have the whatever to be a whatever maintainer across everywhere.
macOS’s terminal app does #1 but you have to option-click. It’s kind of a hack too, it just issues a bunch of right/left arrow key codes to the shell to move your cursor to the designated spot.
Your second point is definitely my #1 issue, at least it is on Linux and Windows (macOS at least uses Cmd-c everywhere and it works.) I have to constantly remember to use ctrl-shift-c to copy in the terminal but ctrl-c to copy everywhere else, and I constantly forget and use ctrl-shift-c in a not-terminal program, and do something stupid like open dev tools in chrome, ugh. This is, unfortunately, not fixable. Not without rewriting every app on my system to use a different copy/paste combo.
Ctrl-C is SIGINT, I don’t want to change its definition of sigint just to make room for copy behavior.
What I want is to make a different shortcut trigger copy/paste, everywhere, and that’s not fixable. Every app independently decides to make ctrl-c implement copy, so changing that is basically not possible.
I'm sorry, I thought there might've been some confusion re. actual sigint definition based on some deeper history and ASCII codes (which didn't seem like it from cursory search)
> ctrl-shift-C will send SIGINT
You filter against your terminal app, where Ctrl+Shift+C will continue send Ctrl+Shift+C
Agree, MacOS terminal has this distinction between Control which is purely terminal modifier, and Command which is purely Mac modifier, hence when I work in terminal on MacOS I do CMD+C - CMD+V and this is consistent with all the other apps, while on Linux you have to either think of CTRL+C as a copy or as a SIGINT, depends on which app you are using.
This was so good experience for me, that I reconfigured my Linux terminal to have Win+C, Win+V and Win+T (for new tab). However this is inconsistent with Linux window management. Since then I have been actively looking for a way to change the Linux OS manager to have default global hotkeys in the MacOS style. Anybody knows how to do that? ( https://news.ycombinator.com/item?id=41439601 - suggested xmodmap is a key mapping way which will break my CTRL+C in terminal )
and insert the missing number without deleting the already existing numbers in a vanilla (non-emacs, non-vim) terminal. In nearly every other editable text field people know well in their lived (including the one you typed in for this comment) you can move your cursor to the middle of a sentence and insert text with a mouse click or the left/right arrow key.
And before someone suggest some option to enable this: my comment was about changing the defaults.
The terminal model is just to display the text that the currently running software provides and send input to it. It’s not a text editor. The prompt is a feature of the shell and other REPL programs, not the terminal. Bash and Zsh and others use readline which allows text editing like navigation [0]. And there’s rlwrap for programs that lack these.
Using the arrow keys to navigate the current input is well supported on most modern terminals, and has been for most of my adult life. If this isn't working properly in your terminal, then I'd recommend experimenting with the various settings available to you.
Some terminals also support mouse navigation, so keep an eye out for that as well.
I'm sorry that you've been dealing with this frustration for so long and under the impression that it was just supposed to be that way and not fixable. The good news is that it's NOT supposed to be that frustrating and you CAN fix it
Edit: you edited your comment somewhere between my first seeing it and my reply posting. I haven't had to modify the default settings on my terminal to fix things like this in about 20 years. I've changed them to tweak various preferences like scrollback, cursor shape/size, etc. But arrow navigation has worked out of the box for me for so long that I literally can't remember when I last had to fix it. I don't know why our experiences have been so different, but I'm sorry that a tool that has been so useful for me has been so frustrating for you.
I've not had luck with selecting a position with my mouse in a terminal shell, but arrow keys is rarely a problem.
Old enough terminal or old enough host, sure, there can be some fighting involved. Of course, working in those conditions, sometimes backspace doesn't work either and you have to hit ctrl-H like an animal.
No option is needed, it’s worked this way since the 90s at least. Mouse is not commonly enabled but would be inefficient to use as hands are already on the keyboard. I haven’t missed it, but it could be set up with a script, no?
If arrow keys not working for you, install a new distro.
You can already do this, in Emacs and possibly other terminals. It is pretty easy to implement. The problem is that this can also cause other problems, especially for newbies, because editing the text may not do what you think it will do (e.g., editing the output of ls or editing a command after you started running it).
1. I probably don't care. On the list of things I want from a shell (what you are asking for isn't a function of the terminal, but of the program running in it) this is so low, I would never cared if it was added. I never wanted it to work like this, but as long as it doesn't actively get in the way, I'm OK with it.
2. What's "normal"? Do you mean CUA-style navigation? In that case, absolutely, no effing way! These keybindings are awful. And it's good that they are awful. It wouldn't be a good idea to often accidentally press C-c and kill whatever thing you are working with. But, it's not a convenient key chord for an operation as common as "copy". Now, you may say "in addition to already existing text editing key bindings": but then, again, no, because I want these keys for rare and dangerous operations. I don't want them to be duplicates of existing and better functionality.
NB. Both of your improvements aren't about terminals. They are about programs run by terminals (eg. shells). But you probably knew that already. I realize that OP and the comments lump all these tools together under the same label. But it's still worth pointing out that these are separate issues at least in the sense that nothing you can do to the terminal will effect the change you want to see.
and I'm curious on the technical details for why it matters for you.
if it's, say, a chrome extension someone whipped up that makes it a button click to generate, or a script someone handcrafted, or somone had an LLM generate, or a fully automated bot doing it off a Cron job, or a billionaire is paying a human in the Philippines to do it by hand, some SV startup millionaire is bored with life and spends too much time here, a college student that has some free time between classes... the end result is a relatively simple post linking back to previous threads.
in what manner does having a human in the loop for that specific post affect your broader feelings about this site?
and I'm here to understand how, among other things, how other people (who aren't things) work/think. It was clearly important enough of a question for you to bother to login and post the comment asking if it was a bot, and you wanted some sort of reaction from you posting that message, so I ask, in all earnestly and not confrontationally - there are no wrong answers, what were you thinking?
I encourage users to log context switches and then find tools to address the context switch. Try to stay in your terminal whenever possible .
For documentation context switches (e.g. stackexchange/googling) : install tldr, fabric , devdocs, sdk docs etc . And get comfortable searching man pages with “/“ and man -K
For job/task context switching (e.g. running multiple jobs like a transfer job and a measure-status job), get familiar with bash job control or tmux
For history context switching (e.g. re-running an old command) , set a long history like HISTFILESIZE=100000 and use ctrl-r. If you ever run out of history, make it bigger . Also dump helpful commands into a README.md with echo COMMAND ARG1 ARG2… >> README.md . Fzf is also helpful.
For context-switches stemming from missing settings / dot files, set up “dotfiles bare git repo”. You can push this repo around with SSH, so every fresh machine will have your settings on first login.
The challenges in her survey are common, and I wish shells did better user onboarding and tutorials, the way games and consumer apps do. But each one can be addressed with the right preparation.
If you use the terminal for any appreciable amount of time I heavily suggest getting fzf (even if just for the search).
Tmux is great if you need any more than 1 terminal window open at once - just remap some of its hotkeys to stuff that make more sense for you (e.g. I use "Alt + |" to split vertically and "Alt + -" (minus) to split horizontally).
Man pages are generally about 500 times longer than I need them to be (just help me do a basic curl/SSH copy/... please) - so I have cheat.sh aliased which helps a lot with simple "how do I use X".
Aliases in general are insanely useful. If you're a fzf search whiz they may not help you as much but seeing people type common commands out multiple times a day... makes me happy knowing I have my alias bank.
> Tmux is great if you need any more than 1 terminal window open at once - just remap some of its hotkeys to stuff that make more sense for you (e.g. I use "Alt + |" to split vertically and "Alt + -" (minus) to split horizontally).
Nice tip! While I don't mind the default Tmux keybindings (<prefix> " and prefix % for horizontal and vertical splits), one thing that used to annoy me early on was how new panes would default to the directory where Tmux was originally launched, rather than inheriting the current working directory. Fortunately it was easy to fix with a few lines of code in ~/.tmux.conf:
This ensures that while splitting a pane with <prefix> " or <prefix> %, or while creating a new window with <prefix> c, the new shell inherits the working directory of the previous pane. This small tweak saved me countless unnecessary "cd" commands.
`fzf` is so universally useful I just recommend it by default to everyone I work with now who touches a terminal. The new fuzzy finding shortcuts it creates for shell history and switching directories alone makes it worth it, even if you never call `fzf` itself, as I recorded back in my tutorial eons ago. [1]
I can relate to many of the frustrations. As years have passed, I've been trying to lessen the (repetitive) effort required for basic monitoring and maintenance over plain SSH. I felt that just the shell wasn't good enough, and large software stacks just increase maintenance burden.
Ended up creating a GUI app called Lightkeeper (https://github.com/kalaksi/lightkeeper). Works over SSH, requires no daemons and is configurable. Still working on some unfinished features.
I've actually written many thousands of lines of Powershell for work and play. I first learned it because Vsphere used it for a CLI but I soon learned to love piping objects and filtering by property name. beat the hell out of bash that is for sure. And the ConvertTo-JSON command is amazingly useful.
Yeah. I also like the PowerShell model of cleanly separating the shell logic itself from various "shell hosts" (of which powershell.exe is just one). The Unix equivalent is the PTY interface, which is too low-level to be optimal.
It's so bad that I'd actually take the decades of cruft over it.
It was made by people who don't know how to use existing tools and what the actual problems are. It's like people who keep creating "new" text editors, but they never learned well how to use existing ones. So they end up with crippled half-baked thing that's some concept from the 80s that was discovered to be a dead-end in the 90s, but with modern cosmetics.
PowerShell is just incompetence and hubris of people working for a large company which can push their random garbage software on a lot of users and developers due to having huge market presence.
curl and ps are both aliases in powershell for their respective posh equivalents. For some reason grep isn't though, I'll give you that.
It also has positional parameters meaning you don't have to specify parameter names, though you might as well because tab completion is a thing. And if you're really keen on not using tab completion, it autocompletes parameter names for you meaning "get-help man -e" is equivalent to "get-help man -examples".
Here are less verbose posh commands for your examples.
The criticism of Unix shell coming from the authors of PowerShell and those who like it says something to the effect:
We want modern (and by that they mean C#-like) programming language in shell. We want user types, type checking, structured, modular code.
And they forget that the reason Unix shell is easy in some respects is precisely because it has none of that. Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells.
Structure will require a lot more operations for composing and decomposing it in order to transmit messages. Equality and identity become a problem.
Custom types are similar to structure, but on top of it present a problem with serialization (somehow both shells need to have same type definitions, and what happens if they inevitably don't).
The problems above not being addressed... what you get is another "scripting" language, of which there are already dozens, with no special benefits when it comes to it being used as shell, but with some problems. Just not worth it and illustrates lack of research and understanding of the problem space on the part of the authors.
" Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells."
Serialization is trivial in PowerShell but also much more powerful because you can pipe the output of any command to ConvertTo-JSON or ConvertTo-CliXML which gives you very nice STRUCTURED serialization that is much easier to consume.
There isn't really. For a lot of PowerShell objects, there's no way of converting them to JSON or XML. Imagine what happens if you convert a closure to JSON? It doesn't matter what language you use, it's always going to be a problem.
You are simply too inexperienced with the subject to be able to have a judgement on how (well) it works.
This is the single worst take I have ever read on Hackernews. You didn't actually give a single concrete reason why PowerShell is bad. I will give a major reason why it is AWESOME:
objects are piped instead of text. This single change makes a ridiculously huge improvement. You are no longer forced to perform incredibly tedious and fragile text manipulation. This also enables filtering on property names and the ConvertTo-JSON command which is amazingly useful.
The problem with any terminal replacement is that you have to support all existing terminal applications. If you don't, then your replacement is going to be useless for half a century until everything gets re-implemented and installed everywhere (and this is assuming you can get buy-in from everyone on this speculative 50 year investment). If you do, then congratulations, you have all of the legacy terminal baggage.
Atuin.sh solved all my problems with history: history by project : check, history by session :check, global history: check.
And if you want you can share history between computers.
I just have to enter 2-4 letters and I can found complex command to rerun or to reuse as example.
Prior to using Atuin, I had some fun fish plugins that used fzf to search my history. I still find that I use that most often (it even searches my atuin history too), but when that fails - or becomes overly complicated, that’s where atuin’s native search comes in. It really is a game changer for working on the console and I can’t recommend it enough. Here’s some of the things that are really great about it:
1. As mentioned above, scope awareness when searching history. This can be exceptionally helpful when you know you’re in the same directory where you previously ran a command.
2. Sync - this is why I started with atuin. It’s pretty easy to run your own sync server if you’re not big on send your commands to some random server somewhere.
3. Persistence - similar to sync, I love having my whole command history available when I stand up a new machine.
4. Secrets hidden - you can even set it so secrets are not persisted in your history. This is useful if you haven’t yet migrated to using something 1Password to inject secrets. Also, as a side, it makes it really easy to find secret references you’ve used before too.
> discoverability (55) There were lots of comments about this, which all came down to the same basic complaint – it’s hard to discover useful tools or features! This comment kind of summed it all up:
> How difficult it is to learn independently. Most of what I know is an assorted collection of stuff I’ve been told by random people over the years.
This is all too true, the discoverability aspect is one of the reasons why we exist (0), and there is lots to improve here for discovering terminal tools, how to install and use them.
Also thanks for running this survey Julia.
Also, let us know on what we can improve on the site if you find Terminal Trove useful for you.
Cool site! Personally, I think the weekly highlight is nice and all, but the value of an aggregator comes from categorization and searching, and I didn't see either on the site. I would love to see it's focus to be like selfh.st
> Is there anything we can improve here that can make this easier for you?
No OP but it would be nice to include link to categories in the header bar. It would make it easier. the dynamic animation of the categorizes at the middle of the page is annoying. You have it in very small font in the footer but this isn't the best.
Ah , missed the link on grayscale. In any case, I think a datatable is a must in an aggregator. I would get a lot more value out of being able to filter and sort based on the language, categories, github stars, etc.
I checked out your site (excellent content and very, VERY useful), and I came back comment with what I think is similar feedback that other commenters have.
I would suggest a few things -
1. Less resource intensive site - I’m on my phone, and it took probably 5 seconds to load the front page, and then to actually get to the list, it took a few seconds more. I do not have a current gen phone, but I’d hazard a guess that my phone is about average in age as far as the potential user-base for this site goes! Do not discount mobile users, especially for a site focusing on CLI applications.
2. Maybe I care what language a CLI utility is written in sometimes (Albeit, I can’t recall a time when I have). I’d add a search in the front page, if well thought out. Or, honestly, I’d just have the front page be the list. People are great at lists, and generally quite good at reading, and your list has very well-written descriptions.
3. Kinda related to the above, but I think the categories view is effectively useless. The categories already appear in the description (and if they don’t, they probably should) - so why not just skip straight to the list? You could add a filter for the list if you want. Or, even better - a simple search box!
I’m only giving these criticisms as a means to (subjectively) improve your site, because overall I think it is very well done and thoughtful, without a lot of fluff. There are hundreds more I’d not have criticized, but only because they felt like a waste of time and dead weight. Keep up the good work!
Please, let's just stop doing things this way. I understand that talking to libterminfo is annoying, but it produces a better result for everyone than everyone maintaining obsolete and incomplete databases mapping TERM values to capabilities.
That's not to say libterminfo is great either: we got into this mess partly because for (IIRC) ~10 years or so, the ncurses people stopped updating the terminal database with information about new capabilities like bracketed paste and 256 color support, forcing authors of programs wanting to use these features into using dirty hacks to detect or configure support --- and everyone has a different dirty hack!
Also, terminfo in inconvenient when jumping between machines. Who among kitty users, for example, has never experienced weirdness after ssh because the target machine doesn't have a terminfo file for "xterm-kitty"?
To fix this mess, we need to:
1. Define a new cross-terminal-emulator OSC sequence that instructs the terminal emulator to echo back THE WHOLE TERMINFO CAPABILITY STRING, in-band. No "user agent sniffing" with TERM. We detect features directly from now on.
2. Stop hard-coding random "ANSI" escapes. Use a library. Ask that library, "What does this terminal support? What strings do I use to accomplish what I want?" and then use it.
3. By default, don't output escape codes if output isn't a tty.
(#2 (by recognizing TERM=dumb) and #3 (because pipes) also address the problem of escape sequences ending up in the middle of output files and shell pipelines.
The terminal world is a mess right now. Continuing to live in squalor is a choice.
A lot of people now don't know how terminals work or even that terminfo exists.
Unfortunately due to the progression of technology and education, a lot of foundational knowledge is not being learned. Terminals are probably one of the biggest losers in this area. Even many technically knowledgeable people only know of terminals as "that box that pops up where you can type commands". They cargo cult/copy-paste the common escape sequences. Most things work "good enough" now that they never have any reason to learn more.
> 1. Define a new cross-terminal-emulator OSC sequence that instructs the terminal emulator to echo back THE WHOLE TERMINFO CAPABILITY STRING, in-band. No "user agent sniffing" with TERM. We detect features directly from now on.
XTGETTCAP does that (kindof), it's implemented by xterm, kitty, and foot.
xterm allows querying keyboard caps, plus a few others
kitty adds to that querying all integer and string caps
foot adds to that bools caps, meaning in foot you can query all of terminfo via it.
what we need to do is bring other terminal emulators up to par with foot's XTGETTCAP, and then we can finally ditch libterminfo for good.
I'd like to re-emphasize point #3. FOR THE LOVE OF GOD, if you are going to spew random ANSI escape sequences to stdout, please, please, please, ensure[0] that it's a goddamn tty!
One related: If you are a terminal emulator, and you default your TERM to xterm-somethingorother, it is on you to actually support xterm control sequences.
function lm {
local input="$*"
llm -s 'Answer as short and concise as possible' ${input} | glow
}
Here's an example,
$ lm "ssh command to forward the port 5050 on user@remote to my localhost:7001"
ssh -L 7001:localhost:5050 user@remote
$
Now for a sophisticated use-case I have a small tmux program where I can capture what's on the pane, enter a prompt and it will query an llm so I can say things like "How do I fix this error" or "what debian package do I need to get this to run right?" ... both these are recent patterns I've started and they've been real game changers
Some lesser game-changers:
* tmux extrakto - opens an "fzf" like search of all the text on the screen. So after a "git status", I can do git add (run extracto - enter partial path, press tab) and continue: https://github.com/laktak/extrakto
Yeah I tweaked the prompt to make it work reasonably well. There is also an experimental mode where it can reason and correct the command if it fails. Feel free to sent a PR!
I actually made a CLI tool (https://github.com/ddworken/hishtory) that automatically binds to Control+R to support both history searching and AI queries (by prefixing queries with `?`).
Ah this is a far more significant effort. I'm glad to see that there's so much consensus that default shell history is broken (I used to use logrotate because it would always truncate regardless of how many ways I told it to not ever, under no conditions, ever, do that).
Nice to see there's so many options these days. Someone else mentioned "https://atuin.sh/" in this thread - which is also new to me. Keeping up with things is seemingly impossible
somewhere around a few thousand lines. I want it to support tens of millions. I have a fast enough computer, storage is effectively free. I've tried all those things - everything short of doing a bunch of bpf filters and setting breakpoints on the binary myself.
honestly, with these modern systems this shouldn't be a problem any more. I look forward to it.
It features an integration with the abbreviation feature in fish and zsh (via plugin) to expand the suggestions for editing, if needed, and execution.
There's stdin support, which can be used to pipe in error messages, for example. I've thought about something like your tmux setup to capture and pass some history to the model, but in practice redirecting stderr handles most of the potential use case.
> Here's an example,
$ lm "ssh command to forward the port 5050 on user@remote to my localhost:7001"
ssh -L 7001:localhost:5050 user@remote
Was this a real example of the input and output generated, because it seems wrong.
-L 7001:localhost:5050 listens on port 7001 locally and forwards connections to 5050 on the remote host.
Based on the request, you want -R 5050:localhost:7001, which listens on port 5050 at the remote end and forwards connections to a server listening on localhost:7001 on the local end.
Has configs for multiple programs, is warm (low blue light), avoids too many colors / clown vomit
I was considering giving up on colors with zenbones before I found this
For copy/paste I'm using a 36 key keyboard, ctrl is on a thumb key hold, while holding , is shift-ctrl. But that's probably not as generally useful to others
> inconsistent command line arguments: is it -h or help or –help?
I've said it before and I'll say it again: the error "Option `--help` not understood, did you mean `-help`? Use `-help` to display program options." is one of the most insulting things a program can say to me. `--help` is the lowest common denominator. You have to support it. I don't care what your program has to special case in its parsing, just do it. If I knew your program's preferred syntax, I wouldn't be asking it for help.
--help isn't even the lowest common denominator. An incorrect argument list is. The program knows it was given incorrect arguments, it should show help.
Many programs prefer to be concise when their arguments are wrong, perhaps on the assumption that it's probably a simple typo rather than a request for screenfuls of help information. This sometimes is and sometimes isn't an ergonomic choice. (I usually prefer conciseness.)
But asking for `--help` is unambiguous, and is in fact the lowest common denominator way to be explicit about it.
-? should be lowest common denominator, because that is exactly equivalent to passing incorrect argument list when using getopt(). Whether that should produce concise help of the kind "usage: foo -abcdeEf <file>" or full help is another question.
> The common denominator for getting help would be man(1).
That's... not what a common denominator means. It's far easier to check for `--help` or `-h` and print _something_ than write a whole document in a weird markup language for man.
"common denominator" is the thing that is guaranteed common for all commands.
man(1) is, provided that people produce man pages. It's also orthogonal and composable without interference: one can write a man page for commands that don't have man pages.
Flags are not, because commands parse their arguments in whatever way; all commands can accept arguments but arguments are also part of the operational interface contract. man(1) is decoupling all possible problems out.
It is also extremely obvious than `man foo` is side-effect free, whereas `foo whatever`, whether `whatever` can be `--help` or anything else, has unknown effects when the command is unknown.
Some argue that man pages are too rich; well the man pages can just also start with a summary identical to what a hypothetical `--help` flag would output.
Turns out this is the conventional `SYNOPSYS` title of section 1 man pages, and possibly the `OPTIONS` one; if these are absent or badly written then one could reasonably posit that a hypothetical `--help` flag output would be just as unhelpful; cue the wads of commands that "--helpfully" output `foo [-4236xXksirtTgsdv]` as help, which tells you nothing really helpful.
My understanding is the opposite: man pages are much more difficult to produce than plain help text, so it's unreasonable to expect they'll always be available, while help is easy enough to (almost) always be there. If you use any CLI library at all, it will automatically be generated. If you don't, the equivalent of `argv[1] == "--help"` is good enough.
These days, I'm positively surprised when I find man pages for a program, whereas I'm annoyed when one doesn't support --help.
> man pages are much more difficult to produce than plain help text
They're absolutely trivial to generate these days, gone are the days of having to deal with roff, you can write a quite dumb markdown file and produce a man page out of it in short order.
I'm not necessarily saying they're _difficult_, but it should be obvious they're relatively harder. For --help, the least I could do would be a conditional at the top of the program, or let my CLI library auto-generate it for me. For man pages, I have to go out of my way to explicitly generate and distribute them.
There are people arguing that? My feeling is that man pages are usually so thin as to be useless in 50%+ scenarios I need them. I really wished the culture defaulted to expecting all software to come with Info pages.
> b) don't have a file named, say, `-a` in the current working directory.
Rather:
b) don't have a file with a single letter name in your CWD, like `a`
Try this:
touch a
ls -?
And yes, it's even more damning; you don't generally find legitimate files named `-a` or similar - rather, it's clear indication of someone invoking some CLI command wrong (`cp` comes to mind). However, single-letter files and folders are a relatively frequent thing to see.
I don't see it. What are you trying to show with 'a' instead of '-l'? Why would a file named 'a' interact with a glob like '-?'?
$ touch a
$ ls -?
zsh: no matches found: -?
$ bash -c 'ls -?'
ls: invalid option -- '?'
Try 'ls --help' for more information.
$ dash -c 'ls -?'
ls: invalid option -- '?'
Try 'ls --help' for more information.
$ touch ./-l
$ ls -?
.rw-rw-r-- 0 user 10 Feb 18:32 -l
.rw-rw-r-- 0 user 10 Feb 18:31 a
Very few things grind my gears like having to search through a wall of "--help" output and lengthy list of arguments to find the error that describes the problem. Screenfulls of text when the error is "Option 'b' unknown" isn't helpful.
If you need to learn something (e.g. you're taking a class or your supervisor wants you to learn something), then reading the documentation is a good idea.
If you already know the content, but accidentally made a typo and are trying to debug it, then reading the documentation isn't going to help. An error message pointing out the problem will help.
I had a teacher like that in High School. "I made a mistake in this proof, but I'm not sure what it is." "You have the book for the course, the answer is in there."
No but the sports referee perhaps specializes in one or a few games/leagues.
And at high levels, a referee role is probably similar to physician/lawyer where you'll have annual rule updates/changes, jurisprudence history of past rulings, and conventions/associations of referees where they will be spending money, time and effort when not on the field.
Now multiply the referee's game or league types by everything in /usr/bin
Reading techical documentation is a skill. It's one that is sorely lacking in IT from develpers to ops. RTFM when learning is a valid lesson in and of itself.
This seems like it would be solved completely by printing the error message ("option b unknown"), and then also printing the "--help" stuff. You can see the error inthe first line(s), so `head` will make that easy to see, but anyone trying to print the help text will get it.
Sometimes, arguably, you can do better. For instance, some CLI tools try to guess what the user was trying to accomplish, and show a more specialized message. Eg. kubectl will tell users that a particular kind of resource they were looking for doesn't exist, but there are some with similar names.
This is especially useful in situations where the help text is enormous (dozens and dozens of options).
I agree with this, but would also point out that many junior engineers I've worked with completely give and ask for help if the program doesn't do what they want it to and prints out many lines of help. Even if there is a clear message at the top of the large output, they get overwhelmed.
An incorrect argument list should concisely tell me what is wrong with the argument list, and that I can use --help to explain the whole thing. I don't want to scroll up 20 pages to fix a typo - assuming the program even printed a specific error before it printed 20 pages of help.
Oh god please no, I hate the rare program that poops my terminal full of seven pages of output and I have to use like shift+pgup or the mouse to get back up to see the only four useful words of output: "option --anakyze not recognized". This also confuses the heck out of beginners.
MariaDB also doesn't print the entire manual when it goes "syntax error at ' OR 1=1". It makes no sense.
You can include "See --help for more information" at the end of every error to make sure everyone knows where to find that, though, since indeed not every program uses the same syntax for usage. 90% of the time I don't need a copy of a program's manual in my scrollback when I, say ,typo something or forgot that two options are incompatible. There is a reason scrollback exists and I use it for that purpose. I'll look up the manual or run --help in another terminal tab/window, or choose to run it in the current one at my own discretion thank you
Just to throw this out there: let's also hate on programs that give you seven pages of output for --help but print it to stderr so you have to jump through shell redirection hoops to pipe it to a pager to be able to read or search through it.
This reminds me of something I remember having installed years ago that would format `man` pages as a nice document (using... grotty or something??) and open them in Preview or something. I think it was on a mac and it was 15+ years ago.
Genuinely my least favorite thing in the terminal is when I forget some detail about... usually CURL, since they use the capitals AND the lowercase letter arguments for very different things. So I end up having to use the / command in `less` to search for some common word for 3-5 minutes because the manpage is so disorganized. We have a much better tool than the Terminal for viewing long-form text content, so maybe I just need to alias `man` to open a website that publishes manpages.
`--help` is a GNU convention, which is why it's not as universal as you want it to be. Of course these days most Linux users interact with GNU tools and thus go on to develop their own tools with the same convention, but it's the reason why non-GNU things like BSD utils or old `openssl` don't have it.
The GNU/BSD conventions are a lot of fun when you have some automation scripts that are used by people who are split between MacOS and Linux (or WSL on Windows).
`--long` options started with GNU (I think) but were soon adopted more widely. One of the really nice things about ksh that bash has neglected to copy is that its `getopts` easily handles long options and has built-in `--help`.
It's 2025, not 1995. I'm about as sympathetic to this as "POSIX doesn't have it." For something like this, I don't care.
I don't care how it's done. Heck, dump the help if you see any option with two dashes, if you're offended about long options. I don't care what other things dump help out too as long as --help does. But both -h and --help should always produce help, no matter what, no matter where you are, and I'd really like -help too, even if that is a bit more complicated. Though since I also want "a -h or a --help in the parameter list reliably makes it so that help is printed and NOTHING ELSE happens", "-help" should generally work as "-h" and "extra stuff that won't happen because -h is in play". It is an error for a program to both print the help and take any other action; should always do one XOR the other.
What about programs with such simple CLIs that they don’t have help?
How about non English speakers who might be inclined to type —ayuda or something?
In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.
> What about programs with such simple CLIs that they don’t have help?
It is crapware
> about non English speakers who might be inclined to type —ayuda or something?
Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”?
I'm not offended hehe. I like small processes, and am into language learning, so my bias is showing. I think how things are, with most supporting --help, but not all, makes sense.
I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
>I think it could be normalized further by having a shell function get help for a command.
See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
Interprete gobal de expresiones regulares, as to my Knowledge grep stand for global reg ex parser.
My Knowledge come from some archaic Sun manual. I wanted to find it, and everywhere it says print… I had it wrong.
Anyway the idea is to show that translating is always partial, ans a full translation would be a titanic and unproductive work.
I’m a native speaker of a couple of languages, and learned some more. So i have used computers in many languages. I hate command line translations, all are bad.
To be clear, the point of my comment was to give the reason that `--help` isn't universal, not to present any opinion on whether it should or should not be. (I myself am in the "go on to develop their own tools with the same convention" camp.)
The fact that they already special-cased the parser to let you know that you used the wrong help option, but didn't just forward to the right one, is just incredibly pedantic
I think the idea is that fuzzy search makes it easier for users to spot typos and this is a general feature of the flag library not something specific for --help.
Short-circuit any typo may be dangerous.
Now, an argument can be made for including as many aliases for "help" and "version" as possible but that's a different story
You can of course - I think the point here is it's different people with different goals writing the CLI lib vs the application.
So it's often not the case that a single person who made the decision to have a message that says "you asked for help, but you did it wrong; before I give you help you have to ask correctly."
It's "helping" in an incredibly pedantic and unhelpful way. The developer has opted to add explicit support for the common option, but only as a means to tell the user that they are "holding it wrong" (in the immortal words of Apple)
Also, single dash for long args and not just short args. I think mostly Go tools do this, and whatever purism is used to justify the choice, I can't think of many CLI apps that don't use a single dash for short args (and combining a sequence of flags) and a double dash for long ones.
If it’s not installed by default on server-oriented flavours of Linux then it’s dead to me, unfortunately. Most orgs aren’t going to agree to roll it out across tens of thousands of machines on a whim.
My entire Linux experience is dictated by what’s installed by default on rhel and/or ubuntu.
This is why I originally learned vi. Working on DoD machines as well as this of other consulting customers. I had a notebook of short scripts and commands that would make my life easier. I couldn't use any media or even reference the internet in many of the data centers and labs.
"installed by default" should never be a compelling consideration for an org with ten thousand machines, or one hundred. As soon as they have their own package repos and automatic deploy systems, it should be as simple as saying "fd is a fast file finding utility packaged upstream as 'fd-find'. Please add it to the deploy list for these classes of machines" or whatever else starts your change management system grinding.
Unfortunately that doesn't cut the mustard in most organisations either, with the typical responses being along the lines of: "Who will support it? Can you provide a security assessment? Is your team happy to be responsible for any issues?"
I sorely wish it was as simple as "please deploy", and in days of yesteryear you could probably get away with that either yourself or if you were friends with the linux team, but those days are over now as far as I see.
For context, my opinion comes from being a security consultant for over a decade - I see a lot of other people's environments and how their organisations handle requests like this. Not every environment will have objections, but most won't add it as a standard package across the fleet.
The Java tools predate the GNU convention (or at best were developed at the same time, unbeknownst to each other). Golang uses single-dash as well (but also accepts double-dash), as do PowerShell and Unix commands like find. In early Unix, there wasn’t a clear convention to use a dash for options at all (dd, tar, ps).
Personally, I dislike gnu style double dash and actively despise the double dash equals variant( --arg=value ). I just think it adds a lot of unnecessary noise to the command line.
And after a bit of shower thinking, you know that alone time with nothing better to do but ponder the mysteries of the universe, things like black holes, the nature of light and the ascetic of the command line. I decided that single dashes were also sort of ugly and hindered readability, but there was a better way as hinted by the single most screwball command in the standard unix installation.
Yes it is I ( evil laugh ), that misanthrope actively making new cli scripts what use dd style arg=value
Actually the real epiphany was when I was doing some work with "megacli" the tool for lsi hardware raid management. I noticed that sometimes I could forget to add a dash to an argument. A little experimentation showed that no arg actually required a dash and the capitalization was ignored. it was like a huge weight was lifted from my shoulders, much better this way.
Does MegaCli still ship with its own copy of libc5 because it's so old and disgusting that they can't bring themselves to upgrade it? Or did they figure out how to resolve that eventually?
No idea. megacli was always a weird program you had to sort sneak on the server however you could fit it. it got renamed to cmdtool at some point(I think because intel were shipping lsi cards). Honestly I am fairly happy we no longer use hardware raid here. Too many mysteries.
It's most common in Go's own tooling (e.g. `go build -buildmode`) but is also present in older tooling like e.g. GNU findutils (e.g. `find . -name something`).
The go tooling also has the irritating tendency to take a command like `go build --help` and say "oh, run `go help build` for details" instead of just printing out a list of possible options. Also: the details page doesn't always present you with a list of possible options, so you have to read each paragraph to see if there's an option relevant to your interests.
I find it helpful. If it's a program that generally supports single dash options only, having it respond to --help will falsely make me believe that it's one that expects double dash options.
Letting me know that the proper way to ask for help is `-help` also communicates that GNU style double dash long opts is not the way to go with this particular program.
Then I suppose you could argue that GNU style double dash options should be supported. Meh, I dunno. They were the ones that invented the fifteenth standard (xkcd/927).
I mean, it's perfectly fine if the way `--help` communicates that you shouldn't be using double-dash options is by... giving the help text that has all single dash options. That seems like pretty solid communication?
I don't care at all which type the program likes. I just can't remember which programs like which styles. So I ask them. And I prefer if they don't insult me when I do.
I just don't really see how that one, single, extra three second step is much to get upset about, and I think it's just welcome that it rubs me in the face that I got it wrong. It makes me not gloss over the help text and start double dashing my way into the next to command.
But sure, I see your point. I just wished K&R had had the forethought to establish a proper standard. I don't particularly care what it would have been.
And... before anybody points it out: When I wrote K&R, I obviously had a brain fart. I was thinking about Ken Thompson and Dennis Ritchie, but the acronym is of course normally used to refer to Brian Kernighan and Dennis. Sorry for any confusion :)
this works great on systems where programs are largely installed via package manager, but in plenty of environments is an unreasonable expectation. There's many many times I've gotten "no manual entry for $program" but there's extensive online help available in the program itself.
Expecting there to be a safe invokation for "how do I use this damn thing" is 100% fair.
$ e2scrub_all --help
e2scrub_all must be run as root
$ sudo e2scrub_all --help
[sudo] password for dan:
/usr/sbin/e2scrub_all: illegal option -- -
Usage: /usr/sbin/e2scrub_all [OPTIONS]
-n: Show what commands e2scrub_all would execute.
-r: Remove e2scrub snapshots.
-A: Scrub all ext[234] filesystems even if not mounted.
-V: Print version information and exit.
(Checking for being root before checking for --help is also frustrating)
Ansible's recommended install path is as a python pip package, which doesn't add manual pages. It's expected that to access the online documentation for ansible you fire off a ton of `ansible help topic` commands. `ipa`, the active-directory adjacent system published by IBM, also expects you to make heavy use of the `--help topic` pattern.
When manual pages exist they're wonderful and lovely. It's a good standard, and my favorite is when the online help system of a given script or installed package (e.g. via pip) emulates man--but there aren't always man pages
that's the entire point of my complaint here. It's unreliable in many contexts, but you do always have access to the command itself.
That is because Ansible documentation is generally poor. Ansible is one of the projects which i use every day and where the (online!) documentation rarely answers the questions i have. This forces me to fall back into a try & error that takes 10 times longer.
I genuinely can't tell if this is a joke or not. I've only _once_ in my life encountered a tool that didn't have `--help` support (and that was a script written by the worst coworker I've ever suffered), but plenty of times I've encountered tools that have no manpage entries.
Usage: /usr/bin/echo [SHORT-OPTION]... [STRING]...
or: /usr/bin/echo LONG-OPTION
Echo the STRING(s) to standard output.
-n do not output the trailing newline
etc.
I don't expect any such ugly shit. A call to echo should print its arguments, no exceptions.
NAME
echo - echo arguments
SYNOPSIS
echo [ arg ... ]
DESCRIPTION
Echo writes its arguments in order as a line on the standard
output file. It is mainly useful for producing diagnostics
in command files.
Exceptions to rules cause mental overhead and maintenance headaches. Why should `echo` be the single solitary tool that responds differently to invocation with `--help`?
For two reasons, both related to the Principle of Least Astonishment:
* Because the likelihood that someone entering `echo --help` _actually_ wants to print `--help` is staggeringly low
* Because it's not the "single solitary string" that has special handling - `echo -n` does not print `-n`. `echo` already supports flags, and so it would be most-consistent and least-surprising for it to also support a standard default one
"I got used to fish and vi mode which are not available when I ssh into servers, containers."
POSIX does mention vi mode as an optional feature.
"Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension. This option shall be supported if the system supports the User Portability Utilities option."
(The reason for this one seems to be that, in your CLI-parsing library, you have verbs that define what you want and flags that pass options to those verbs; 'show me the version' is a verb, so it can't be a flag instead. Without a verb, the program doesn't know what to do.
It's still infuriating, though, but at least it reduces the frequency with which -- is substituted for an em-dash (e.g. when sending commands to coworkers from your iPhone via Slack).
Iterm grabbed text highlit under mouse immediately for paste. Mac terminal. It's mac norms which means cmd-c
A very minor annoyance.
I dropped iterm to reduce my surface of dependency on complex systems. Somewhat confusingly un reductionist, xquartz and xterm would be the logical endpoint.
I have often thought it would be fun to have a Smalltalk like interaction screen, where you could leave snippets of code lying around and a “do it” menu item.
Kind of like how most of the SQL systems like dBeaver work. I have a scratchpad of SQL in a file I use for fiddly jobs, and a file like that for shell commands would be good if it had all the flags for awk or grep or whatever handy.
Would also be cool for the AWS and azure cli tools. I had something half working as an old VisualWorks experiment that implemented an AWS service on one side and a scratchpad in the middle but I feel like it might be a very cool vscode extension instead.
My biggest terminal frustration would be lack of access to Terminal. I have loved terminal windows since about 1981 or so. I was a big DOS fan and would only use Windows up until the Mac switched to OS X. I switched and never looked back.
Every day I use zsh on my Mac and bash on all the servers I use (almost all are Ubuntu).
My biggest peeve is the difficulty with formatting output in an elegant way when writing shell scripts. I have wrangled it for the most part, but all the solutions that I have found seem a bit janky.
Making command line tools at work really made me appreciate the work it takes to make a good one.
Do you have a good `--help`? Did you catch the common mistakes and return a helpful error message? Did you put reasonable defaults? Do you have enough examples on how to actually use it: not just one running example, but actually one that uses at least _some_ of the options.
Have you tried finding its path and looking into the file itself? Maybe it's a wrapper or alternative version somewhere in your $PATH you installed and forgot?
And to add some mor efor testing: you can try "find /help", "find /?" and "find -?", in case it's using dos-style parameters.
Is this MacOS? As I remember, they are using the tools from freebsd, and according to man-pages I randomly found on the internet it has indeed no help-parameter. I guess, their culture is to use "man" instead of flavors of --help.
Learning command line options is like learning hundreds of DSLs. It gets worse when you have to learn more, or different, sets for different platforms, like Linux vs MacOS.
Unices, by design, intend for you to compose many of these, so you not only need to learn the DSLs but you also have to learn the input and output formats, and learn even more DSLs to “glue” the commands together.
Finally, you need to learn yet another language (typically bash) to compose these together.
So using the CLI either slows productivity greatly as you have to look up everything, or requires years and years of time investment to become proficient, much of which investment is non-transferable.
I think that Microsoft PowerShell makes many of these problems much better, but aliasing for brevity re-introduces some of the toil involved, and afaict psh has not gained traction anywhere but Windows.
Powershell is so asinine I don’t know why you would bring it up unless you’re a blue badge crypto posting for Microsoft.
Do you want to talk about portability and transferability? It is the epitome of non-transferable and non-portable.
It is a domain specific shell language built for the Windows operating system win32 only. It does not work on Mac. It does not work on Linux. If you somehow managed to replace the Win32 shell with something else, it doesn’t work.
Bash or at least the shell script in UNIX has been going for 50 years. Power shell was shit out of Microsoft’s ass in 2007 and reached “usability” in 2013.
It broke compatibility with batch scripting, you have to call cmd to get batch scripts to behave. It broke compatibility with W scripting, or rather, justified to MS that abandoning script host was a worthy goal. It does not follow any of the same conventions as the Shell scripts and terminal commands that windows had used for decades at that point. If I want to accomplish something in powershell, I have to go look it up or I have to trust some command that somebody’s written on stack overflow will do what they say it does because I don’t have the time or the energy to go through and look up every single aspect of the command for a domain specific shell language that only works for a single operating system & that is worthless with any other system.
I spent probably about a decade of my life from 11 years old to 21 years old learning to use the Windows command line and W script.
To the degree that I literally automated myself out of my first tech job.
So therefore, my decade of time investment to become proficient with Windows scripting is non-transferable and Microsoft decided to throw it out.
If I had spent that time learning UNIX I would have been able to immediately go and use any other UNIX system and probably would’ve been able to get a much higher paying job at the start of my career.
The problem with shell scripts are that they are objectively badly designed. And I do mean objective--there is no reason to accept that "accidentally delete your home directory" is a sane default behavior for "oops I forgot to set a variable". Any project that attempts to make shell scripts not broken is, by design, going to have break compatibility, because compatibility is insane.
Powershell is interesting because it's attempting to introduce a different modality into shell scripts--rather than marshalling data as streams of bytes, you can actually represent the output as, well, data. So that a producer program can say "I'm outputting a list of files" and the consumer can actually handle it as a list of files and easily deal with the fact that maybe files have weird names like " ". A task that, for all the 50 years of experience on UNIX, still requires you to jump through hoops in every other shell script.
> If I had spent that time learning UNIX I would have been able to immediately go and use any other UNIX system and probably would’ve been able to get a much higher paying job at the start of my career.
You'd probably be on here complaining about systemd and iproute2.
Not transferable? In the context of the most widely-used server operating system? I have transferred Unix skills for decades, from one job and project to the next. Even Windows can run a Linux subsystem now.
Having learned Unix/Linux and many of the tools myself I challenge the "requires years and years of time investment to become proficient." You missed that the knowledge and skills grow incrementally, so while you get to proficiency your skills constantly improve at the same time. You don't have to stop everything, study Unix for years, and then go back to doing something "productive" once you've memorized it all.
Unix has one file format: plain text. The tools all compose around that. You can of course find exceptions -- you can't express everything in plain text -- but you can get remarkably far with simple single-purpose tools redirecting their output to the input of another tool.
The core tools have more consistency than you give them credit for, describing them as hundreds of DSLs. They all have man pages, they more or less follow the same conventions with I/O and flag names. Plenty of exceptions, sure, but no more than you find in any large legacy system that has grown and adapted over time.
I didn't realize until now how many problems I avoided by using Emacs and ansi-term (and usually tmux running in it). Stuff like struggling with color schemes or remembering key bindings... I just solved them once many years ago and don't even remember anymore how I did it. Same for copy and paste.
A lot of problems mentioned in the survey aren't really problems with the terminal, but, I guess, respondents didn't care about that kind of precision. Like... AWK syntax isn't a problem with terminals at all.
315 comments
[ 4.8 ms ] story [ 280 ms ] threadMany of the points raised point to real glitches, cruft, and frustrations with using the CLI. Those get more frustrating for people who only occasionally use the CLI, and less so for those of us who live in the shell.
Many of the same kinds of problems exist in GUIs. I rarely use Windows so when I do I can’t find or discover what I need.
Over time you remember the commands and flags, write aliases, set up config files, and mostly it becomes second nature.
That was an unnecessary spend then. You should ask yourself why ffmpeg still exists if if it's that hard to use. There's a plethora of simpler tools that exists for simple uses (handbrake, XLD,...). The truth is that if you want versality, there's no better than ffmpeg and it's core usage is relatively simple. It's an input | filter | output pipeline, with various options to fine tune each one. If you don't have the domain knowledge, it will be hard, just like a layman inside a plane cockpit. But if you do, everything makes sense.
Same with a lot of other software. There are bad design out there, but if something persists with no other incentive than its users, you should probably ask why first.
> why it can't be like
Here is another mistake: in many cases it be.
Me too, which was why I was very surprised when I discovered light switches in the USA worked backwards[0]. :D
(When I initially read your comment I didn't notice the use of "button" by which I guess you're referring to a push-button toggle style switch? But either way I still think light switches are an interesting example of non-obvious things that don't work the same way in all environments. (Even ignoring the "one light controlled by multiple switches" situation.))
----
[0] https://en.wikipedia.org/wiki/Light_switch#Orientation
Anyone can make their own tools if they have a better idea, and sometimes those take off and get adopted -- look at vim and now Neovim, rg (ripgrep), even Python pushing Perl and bash scripts out of the way. And plenty of people will call those things arcane too.
If you manage servers you know that RAM and disk space and other limitations have lots of relevance today. I'll quote you the next time my boss or customer asks me to explain a huge AWS bill.
If you don't like Unix or CLI tools, or don't want to spend the (admittedly signficant) effort to master them, no one will force you. I think the effort pays off. I have dodged more than one round of layoffs because I can work from the command line and keep legacy scripts and code working.
Dismiss or make fun of us "Unix ideologues" if you want, but I don't worry about losing my job or customers like my friends who have "mastered" VSCode pasting in LLM-generated snippets of React.
When I wrote "skills issue" I had in mind the mentality that equates learning the standard tools, mastering the environment, and always improving skills with a waste of time, a few minutes or hours diverted from pasting together API calls or prompting an LLM. I have watched programmers spend hours setting up color schemes and fonts in their IDE, and then complain that they can't remember a flag for grep.
Years ago I worked at a software company where everyone used the Eclipse IDE. I tried it but it felt too slow and buggy, so I fell back to my usual vim in the terminal. Every week or so the team came to a halt when Eclipse got an update to the Subversion SCM plugin (this happened before git took over). Eclipse would have a version of Subversion incompatible with the version on the servers, causing the team to stop to deal with that. I used svn from the command line, same version as the server, so I could keep working. Eclipse broke down so often I couldn't understand the team-wide devotion to it. And they made fun of my "arcane" and obsolete workflow. Now I work with teams who use VSCode and I see the same kind of thing play out -- plugin updates that break the whole environment, weird problems from the bowels of npm that no one can figure out. And they tell me they don't have time to learn vim.
Seems a bit harsh to call out the developers of all that software like that.
But I do agree that software interface design and empathy are both skills that many software developers might benefit from developing further.
In their defence, developers unfortunately often don't seem to have access to many resources for upskilling themselves in these areas either--people don't seem to realise that simply telling someone to, say, just "git gud" at empathy is actually a form of gate-keeping that doesn't really benefit anyone.
Admittedly, if I was feeling snarky I might be tempted to say being able to create software interfaces that may take a person from four to twenty-one or more years[0] to learn could be considered a "skill" of sorts, I guess, but that wouldn't be very empathetic of me.
----
[0] "40% of people answering this survey have been using the terminal for 21+ years / 95% of people answering the survey have been using the terminal for at least 4 years"
The people who wrote the shells and tools like vi(m) and awk didn't suffer from skills issues or lack of empathy. They wrote tools for themselves and other skilled programmers, in environments that no one under 50 can remember or imagine. Monochrome 80x24 displays, 8 MB of RAM, floppy disks (or worse) -- major hardware and software constraints. Blaming them for not anticipating modern hardware and software (and attention spans) seems like blaming Henry Ford for not inventing the electric Mustang.
I very much understood that's what you meant.
(And assumed you meant "skills issue" in the dismissive sense--if you didn't, ummm, feel free to skip to the last line of this comment, I guess...)
My comment was written in a manner to "humorously" imply I misinterpreted your comment as criticising presumably much older individuals rather than the actual intended targets of the criticism. This was in an attempt to prompt a possible reconsideration of the statement.
Seeing as I obviously failed in my attempt, let me restate my point less delicately but more clearly:
Unlike the tools from decades ago that can be & often are useful today--in spite of their less than perfect interfaces; attitudes that lead to shallow criticisms of people's skills are outdated, should be deprecated & removed from use--because such gate-keeping serves no useful purpose. In fact, it never did.
----
I mention this because I happen to care about our shared hobby/industry and those who have chosen to be part of it--because the technology is really fucking fun and/or fulfilling and/or frustrating.
And if the technology can be really fun why wouldn't I want as many people who are interested in it to have some of that fun? Or, heck, earn a living with making it less frustrating?
Humans are often already fantastic at self-critique of their skills--they don't need other people to shit on their skills too. (And I'm intentionally writing all this in case some of those humans are "in the room with us now".)
----
Besides, these survey respondents were primarily people who have stuck it out with our imperfect technologies for at least four to twenty or more years.
Not only were they prepared to admit that they didn't know something (something I personally find challenging to do, at times *cough*) they were kind enough to do so in the context of a survey that would help Julia Evans create an effective targeted resource to help people learn the very skills that are apparently of such importance!
----
I would also note, for example, one might consider it reasonable if only ~7-10% of people might know to use `cmd1 |& cmd2` for redirection of both stdout & stderr given it has apparently only existed since Bash v5.0, a mere six short years ago--and, coincidentally, probably one of my favourite Bash tips I've learned in the past five years because I could never seem to remember which order the `2>&1` went in--and seems maybe I wasn't the only one?
Why, if I was feeling petty, I might even point out that the existence of `|&` might even suggest that decades-old tools can in fact change their UI and that even complaining about bash might not just go nowhere.
Why, if I was feeling optimistic, I might even imagine that maybe attitudes can change!
----
On a definitely related & probably incredibly condescending sounding note:
What's a useful CLI tool tip you'd suggest would be valuable for people to know?
People actually frequently fail to self-critique their skills, leading to what we call the Dunning-Kruger Effect, the Expert Beginner, the 21-year-old "senior engineer." Listening to and learning from someone who has mastered a skill -- a mentor -- describes one of the best ways to learn something. Interpreting criticism as a personal insult, then blaming inanimate things like Unix CLI tools, doesn't seem productive or professional.
Calling command line tools poorly-designed, arcane, cryptic, etc. blames the tool, and perhaps by extension the author. I have managed to remember 0=stdin, 1=stdout, 2=stderr for decades, and I expect anyone who wants to get into programming can remember three file descriptors. If they can't remember those things, or look them up when necessary, and then blame the operating system or tool, what would you call that if not a skills issue?
As for the survey results that started this thread, I interpret them in the context of my own (40+ years) experience programming. Some people master the Unix CLI well enough to get things done with it. They appreciate the original intent of composability, "everything a file," plain text as the common format. Many other people have learned to type a few commands they don't understand, or copy and paste one-liners found online. Those people "use" the command line in the same sense that I "use" TurboTax -- infrequently and without motivation to master it. I have and continue to work with programmers who have a terminal window open all the time in their IDE, but can't actually do much with it. Then they get on threads like this to complain that command line flags "lack discoverability," as if the man tool didn't exist.
You can criticize what you perceive as my attitude. I have mentored and taught enough programmers how to improve their command line skills over the years to feel OK with myself when I tell complainers to stop blaming the tools. I got lucky early on and had mentors who taught me this stuff, the concepts and design behind Unix and its tools, and got me through my skills issues. Now when I run into something I don't understand I interpret it as my own skills issue, not as a sign that another programmer didn't know how to predict the future or didn't care about correct "design," as if that described anything real.
It's a good reminder to some of us that we are not in fact imposters.
I am aware that such a change would probably be 1000 times more complex to pull off than most people would think, but every time I have to explain to beginners they can't edit the text I die a little inside.
I am perfectly fine with having sent commands uneditable and responses uneditable as well.
Your second point is definitely my #1 issue, at least it is on Linux and Windows (macOS at least uses Cmd-c everywhere and it works.) I have to constantly remember to use ctrl-shift-c to copy in the terminal but ctrl-c to copy everywhere else, and I constantly forget and use ctrl-shift-c in a not-terminal program, and do something stupid like open dev tools in chrome, ugh. This is, unfortunately, not fixable. Not without rewriting every app on my system to use a different copy/paste combo.
What I want is to make a different shortcut trigger copy/paste, everywhere, and that’s not fixable. Every app independently decides to make ctrl-c implement copy, so changing that is basically not possible.
Though it's also possible to fix it everywhere - use a keyboard rebinding tool to make Ctrl-Shift-C send Ctrl-C key combo instead
That’s what I mean? Changing sigint’s shortcut isn’t what I want to do.
> Ctrl-Shift-C send Ctrl-C key combo instead
Then ctrl-shift-C will send SIGINT too, and I’m back to where I started (SIGINT and copy having the same shortcut)
I'm sorry, I thought there might've been some confusion re. actual sigint definition based on some deeper history and ASCII codes (which didn't seem like it from cursory search)
> ctrl-shift-C will send SIGINT
You filter against your terminal app, where Ctrl+Shift+C will continue send Ctrl+Shift+C
This was so good experience for me, that I reconfigured my Linux terminal to have Win+C, Win+V and Win+T (for new tab). However this is inconsistent with Linux window management. Since then I have been actively looking for a way to change the Linux OS manager to have default global hotkeys in the MacOS style. Anybody knows how to do that? ( https://news.ycombinator.com/item?id=41439601 - suggested xmodmap is a key mapping way which will break my CTRL+C in terminal )
Please write:
and insert the missing number without deleting the already existing numbers in a vanilla (non-emacs, non-vim) terminal. In nearly every other editable text field people know well in their lived (including the one you typed in for this comment) you can move your cursor to the middle of a sentence and insert text with a mouse click or the left/right arrow key.And before someone suggest some option to enable this: my comment was about changing the defaults.
[0]: https://readline.kablamo.org/emacs.html
Some terminals also support mouse navigation, so keep an eye out for that as well.
I'm sorry that you've been dealing with this frustration for so long and under the impression that it was just supposed to be that way and not fixable. The good news is that it's NOT supposed to be that frustrating and you CAN fix it
Edit: you edited your comment somewhere between my first seeing it and my reply posting. I haven't had to modify the default settings on my terminal to fix things like this in about 20 years. I've changed them to tweak various preferences like scrollback, cursor shape/size, etc. But arrow navigation has worked out of the box for me for so long that I literally can't remember when I last had to fix it. I don't know why our experiences have been so different, but I'm sorry that a tool that has been so useful for me has been so frustrating for you.
Old enough terminal or old enough host, sure, there can be some fighting involved. Of course, working in those conditions, sometimes backspace doesn't work either and you have to hit ctrl-H like an animal.
But I haven't had issues with that lately.
If arrow keys not working for you, install a new distro.
2. What's "normal"? Do you mean CUA-style navigation? In that case, absolutely, no effing way! These keybindings are awful. And it's good that they are awful. It wouldn't be a good idea to often accidentally press C-c and kill whatever thing you are working with. But, it's not a convenient key chord for an operation as common as "copy". Now, you may say "in addition to already existing text editing key bindings": but then, again, no, because I want these keys for rare and dangerous operations. I don't want them to be duplicates of existing and better functionality.
NB. Both of your improvements aren't about terminals. They are about programs run by terminals (eg. shells). But you probably knew that already. I realize that OP and the comments lump all these tools together under the same label. But it's still worth pointing out that these are separate issues at least in the sense that nothing you can do to the terminal will effect the change you want to see.
https://news.ycombinator.com/item?id=42970632
https://news.ycombinator.com/item?id=42975816
https://news.ycombinator.com/item?id=42959824
https://news.ycombinator.com/item?id=42953869
That's generally how question asking goes...
if it's, say, a chrome extension someone whipped up that makes it a button click to generate, or a script someone handcrafted, or somone had an LLM generate, or a fully automated bot doing it off a Cron job, or a billionaire is paying a human in the Philippines to do it by hand, some SV startup millionaire is bored with life and spends too much time here, a college student that has some free time between classes... the end result is a relatively simple post linking back to previous threads.
in what manner does having a human in the loop for that specific post affect your broader feelings about this site?
For documentation context switches (e.g. stackexchange/googling) : install tldr, fabric , devdocs, sdk docs etc . And get comfortable searching man pages with “/“ and man -K
For job/task context switching (e.g. running multiple jobs like a transfer job and a measure-status job), get familiar with bash job control or tmux
For history context switching (e.g. re-running an old command) , set a long history like HISTFILESIZE=100000 and use ctrl-r. If you ever run out of history, make it bigger . Also dump helpful commands into a README.md with echo COMMAND ARG1 ARG2… >> README.md . Fzf is also helpful.
For context-switches stemming from missing settings / dot files, set up “dotfiles bare git repo”. You can push this repo around with SSH, so every fresh machine will have your settings on first login.
The challenges in her survey are common, and I wish shells did better user onboarding and tutorials, the way games and consumer apps do. But each one can be addressed with the right preparation.
If you use the terminal for any appreciable amount of time I heavily suggest getting fzf (even if just for the search).
Tmux is great if you need any more than 1 terminal window open at once - just remap some of its hotkeys to stuff that make more sense for you (e.g. I use "Alt + |" to split vertically and "Alt + -" (minus) to split horizontally).
Man pages are generally about 500 times longer than I need them to be (just help me do a basic curl/SSH copy/... please) - so I have cheat.sh aliased which helps a lot with simple "how do I use X".
Aliases in general are insanely useful. If you're a fzf search whiz they may not help you as much but seeing people type common commands out multiple times a day... makes me happy knowing I have my alias bank.
Nice tip! While I don't mind the default Tmux keybindings (<prefix> " and prefix % for horizontal and vertical splits), one thing that used to annoy me early on was how new panes would default to the directory where Tmux was originally launched, rather than inheriting the current working directory. Fortunately it was easy to fix with a few lines of code in ~/.tmux.conf:
This ensures that while splitting a pane with <prefix> " or <prefix> %, or while creating a new window with <prefix> c, the new shell inherits the working directory of the previous pane. This small tweak saved me countless unnecessary "cd" commands.Not just current dir, but the whole env:
Then another unrelated terminal:[1]: https://andrew-quinn.me/fzf
Ended up creating a GUI app called Lightkeeper (https://github.com/kalaksi/lightkeeper). Works over SSH, requires no daemons and is configurable. Still working on some unfinished features.
This is very true.
It was made by people who don't know how to use existing tools and what the actual problems are. It's like people who keep creating "new" text editors, but they never learned well how to use existing ones. So they end up with crippled half-baked thing that's some concept from the 80s that was discovered to be a dead-end in the 90s, but with modern cosmetics.
PowerShell is just incompetence and hubris of people working for a large company which can push their random garbage software on a lot of users and developers due to having huge market presence.
(curl http://localhost:5555/log | grep -o -E "2025[0-9-]+")
or this (ps ax | grep ffmpeg) Maybe it's good for scripting (why not python then?) but really sucks when you need to get things done in terminal.Auto complete is quite good though.
The way to write that on the command line Powershell would be:
Whereas your longer example is what you put in the PS1 file.It also has positional parameters meaning you don't have to specify parameter names, though you might as well because tab completion is a thing. And if you're really keen on not using tab completion, it autocompletes parameter names for you meaning "get-help man -e" is equivalent to "get-help man -examples".
Here are less verbose posh commands for your examples.
Still arguably a mess. Select-string not having a -o equivalent parameter is a big gripe of mine. Get-Process has a name parameter. Why not use it?Edit:
I should have added, curl ships with Windows now so a farer comparison would be a select-string on curl.exe.
We want modern (and by that they mean C#-like) programming language in shell. We want user types, type checking, structured, modular code.
And they forget that the reason Unix shell is easy in some respects is precisely because it has none of that. Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells.
Structure will require a lot more operations for composing and decomposing it in order to transmit messages. Equality and identity become a problem.
Custom types are similar to structure, but on top of it present a problem with serialization (somehow both shells need to have same type definitions, and what happens if they inevitably don't).
The problems above not being addressed... what you get is another "scripting" language, of which there are already dozens, with no special benefits when it comes to it being used as shell, but with some problems. Just not worth it and illustrates lack of research and understanding of the problem space on the part of the authors.
Serialization is trivial in PowerShell but also much more powerful because you can pipe the output of any command to ConvertTo-JSON or ConvertTo-CliXML which gives you very nice STRUCTURED serialization that is much easier to consume.
There isn't really. For a lot of PowerShell objects, there's no way of converting them to JSON or XML. Imagine what happens if you convert a closure to JSON? It doesn't matter what language you use, it's always going to be a problem.
You are simply too inexperienced with the subject to be able to have a judgement on how (well) it works.
Trust me, it's anything but "trivial".
objects are piped instead of text. This single change makes a ridiculously huge improvement. You are no longer forced to perform incredibly tedious and fragile text manipulation. This also enables filtering on property names and the ConvertTo-JSON command which is amazingly useful.
https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
The problem with any terminal replacement is that you have to support all existing terminal applications. If you don't, then your replacement is going to be useless for half a century until everything gets re-implemented and installed everywhere (and this is assuming you can get buy-in from everyone on this speculative 50 year investment). If you do, then congratulations, you have all of the legacy terminal baggage.
ymmv but I prefer this to searching.
1. As mentioned above, scope awareness when searching history. This can be exceptionally helpful when you know you’re in the same directory where you previously ran a command.
2. Sync - this is why I started with atuin. It’s pretty easy to run your own sync server if you’re not big on send your commands to some random server somewhere.
3. Persistence - similar to sync, I love having my whole command history available when I stand up a new machine.
4. Secrets hidden - you can even set it so secrets are not persisted in your history. This is useful if you haven’t yet migrated to using something 1Password to inject secrets. Also, as a side, it makes it really easy to find secret references you’ve used before too.
Thank you for the kind words! Glad you find Atuin useful!
> It’s pretty easy to run your own sync server if you’re not big on send your commands to some random server somewhere.
We always intended to keep it easy to run a sync server! But also fwiw, sync is e2e encrypted, so we can't actually see anyone's commands
> How difficult it is to learn independently. Most of what I know is an assorted collection of stuff I’ve been told by random people over the years.
This is all too true, the discoverability aspect is one of the reasons why we exist (0), and there is lots to improve here for discovering terminal tools, how to install and use them.
Also thanks for running this survey Julia.
Also, let us know on what we can improve on the site if you find Terminal Trove useful for you.
(0) https://terminaltrove.com/
We have categorization here:
https://terminaltrove.com/categories/
Is there anything we can improve here that can make this easier for you?
We will consider searching on the website, what would you search by or search for if this feature existed?
No OP but it would be nice to include link to categories in the header bar. It would make it easier. the dynamic animation of the categorizes at the middle of the page is annoying. You have it in very small font in the footer but this isn't the best.
I would suggest a few things -
1. Less resource intensive site - I’m on my phone, and it took probably 5 seconds to load the front page, and then to actually get to the list, it took a few seconds more. I do not have a current gen phone, but I’d hazard a guess that my phone is about average in age as far as the potential user-base for this site goes! Do not discount mobile users, especially for a site focusing on CLI applications.
2. Maybe I care what language a CLI utility is written in sometimes (Albeit, I can’t recall a time when I have). I’d add a search in the front page, if well thought out. Or, honestly, I’d just have the front page be the list. People are great at lists, and generally quite good at reading, and your list has very well-written descriptions.
3. Kinda related to the above, but I think the categories view is effectively useless. The categories already appear in the description (and if they don’t, they probably should) - so why not just skip straight to the list? You could add a filter for the list if you want. Or, even better - a simple search box!
I’m only giving these criticisms as a means to (subjectively) improve your site, because overall I think it is very well done and thoughtful, without a lot of fluff. There are hundreds more I’d not have criticized, but only because they felt like a waste of time and dead weight. Keep up the good work!
* ipython/prompt_toolkit (https://github.com/prompt-toolkit/python-prompt-toolkit),
* chalk (https://github.com/chalk/chalk),
* linenose (https://github.com/antirez/linenoise), and
* plenty of other random programs.
Please, let's just stop doing things this way. I understand that talking to libterminfo is annoying, but it produces a better result for everyone than everyone maintaining obsolete and incomplete databases mapping TERM values to capabilities.
That's not to say libterminfo is great either: we got into this mess partly because for (IIRC) ~10 years or so, the ncurses people stopped updating the terminal database with information about new capabilities like bracketed paste and 256 color support, forcing authors of programs wanting to use these features into using dirty hacks to detect or configure support --- and everyone has a different dirty hack!
Also, terminfo in inconvenient when jumping between machines. Who among kitty users, for example, has never experienced weirdness after ssh because the target machine doesn't have a terminfo file for "xterm-kitty"?
To fix this mess, we need to:
1. Define a new cross-terminal-emulator OSC sequence that instructs the terminal emulator to echo back THE WHOLE TERMINFO CAPABILITY STRING, in-band. No "user agent sniffing" with TERM. We detect features directly from now on.
2. Stop hard-coding random "ANSI" escapes. Use a library. Ask that library, "What does this terminal support? What strings do I use to accomplish what I want?" and then use it.
3. By default, don't output escape codes if output isn't a tty.
(#2 (by recognizing TERM=dumb) and #3 (because pipes) also address the problem of escape sequences ending up in the middle of output files and shell pipelines.
The terminal world is a mess right now. Continuing to live in squalor is a choice.
Unfortunately due to the progression of technology and education, a lot of foundational knowledge is not being learned. Terminals are probably one of the biggest losers in this area. Even many technically knowledgeable people only know of terminals as "that box that pops up where you can type commands". They cargo cult/copy-paste the common escape sequences. Most things work "good enough" now that they never have any reason to learn more.
XTGETTCAP does that (kindof), it's implemented by xterm, kitty, and foot.
xterm allows querying keyboard caps, plus a few others
kitty adds to that querying all integer and string caps
foot adds to that bools caps, meaning in foot you can query all of terminfo via it.
what we need to do is bring other terminal emulators up to par with foot's XTGETTCAP, and then we can finally ditch libterminfo for good.
Oh, cool. Agreed we need to bring other terminal emulators up to speed. I might as well do Emacs's.
[0]: https://www.man7.org/linux/man-pages/man3/isatty.3.html
* cht.sh is a great way to avoid a lot of this stuff - there's a commandline tool as well
* usable cli ai setup: simonw's llm (https://github.com/simonw/llm) + openrouter (https://github.com/simonw/llm-openrouter) + free models (https://openrouter.ai/models?max_price=0) + glow (https://github.com/charmbracelet/glow) + adding this to your .rc file:
Here's an example, Now for a sophisticated use-case I have a small tmux program where I can capture what's on the pane, enter a prompt and it will query an llm so I can say things like "How do I fix this error" or "what debian package do I need to get this to run right?" ... both these are recent patterns I've started and they've been real game changersSome lesser game-changers:
* tmux extrakto - opens an "fzf" like search of all the text on the screen. So after a "git status", I can do git add (run extracto - enter partial path, press tab) and continue: https://github.com/laktak/extrakto
* mcfly history: https://github.com/cantino/mcfly just watch the demo, you'll see
* ugrep: grep with a powerful tui: https://github.com/Genivia/ugrep - I became an instant convert.
* batcat: https://github.com/sharkdp/bat ... you really need to use some of its other features to leverage it. It's really nice.
https://github.com/regnull/how.sh
I think the real sweet-spot flow is to take this and use bindkey to do inline replacement. Let me fork it and see what I can do.
It's a re-invention really.
Essentially you do (assuming zsh)
Then you type your thing at the shell Then you (in the default, CTRL+X+H) and it does this Then you can choose to press enter and run it.https://github.com/kristopolous/how.sh
This is a much more one-and-done approach but 99% of the time I just forget invocation syntax - I'm not actually exploring things deeply.
If you want a "proper" pr, it'd really be a rewrite with two "frontends" - your conversational edit flow and my keystroke invoke.
Honestly they're probably different things.
Here's the prompt engineering I did: https://github.com/ddworken/hishtory/blob/master/shared/ai/a...
Nice to see there's so many options these days. Someone else mentioned "https://atuin.sh/" in this thread - which is also new to me. Keeping up with things is seemingly impossible
honestly, with these modern systems this shouldn't be a problem any more. I look forward to it.
It features an integration with the abbreviation feature in fish and zsh (via plugin) to expand the suggestions for editing, if needed, and execution.
There's stdin support, which can be used to pipe in error messages, for example. I've thought about something like your tmux setup to capture and pass some history to the model, but in practice redirecting stderr handles most of the potential use case.
Was this a real example of the input and output generated, because it seems wrong.
-L 7001:localhost:5050 listens on port 7001 locally and forwards connections to 5050 on the remote host.
Based on the request, you want -R 5050:localhost:7001, which listens on port 5050 at the remote end and forwards connections to a server listening on localhost:7001 on the local end.
Has configs for multiple programs, is warm (low blue light), avoids too many colors / clown vomit
I was considering giving up on colors with zenbones before I found this
For copy/paste I'm using a 36 key keyboard, ctrl is on a thumb key hold, while holding , is shift-ctrl. But that's probably not as generally useful to others
I've said it before and I'll say it again: the error "Option `--help` not understood, did you mean `-help`? Use `-help` to display program options." is one of the most insulting things a program can say to me. `--help` is the lowest common denominator. You have to support it. I don't care what your program has to special case in its parsing, just do it. If I knew your program's preferred syntax, I wouldn't be asking it for help.
But asking for `--help` is unambiguous, and is in fact the lowest common denominator way to be explicit about it.
a) use bash-like behaviour of an unmatched glob turning into a bare word, e.g with zsh have `setopt NULL_GLOB`.
AND
b) don't have a file named, say, `-a` in the current working directory.
Try this:
The common denominator for getting help would be man(1).That's... not what a common denominator means. It's far easier to check for `--help` or `-h` and print _something_ than write a whole document in a weird markup language for man.
man(1) is, provided that people produce man pages. It's also orthogonal and composable without interference: one can write a man page for commands that don't have man pages.
Flags are not, because commands parse their arguments in whatever way; all commands can accept arguments but arguments are also part of the operational interface contract. man(1) is decoupling all possible problems out.
It is also extremely obvious than `man foo` is side-effect free, whereas `foo whatever`, whether `whatever` can be `--help` or anything else, has unknown effects when the command is unknown.
Some argue that man pages are too rich; well the man pages can just also start with a summary identical to what a hypothetical `--help` flag would output.
Turns out this is the conventional `SYNOPSYS` title of section 1 man pages, and possibly the `OPTIONS` one; if these are absent or badly written then one could reasonably posit that a hypothetical `--help` flag output would be just as unhelpful; cue the wads of commands that "--helpfully" output `foo [-4236xXksirtTgsdv]` as help, which tells you nothing really helpful.
`info(1)` can burn in hell though.
These days, I'm positively surprised when I find man pages for a program, whereas I'm annoyed when one doesn't support --help.
They're absolutely trivial to generate these days, gone are the days of having to deal with roff, you can write a quite dumb markdown file and produce a man page out of it in short order.
https://github.com/sunaku/md2man/blob/master/EXAMPLE.markdow...
https://github.com/rtomayko/ronn/blob/master/man/ronn-format...
There are people arguing that? My feeling is that man pages are usually so thin as to be useless in 50%+ scenarios I need them. I really wished the culture defaulted to expecting all software to come with Info pages.
Rather:
b) don't have a file with a single letter name in your CWD, like `a`
Try this:
And yes, it's even more damning; you don't generally find legitimate files named `-a` or similar - rather, it's clear indication of someone invoking some CLI command wrong (`cp` comes to mind). However, single-letter files and folders are a relatively frequent thing to see.I don't see it. What are you trying to show with 'a' instead of '-l'? Why would a file named 'a' interact with a glob like '-?'?
'?' is glob for one character, '-?' means "dash followed by any character", and that's what I'd expect to be matched, and that's what my `ls` does.
but `a` is not "dash followed by one character" so the glob does not match a `a` file?
my haha nearby was wrong! I should have tested it :)
Normally, ls doesn't expand globs.
Why did you say to try "touch a; ls -?"? What am I supposed to see from those two commands?
If you already know the content, but accidentally made a typo and are trying to debug it, then reading the documentation isn't going to help. An error message pointing out the problem will help.
And at high levels, a referee role is probably similar to physician/lawyer where you'll have annual rule updates/changes, jurisprudence history of past rulings, and conventions/associations of referees where they will be spending money, time and effort when not on the field.
Now multiply the referee's game or league types by everything in /usr/bin
--help being an incorrect argument does the right thing, yes.
This is especially useful in situations where the help text is enormous (dozens and dozens of options).
MariaDB also doesn't print the entire manual when it goes "syntax error at ' OR 1=1". It makes no sense.
You can include "See --help for more information" at the end of every error to make sure everyone knows where to find that, though, since indeed not every program uses the same syntax for usage. 90% of the time I don't need a copy of a program's manual in my scrollback when I, say ,typo something or forgot that two options are incompatible. There is a reason scrollback exists and I use it for that purpose. I'll look up the manual or run --help in another terminal tab/window, or choose to run it in the current one at my own discretion thank you
Genuinely my least favorite thing in the terminal is when I forget some detail about... usually CURL, since they use the capitals AND the lowercase letter arguments for very different things. So I end up having to use the / command in `less` to search for some common word for 3-5 minutes because the manpage is so disorganized. We have a much better tool than the Terminal for viewing long-form text content, so maybe I just need to alias `man` to open a website that publishes manpages.
I don't care how it's done. Heck, dump the help if you see any option with two dashes, if you're offended about long options. I don't care what other things dump help out too as long as --help does. But both -h and --help should always produce help, no matter what, no matter where you are, and I'd really like -help too, even if that is a bit more complicated. Though since I also want "a -h or a --help in the parameter list reliably makes it so that help is printed and NOTHING ELSE happens", "-help" should generally work as "-h" and "extra stuff that won't happen because -h is in play". It is an error for a program to both print the help and take any other action; should always do one XOR the other.
How about non English speakers who might be inclined to type —ayuda or something?
In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.
> What about programs with such simple CLIs that they don’t have help?
It is crapware
> about non English speakers who might be inclined to type —ayuda or something?
Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”?
That is just ridiculous! Please stop!
I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
My Knowledge come from some archaic Sun manual. I wanted to find it, and everywhere it says print… I had it wrong.
Anyway the idea is to show that translating is always partial, ans a full translation would be a titanic and unproductive work.
I’m a native speaker of a couple of languages, and learned some more. So i have used computers in many languages. I hate command line translations, all are bad.
I’m BSD and Solaris guy, but when I’m in linux, I spect linux. It should be part of PORTING a program, if the option is not supported.
Short-circuit any typo may be dangerous.
Now, an argument can be made for including as many aliases for "help" and "version" as possible but that's a different story
So it's often not the case that a single person who made the decision to have a message that says "you asked for help, but you did it wrong; before I give you help you have to ask correctly."
>> aim wand at perodactyl
> I see no perodactyl here.
>> aim wand at pterodacyl
> I see no pterodacyl here.
Frustrated at my continuing mistakes, I decided to try to short-circuit their logic. Despite knowing the difference, I typed this:
> aim wand at bird
And the game replied:
> a pterodactyl is not a bird
My entire Linux experience is dictated by what’s installed by default on rhel and/or ubuntu.
I sorely wish it was as simple as "please deploy", and in days of yesteryear you could probably get away with that either yourself or if you were friends with the linux team, but those days are over now as far as I see.
For context, my opinion comes from being a security consultant for over a decade - I see a lot of other people's environments and how their organisations handle requests like this. Not every environment will have objections, but most won't add it as a standard package across the fleet.
Java was already two years in development at that time.
And after a bit of shower thinking, you know that alone time with nothing better to do but ponder the mysteries of the universe, things like black holes, the nature of light and the ascetic of the command line. I decided that single dashes were also sort of ugly and hindered readability, but there was a better way as hinted by the single most screwball command in the standard unix installation.
Yes it is I ( evil laugh ), that misanthrope actively making new cli scripts what use dd style arg=value
http://nl1.outband.net/extra/remv.txt
Actually the real epiphany was when I was doing some work with "megacli" the tool for lsi hardware raid management. I noticed that sometimes I could forget to add a dash to an argument. A little experimentation showed that no arg actually required a dash and the capitalization was ignored. it was like a huge weight was lifted from my shoulders, much better this way.
Likely inspired by JCL syntax!
https://en.wikipedia.org/wiki/Dd_(Unix)#History
The go tooling also has the irritating tendency to take a command like `go build --help` and say "oh, run `go help build` for details" instead of just printing out a list of possible options. Also: the details page doesn't always present you with a list of possible options, so you have to read each paragraph to see if there's an option relevant to your interests.
Letting me know that the proper way to ask for help is `-help` also communicates that GNU style double dash long opts is not the way to go with this particular program.
Then I suppose you could argue that GNU style double dash options should be supported. Meh, I dunno. They were the ones that invented the fifteenth standard (xkcd/927).
I don't care at all which type the program likes. I just can't remember which programs like which styles. So I ask them. And I prefer if they don't insult me when I do.
I just don't really see how that one, single, extra three second step is much to get upset about, and I think it's just welcome that it rubs me in the face that I got it wrong. It makes me not gloss over the help text and start double dashing my way into the next to command.
But sure, I see your point. I just wished K&R had had the forethought to establish a proper standard. I don't particularly care what it would have been.
Expecting there to be a safe invokation for "how do I use this damn thing" is 100% fair.
Are you on debian? Do an `/usr/sbin/e2scrub_all --help`.
When manual pages exist they're wonderful and lovely. It's a good standard, and my favorite is when the online help system of a given script or installed package (e.g. via pip) emulates man--but there aren't always man pages
that's the entire point of my complaint here. It's unreliable in many contexts, but you do always have access to the command itself.
Never heard of echo? What do you expect this to do?
https://www.man7.org/linux/man-pages/man1/echo.1.html
Some programs give a short help message when options are not understood. A good thing.
That said, in GNU/Linux a program that does not have --help is shitware.
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/
"I got used to fish and vi mode which are not available when I ssh into servers, containers."
POSIX does mention vi mode as an optional feature.
"Allow shell command line editing using the built-in vi editor. Enabling vi mode shall disable any other command line editing mode provided as an implementation extension. This option shall be supported if the system supports the User Portability Utilities option."
`cmd --help`
Error: option - not understood. Use `cmd -h` for help.
Or this pattern that we find everywhere in golang-written tools:
$ helm --version
Error: unknown flag: --version
$ helm version
version.BuildInfo{Version:"v3.17.0", GitCommit:"301108edc7ac2a8ba79e4ebf5701b0b6ce6a31e4", GitTreeState:"clean", GoVersion:"go1.23.4"}
(The reason for this one seems to be that, in your CLI-parsing library, you have verbs that define what you want and flags that pass options to those verbs; 'show me the version' is a verb, so it can't be a flag instead. Without a verb, the program doesn't know what to do.
It's still infuriating, though, but at least it reduces the frequency with which -- is substituted for an em-dash (e.g. when sending commands to coworkers from your iPhone via Slack).
A very minor annoyance.
I dropped iterm to reduce my surface of dependency on complex systems. Somewhat confusingly un reductionist, xquartz and xterm would be the logical endpoint.
Kind of like how most of the SQL systems like dBeaver work. I have a scratchpad of SQL in a file I use for fiddly jobs, and a file like that for shell commands would be good if it had all the flags for awk or grep or whatever handy.
Would also be cool for the AWS and azure cli tools. I had something half working as an old VisualWorks experiment that implemented an AWS service on one side and a scratchpad in the middle but I feel like it might be a very cool vscode extension instead.
Every day I use zsh on my Mac and bash on all the servers I use (almost all are Ubuntu).
My biggest peeve is the difficulty with formatting output in an elegant way when writing shell scripts. I have wrangled it for the most part, but all the solutions that I have found seem a bit janky.
Do you have a good `--help`? Did you catch the common mistakes and return a helpful error message? Did you put reasonable defaults? Do you have enough examples on how to actually use it: not just one running example, but actually one that uses at least _some_ of the options.
Your UX instincts do get tested in this.
And to add some mor efor testing: you can try "find /help", "find /?" and "find -?", in case it's using dos-style parameters.
On my system Ubuntu 24.04:
You could also think about sitting at a train station trying to code, or that feel when you lick a battery
[1] https://github.com/sharkdp/vivid
Unices, by design, intend for you to compose many of these, so you not only need to learn the DSLs but you also have to learn the input and output formats, and learn even more DSLs to “glue” the commands together.
Finally, you need to learn yet another language (typically bash) to compose these together.
So using the CLI either slows productivity greatly as you have to look up everything, or requires years and years of time investment to become proficient, much of which investment is non-transferable.
I think that Microsoft PowerShell makes many of these problems much better, but aliasing for brevity re-introduces some of the toil involved, and afaict psh has not gained traction anywhere but Windows.
Do you want to talk about portability and transferability? It is the epitome of non-transferable and non-portable.
It is a domain specific shell language built for the Windows operating system win32 only. It does not work on Mac. It does not work on Linux. If you somehow managed to replace the Win32 shell with something else, it doesn’t work.
Bash or at least the shell script in UNIX has been going for 50 years. Power shell was shit out of Microsoft’s ass in 2007 and reached “usability” in 2013.
It broke compatibility with batch scripting, you have to call cmd to get batch scripts to behave. It broke compatibility with W scripting, or rather, justified to MS that abandoning script host was a worthy goal. It does not follow any of the same conventions as the Shell scripts and terminal commands that windows had used for decades at that point. If I want to accomplish something in powershell, I have to go look it up or I have to trust some command that somebody’s written on stack overflow will do what they say it does because I don’t have the time or the energy to go through and look up every single aspect of the command for a domain specific shell language that only works for a single operating system & that is worthless with any other system.
I spent probably about a decade of my life from 11 years old to 21 years old learning to use the Windows command line and W script.
To the degree that I literally automated myself out of my first tech job.
So therefore, my decade of time investment to become proficient with Windows scripting is non-transferable and Microsoft decided to throw it out.
If I had spent that time learning UNIX I would have been able to immediately go and use any other UNIX system and probably would’ve been able to get a much higher paying job at the start of my career.
https://learn.microsoft.com/en-us/powershell/scripting/insta...
Powershell is interesting because it's attempting to introduce a different modality into shell scripts--rather than marshalling data as streams of bytes, you can actually represent the output as, well, data. So that a producer program can say "I'm outputting a list of files" and the consumer can actually handle it as a list of files and easily deal with the fact that maybe files have weird names like " ". A task that, for all the 50 years of experience on UNIX, still requires you to jump through hoops in every other shell script.
You'd probably be on here complaining about systemd and iproute2.
Having learned Unix/Linux and many of the tools myself I challenge the "requires years and years of time investment to become proficient." You missed that the knowledge and skills grow incrementally, so while you get to proficiency your skills constantly improve at the same time. You don't have to stop everything, study Unix for years, and then go back to doing something "productive" once you've memorized it all.
Unix has one file format: plain text. The tools all compose around that. You can of course find exceptions -- you can't express everything in plain text -- but you can get remarkably far with simple single-purpose tools redirecting their output to the input of another tool.
The core tools have more consistency than you give them credit for, describing them as hundreds of DSLs. They all have man pages, they more or less follow the same conventions with I/O and flag names. Plenty of exceptions, sure, but no more than you find in any large legacy system that has grown and adapted over time.
A lot of problems mentioned in the survey aren't really problems with the terminal, but, I guess, respondents didn't care about that kind of precision. Like... AWK syntax isn't a problem with terminals at all.