> 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.
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.
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.
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.
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.
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.
`--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`.
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).
--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.
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
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.
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.
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.
(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).
"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."
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.
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.
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.
It’s quite remarkable that the whole stack works as well as it does. I’m using a terminal emulator, which is running a shell, which launches an ssh connection, which opens a remote shell, which I use to attach a tmux session where another shell is already running, which I use to open a file in a text editor, which displays a cat emoji correctly.
> 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.
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
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.
For copy-pasting text to/from the terminal, I prefer to use Mac shortcut Cmd+C. It doesn't work out of the box on Linux (you have to use Ctrl+Shift+C, because Ctrl+C sends SIGINT). But there's a simple way to make Cmd+C work universally across all apps by rebinding Cmd+C to send Ctrl+Insert and Cmd+V to send Shift+Insert. It turns out these alternative keybindings work everywhere (browsers, GUI apps, terminal, etc). I use keyd to do that in software, but some QMK keyboards can do that rebinding on the keyboard itself.
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.
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.
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
> 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.
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.
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.
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!
Readit News
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.
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.
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.
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.
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.
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
But asking for `--help` is unambiguous, and is in fact the lowest common denominator way to be explicit about it.
This is especially useful in situations where the help text is enormous (dozens and dozens of options).
--help being an incorrect argument does the right thing, yes.
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.
`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).
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."
Expecting there to be a safe invokation for "how do I use this damn thing" is 100% fair.
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.
> 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/
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!
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?
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
ymmv but I prefer this to searching.
This is my keyd config:
You are remembering correctly, pbcopy (and it’s partner pbpaste) are preinstalled on all Macs as part of the OS.
See also IBM CUA: https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
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.
* 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.
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.
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.
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.
* 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