Actually, if you truly, really want to understand Bash by my personal arbitrary standard, then you must be able to produce the entire source code from memory, because that is the real book to rule them all. Sure, you might be able to navigate your everyday tasks perfectly, but that's not what matters now is it?

Yeah, I've been deep in the bash manual and source code during my work on https://www.oilshell.org, which basically reimplements a "cleaned up" spec-driven bash (called OSH).

But I also used bash for 15 years before that, and I hardly used the bash manual. I got by with a minimal / sane dialect, and I read a few books about Unix, and one about POSIX shell (the latter is also "meh").

Now that I've read almost all of the bash manual, I'd say it's not really a special document. It's fine, but it's not complete, and I wouldn't say it's particularly well written. It lacks examples.

--

The main recommendation I have for anyone who wants to learn bash is to learn Unix and C. Learning the underlying model explains many things, explains the bad error messages, and makes it easier to use.

https://www.oilshell.org/blog/2020/04/comics.html - Three Comics For Understanding Unix Shell

So yeah I don't think "learning shell" or "learning bash" is actually a great goal -- it's part of the operating SYSTEM, and you want to learn the OS, and its philosophy.

related - https://www.oilshell.org/blog/2021/01/philosophy-design.html - Unix Shell: Philosophy, Design, and FAQs

--

Probably the most useful part of the bash manual is the acknowledgement that there's a lexing design bug with [[ and regular expressions.

It's better to make the regex a separate var, like

    pat='[[:digit:]]+'
    if [[ $mystr ~= $pat ]]; then ... fi

... than to inline it, because bash does funky stuff when you inline it. It confuses regex metachars and bash metachars.

It's trying (and failing) to make regexes syntaically part of the bash language, but it's better to treat it like Python, where Python syntax and regex syntax are separate.

`man bash` is, hands down and by far, the most accurate and complete bash resource.

That doesn't mean it's a pleasant or even good read. It's terse, technical and descriptive. It's a users manual, not a textbook, and not a tutorial.

But it's complete, explains everything, it's free, comes with bash, and is searchable ;-)

I have spent a lot of time in there, usually when debugging or extending old shell scripts.

Usually when I can't find a simple way to do something, only a messy/complicated one, I find it worth popping into the info file and looking around - as long as you're comfortable using bash-specific (vs POSIX) idioms, there's often some generalization that helps. (Having said that, stack overflow "isn't great until it is", I've found some real gems of "can't you just do this?" that vastly simplify what I was trying to do by, effectively, doing something else entirely.)

That said, I think with bash (and anything with a man page more than 5 pages long - "screen" and "lsof" for example) it's worth just doing a quick skim of the entire man page once every 5 or 10 years - sure, most of it will be "yeah, I know that", and a bunch will be "... who asked for that? why do we even have that lever?" but there will be a few things that fix something that's annoyed you for years, and a few things that you'll ignore and then 6 months later you'll say "wait, I read something about this" and go back and fix the problem.

(Reading the changelogs of your primary tools is also smart, and I'll admit I pretty much only do that when looking at security changes, or when looking at a weird behaviour change between releases and trying to figure out what the intent was - not that I recommend that part per se, you just become the greybeard everyone comes to with weird questions :-) Most recently, bash pipeline tail-exec...)

There's a reason the man page is 200 pages long with 43,000 words. There's a lot more there than you imagine, much of it subtle.

Once you've read it, you don't need to Google anymore. You just open up the man page to the relevant section and see all the context, rather than just one answer to one question.