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.

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

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

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

Amen!

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.

Don't forget when a program only accepts short-form arguments:

`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).

Or database clients (e.g. psql) using `-h` for the host argument. I get it, but I don't like it.

POSIX doesn't have any of that.

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

Agreed, but to be fair some of that comes from fuzzy searching the available parameters for close matches. Which is normally helpful.

Its not "$command --help", its "man 1 $command". You should not invoke programs blindly, hoping "--help" causes them to do nothing else.

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

Just print help instead of any error during parsing

Works well because almost all interaction is low-bandwidth low-latency duplex text streams. You can make a lot of assumptions based on that.

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!

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

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.

I find the history much too unorganized to be useful. That's why I made playbooks https://github.com/laktak/tome

ymmv but I prefer this to searching.

Same

I don't remember if I did any special config in iTerm or installed a nonstandard package (I don't believe I did), but in Mac I often find it easier to just pipe a result I want copied into the `pbcopy` command in order to capture it in the clipboard, rather than trying to highlight what may be a long output.

Then how do you SIGINT?

sounds like Pharo

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

Here's my take on an LLM based shell helper for command suggestions and more: https://github.com/scottyeager/Pal

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.

I did a similar thing, where you describe what you want to achieve and it gives you the command and (optionally) executes it for you:

https://github.com/regnull/how.sh

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.

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.

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!

[0]: https://www.man7.org/linux/man-pages/man3/isatty.3.html

Saving others a click: it syncs terminal history between systems

How does this help to memorize syntax if you repeatedly use the same commands?

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.

> A good catalog of mostly skills issues.

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"

> A good catalog of mostly skills issues.

It's a good reminder to some of us that we are not in fact imposters.

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

Where is that the case? Middle click copies the selection and right click pastes on every terminal emulator I use.

This does not work in a vertically split window inside a tmux session, for example. (Same with split buffers in vim, and so on.)

I think it was more common until Apple normalized the one button mouse.

What if you can't use the mouse?

Detector seems a bit off when it also includes the item-id where it's posting.

Is this a bot?

You have a manky version or an alias over find somewhere.

On my system Ubuntu 24.04:

  $ find --version
  find (GNU findutils) 4.9.0
  $ find --help
  works
  $ find -help
  works
  $ man find
  then /help works

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.

Thanks for the tip, another awesome tool from sharkdp.

P.S. dont blame bash for sed. Once you grok bash, other tools make more sense. If you don't understand bashes escaping rules and options

echo x | sed "..."

Is doubly confusing.

> But it is weird that we stick with these being emulators for stuff most people here would never have touched in their life because they are not at retirement age yet.

It's a standard that works, keeps a massive trove of software from being obsolete, and gives you backwards compatibility for free.

Case in point, I recently installed Gentoo on my desktop from a VT320 terminal given to me by a friend. After a simple config line to tell the init system to put a shell on my serial port with the right options, I was working with modern Linux tools in 2025 on hardware from 1987.

https://jimm.horse/img/vt320.jpg

It's a testament to the value of maintaining standards and emulation that this terminal can be saved from e-waste. Everything mostly "just worked" once I got the TERM/environment set up right. Oddly seems like you need to set options to vt300, not vt320, for the best compatibility.

It's a joy to use. The keyboard feels very nice to type on, very good for rubber dome. The amber light is easy on the eyes. I find working on the terminal makes me less prone to distractions, and it's also prompted me to get back into learning vim better. Any cases where I had trouble with control codes etc. were a good opportunity to learn more about the ecosystem - helps that that was my mindset going into installing Gentoo in the first place.

Headline editors gonna edit

You could also think about sitting at a train station trying to code, or that feel when you lick a battery

It's likely correct because I doubt these frustrations will be solved in our lifetimes.

> 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:

  bind '"' split-window -c "#{pane_current_path}"
  bind % split-window -h -c "#{pane_current_path}"
  bind c new-window -c "#{pane_current_path}"

`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]

[1]: https://andrew-quinn.me/fzf

> help systems that focus on learning by example rather than enumerating an exhaustive list of features (like most current man pages)

I almost always prefer exhaustive lists of features. Examples don't really teach you what each flag being used does, so you end up just memorizing combinations of flags without knowing what they actually do. I suspect learning solely by example is exactly why so many people have a ton of trouble learning how to use tools like tar, and the common refrain of "I have to look it up every single time".

Examples are useful, but not sufficient on their own for learning.

I have 100% same process, including the adding of comments at the end to tag commands for future fzf searchability (although in practice I find the need for this pretty rare).

Of course it does also presume keeping an appropriately long history, which from some of the comments in the article make me believe that I have long since forgotten that I needed to change that setting.

Are you backing up your command history?

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.

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.

This is Chesterton's Fence.

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.

Yet there is one and its reference shell (2022) ( https://www.youtube.com/watch?v=39ob0IO2Za0 ) is .. interesting

https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...

I couldn’t disagree more.

Check out powershell

TempleOS

I did the same. I have a little dotfiles repo[0] on github that I clone on a new machine, then I execute a setup.sh file that installs a messy set of aliases and functions to set up my cozy unix world.

[0]: https://github.com/jmcguire/dotfiles

For real, this is one of the things that LLMs are unconditionally great at doing. They are like lossy compression algorithms that store Stack Overflow threads and retrieve manual pages. Or, with a fair probability of success, you can ask them to write the command.

I don't mind Ctrl+Shift+C so much, except that I mess it up several times a day, and that combo opens dev tools in Chrome, which takes several seconds to load on my work machine, messes up what I was doing and is a general nuisance. I wish there was a way to NOOP that combo in Chrome.

I believe fish shell solves this by inserting a visible "⏎" character at the end of the line and moving to the beginning of the next line for the prompt.

    if [[ "${TERM}" != "dumb" ]] || [[ $- == *i* ]]; then
        PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"'$'\n'"$PROMPT_COMMAND"
    fi

Occasionally happens to me too. I believe I researched the cause being some kind of history corruption (eg bad control characters mistakenly pasted/output), and zsh will just make new history file if it detects corruption.

Now, I made myself a cron script that once a day just copies the history file to a backup folder, so that I can bring it back if it ever corrupts.

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.

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

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.

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.

You can edit text, at the prompt. Afterwards output is readonly and copyable. Doesn’t make much sense another way.