I once saw Bram Moolenaar do a Q&A on Vim. Someone asked about some feature or the other and Bram didn't really know how it worked from the top of his head, "because I never really use it".

Shells are large programs. Everyone is unfamiliar with some bits because it just doesn't fit in their workflow.

One could say the same thing about empathy, another "basic" skill.

Imagine how you'd rush to justify your lack of it here.

Everything you'd say in your defense would equally explain why someone wouldn't know the meaning of a certain unmarked number in the output of a random shell command.

There are a lot of people learning a lot of things for the first time everyday. Time and attention are limited and must be allocated, and sometimes that means you don't read manuals for everything.

I've seen myself transition. I've read python 2 stdlib docs cover to cover, and was better for it. It was also the last language for which I did that. I skimmed kotlin stdlib, and with go these days I hit up a search engine.

If everyone spent time going through every supposedly basic thing first, nobody would get anything done.

It's not at all obvious that the number is the history entry number, and I'm not even sure if knowing that brings any value to the average user.

I’m not defending GP, but this bit from your post got me thinking:

> If everyone spent time going through every supposedly basic thing first, nobody would get anything done.

I’m not convinced that’d be so bad. We could all strive to do less. There’s too much bullshit “doing” in the world and not enough thoughtful pondering on what should be done.

If everyone spent the time to go through basic things, and thus had less time to do new things, then there would be fewer things to go through. And every new thing would be informed by what came before and not repeat its mistakes. And they would have had more thought put into it, thus be less buggy and dysfunctional, thus necessitating fewer alternatives.

It’s not going to happen, but everyone doing less and taking the time to learn the basics would likely make the world better.

I think curiosity is a nice trait to have. Whenever I have a question like the one quoted, i just do a quick search if I have the time to do so (and more often than not, you do). Or I just add it to my notes.

I don't bother reading entire manuals either, but I know where they are. And if I'm using something often, I also try to learn how to best get help and information. Knowledge of the shell isn't mandatory, but can help greatly sometimes. If someone implement a feature to scratch an itch, it's nice to know about it when the same thing frustrates you too.

The shell should just have better UX. If 5408 is the id of the command ran... just list that out in the printed table. Powershell and nushell do this really well.

Because you can use the ID to recall a previous command with "!". This is a feature that predates Bash+readline.

History substitution with "!" goes back to Bill Joy's csh, 1979.

I've known this since the start of my using unix shells, but it's almost useless. For example, if fzf or whichever plugin I'm using shows me the number, why would I need it when I'm going to use the list it has presented? I certainly wouldn't cancel it and use the number, nor would I type the number when I have the choice of banging one key repeatedly, or adding characters I can see in the command to narrow the search even more.

Some features just aren't worth the time.

In nushell you can use it to look up more detail about that command:

     > history | get 81201
    ╭─────────────────┬─────────────────────────────╮
    │ start_timestamp │ 2025-03-26 05:16:58.184 UTC │
    │ command         │ echo hello world            │
    │ cwd             │ /Users/matt                 │
    │ duration        │ 1ms                         │
    │ exit_status     │ 0                           │
    ╰─────────────────┴─────────────────────────────╯

It's nice for confirming a suspicion that something is now slower than it used to be.

That's fair, I might have to change my ideas ;-)

> please pick up a book on bash/zsh/sh and take the time to learn.

Or even just the man page! bash(1)'s man page is a treasure trove, and it's a fairly short read (versus an entire book, at least).

    man bash