Some terminal frustrations
jvns.ca
jvns.ca
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:
touch ./-l
ls -?
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:
touch a
ls -?
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'?' 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.
MegaCli -PdReplaceMissing -PhysDrv [1:1] -Array2 -row1 -a1
MegaCli pdreplacemissing physdrv [1:1] array2 row1 a1Likely inspired by JCL syntax!
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`.
$ 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.
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?
echo --help $ echo --help
--help
$ type echo
echo is a shell builtin 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.
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.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).
> 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.
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!
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
This is my keyd config:
[ids]
*
[main]
capslock=overload(control, esc)
leftalt=layer(meta_mac)
leftmeta=layer(alt)
[meta_mac:M]
c=C-insert
v=S-insertSee also IBM CUA: https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
You are remembering correctly, pbcopy (and it’s partner pbpaste) are preinstalled on all Macs as part of the OS.
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:
function lm {
local input="$*"
llm -s 'Answer as short and concise as possible' ${input} | glow
}
$ lm "ssh command to forward the port 5050 on user@remote to my localhost:7001"
ssh -L 7001:localhost:5050 user@remote
$
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
* 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.
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)
$ source how.sh
$ add a user bob using modern homectl methods
$ add a user bob using modern homectl methods ... (name of your default model)
... a few seconds pass ...
$ sudo homectl create-user bob
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
shopt -s histappend
shopt -s cmdhist
export HISTCONTROL=ignoreboth
export HISTFILESIZE=-1
export HISTFILE=~/.bash_eternal_history
export HISTSIZE=-1
export HISTTIMEFORMAT="%d/%m/%y %T "
export HISTIGNORE="history:ls:l:ll:pwd:exit:clear"
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.
* 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
How does this help to memorize syntax if you repeatedly use the same commands?
Also the fact it syncs between machines means even if the last time you used that command was on your old laptop 2 years ago ctrl+r still finds it
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.
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.))
----
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.
COPY: select text with the mouse
PASTE: middle click
don't people use that? No need for the keyboard at all! It works across all programs since forever (except inside jupyter notebooks on firefox, for some weird reason).
If I had to single out a unique feature that makes linux worthwhile (as compared to windows or macos) it would be that one! Way ahead of anything else.
If the desired selection is large and spans multiple lines, yeah, you're going to have a bad time doing it via the terminal emulator (but that has little to do with the split, other than splits make it more likely to wrap), but you can then just fall back asking vim to copy it to the selection.
(This does get back at the complaint in TFA, though, that they're not the same, the moment we have to switch from the terminal to vim's command.)
(All of this probably applies directly to tmux too, but I don't use tmux.)
I mostly used this to copy paste from a terminal into a COTS GUI tool, or from that tool into the OpenOffice (or maybe LibreOffice, I don't recall) spreadsheet program whatever that's called.
Honestly it was incredibly useful and probably saved me collective hours over the few years I worked there
Obviously this thread is about terminals, but the functionality does exist in some places
What terminals have middle-click-to-copy, right-click-to-paste? Sounds alien to me.
[0] https://en.wikipedia.org/wiki/X_Window_selection#Clipboard
CMD on Windows, default PuTTy settings, WSL as well. I honestly haven't used GUIs on native Linux environments much, and when I have I must have changed the terminal emulator settings.
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.
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?
> $ find --help
> find: illegal option -- -
>
> $ find -help
> find: illegal option -- h
>
> $ find -h
> find: illegal option -- h
And to add some mor efor testing: you can try "find /help", "find /?" and "find -?", in case it's using dos-style parameters.
> $ file `which find`
/usr/bin/find: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
> $ find /help
find: /help: No such file or directory
> $ find /?
zsh: no matches found: /?
> $ find -?
zsh: no matches found: -?On my system Ubuntu 24.04:
$ find --version
find (GNU findutils) 4.9.0
$ find --help
works
$ find -help
works
$ man find
then /help worksHas 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
Read Google bash coding guidelines.
Try to write shells scripts that don't fork. That approach really helped me write resilient scripts.
Use
x=`${...}`. Instead of
echo |...
Then you bash starts to improve every day, instead of accepting mediocre all your life.%
I have given the above lesson to a few folk who suddenly found bash fun and a highly productive programming language.
Like all languages get it working first, make it testable and refactor until it's good.
With bash that whole process can take 5 mins for a simple script: and scripts should only be simple
echo x | sed "..."
Is doubly confusing.
1) the general UX of terminal emulators. Which as the wording suggests is about emulating some severely obsolete, at least half a century old hardware, including weird limitations that came with those. Most modern terminal emulators work hard to undo some of that. 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. I just turned 50 and I remember having some slightly less fancy terminal emulators to work with (xterm basically) on hpux, sgi, and some sun workstations we had at university in the nineties. Even then the whole notion was basically obsolete. All those came with xwindows, xterm and some basic shells and other command line tooling.
2) the general UX of cli software that you would use from a terminal. Which is a bit all over the place and generally not great.
If you use something reasonably modern, the terminal environment is not completely horrible. I use iterm2 on a mac, which is pretty nice. There are a few competing products. What I like about iterm2 is that I can use cmd+c and cmd+v for copy paste so I don't have to think about having to hit the shift key just because I'm in a terminal window (like on the Gnome terminal). Also nice is that two finger scrolling works. Even when using less/bat/more/whatever. There are a few other nice things that they solved but that solves a few basic UX issues.
The second issue is harder to address because it basically involves fixing a lot of tools that have been around for decades, which is just not going to go down well with those that have used those tools for a few decades. There are some nice modern replacements for some of those tools. For example, I use eza instead of ls (via an alias of course). And there are a few similar rewrites of classic cli tools that offer some nice features and performance. But mostly those aim to be drop in replacements.
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.
You could also think about sitting at a train station trying to code, or that feel when you lick a battery
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:
bind '"' split-window -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"
bind c new-window -c "#{pane_current_path}"
Not just current dir, but the whole env:
export SECRET=oops # could be silent if you use e.g direnv
tmux # first one => start daemon
tmux
env | grep SECRET # oopsThese frustrations seem inevitable given the diversity of systems people need to interact with. But I think a lot of them could be eased with better help systems; in particular, with help systems that focus on learning by example rather than enumerating an exhaustive list of features (like most current man pages). AI clearly has a role to play here, but most tools I've seen seem focused on simply providing the answer rather than building proficiency in the user.
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.
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.
This makes ‘remembering’ syntax and flags less stress inducing. You only have to figure it out once. Fzf will pull it up for you in a second. I also add #comments at the end of the commands to serve as search tags..
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.
> keyboard shortcuts for tmux, text editing, etc
tmux -> zellij has good discoverability of shortcuts. Since written in Rust, it can be installed with cargo
For vi, I don't have an alternative, the first thing I do on a machine without vi is get neovim, or vim, or vi. I mean, I don't know how good emacs is these days, and nano is limited but back when I started to use pico (which nano is a successor for) it had good discoverability.
My very first text UI editor was a DOS text editor called Q&A. All the F-keys were mentioned on the bottom. But once you know them, that information becomes redundant. Especially on a low resolution. So nowadays, given we hardly ever use 80x24 anymore, yet stuff looks good on high resolution (due to good DPI) it is only a minor sacrifice.
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.
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.
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-]+")
(Invoke-WebRequest -Uri "http://localhost:5555/log" -UseBasicParsing).Content | Select-String -Pattern "2025[0-9-]+" -AllMatches | ForEach-Object { $_.Matches.Value }
Get-Process | Where-Object { $_.ProcessName -match "ffmpeg" }
Auto complete is quite good though.
$ ps ax | grep ffmpeg
66898 pe S+p 0:00.01 grep ffmpeg
$ ps ax | grep '[f]fmpeg'
$ pgrep ffmpeg
$
The way to write that on the command line Powershell would be:
ps ffmpeg
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.
(curl http://localhost:555/log -useb | select content | sls "2025[0-9-]+" -a).select.matches
(gps ffmpeg) or (ps ffmpeg)
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.
Beyond that, I am enjoying a little bit too much customizing Fish, bobthefish, FZF, and replacements for established CLI apps (e.g., find/fd). I spend too much time asking Claude how to do various things. And I am the happiest with my current setup—until I have to SSH into the barren lands of a production host.
As a result, most of the non-memory issues listed here are things I solved once in those scripts and rarely have to think about again. Most of the simple memory issues can be solved by running `cheat x` and/or `tldr x`, where x = the program I'm struggling to remember the basic usecase of, both installed by those scripts of course. Most of the more obscure memory issues I can deal with with either ChatGPT or Anki these days.
I originally considered writing my scripts as a `host: localhost` Ansible playbook instead, but then I remembered that whatever I might gain in idempotency I would lose tenfold in hackability. I am guaranteed to be doing shell for the rest of my life; I am decidedly not guaranteed to be doing Ansible, or any other config management tool for that matter.
Hopefully one person sees this and saves thousands of keystrokes over the next few decades ;)
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.
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.
[0] - https://llm.datasette.io
[1] - https://docs.github.com/en/copilot/using-github-copilot/usin...
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.
On Linux I rebind SIGINT to Ctrl+Shift+C and similarly Ctrl+V -> Ctrl+Shift+V. This has never caused problems, except when a friend/coworker is trying to use my machine.
GNOME Terminal makes this easy; if you map Ctrl+C to copy, it will automatically remap SIGINT to Ctrl+Shift+C.
Its not clear what the solution would be. My pet solution would be to have a control character that is only a newline if the previous character was not a newline, which you could put un $PROMPT
if [[ "${TERM}" != "dumb" ]] || [[ $- == *i* ]]; then
PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"'$'\n'"$PROMPT_COMMAND"
fiNow, 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. 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.
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:
echo "12345789"
And before someone suggest some option to enable this: my comment was about changing the defaults.
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.
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.
"remembering exact commands" (vide https://xkcd.com/1168/) and "getting context for a given instruction" are precisely things at which LLMs excel.