Not to be that gal, but… the GNU site’s Bash Reference Manual documents everything you could ever want to know right up until you get into weird edge cases and abusing bugs/unintended behaviors for your own nefarious purposes.

For that, others have pointed to YSAP, whom I will also recommend. I can’t find it right now, but I swear in some videos he mentions a website or forum where people discussi Bash extremely in-depth, and that is end-game stuff (the stuff you learn right before you start auditing the code yourself or editing the source to enable your own custom behaviors)

The hard part for me was dynamic scope, which I found it was explained nicely in The Common Lisp Condition System: Beyond Exception Handling with Control Flow Mechanisms. Since then I have begun to feel that dynamic scope in Bash is a feature, not limitation.

shellcheck.net

Also, adcanced bash is mostly about structuring code for maintainability, exception handling and some good tidbit functions you can easily adapt. Actually a good experience for creating maintianable lower-level code too.

That said, i have a (POSIX) cheatsheet i still regularly use. Most important parts:

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## exit codes for GNU/Linux
┌──────────┬────────────────────────────────────────────────────────┬─────────────────────────────────────┐
│ Exitcode │ Meaning                                                │ Example                             │
├──────────┼────────────────────────────────────────────────────────┼─────────────────────────────────────┤
│ 1        │ Catchall for general errors, such as "divide by zero"  │ let "var1 = 1/0"                    │
│ 2        │ Misuse of shell builtins: Missing keyword or command.  │ empty_function() {}                 │
│ 126      │ cannot invoke requested command                        │ /dev/null                           │
│ 127      │ A utility to be executed was not found                 │ evho                                │
│ 128      │ Invalid argument to exit: only integer args in the     │ exit 3.14159                        │
│          │ range 0 - 255 allowed                                  │                                     │
│ 128+n    │ A command was interrupted by signal n (128 + n)        │ kill -9 $PPID returns 137 (128 + 9) │
│ 130      │ Script terminated by Ctrl+C: fatal error signal 2,     │ Ctl-C                               │
│          │ (130 = 128 + 2, see above)                             │                                     │
│ 255*     │ Exit status out of range: exit takes only integer args │ exit -1                             │
│          │ in the range 0 - 255                                   │                                     │
└──────────┴────────────────────────────────────────────────────────┴─────────────────────────────────────┘

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Numeric True/False

OR ||:
1 + 1 = 1         TRUE || TRUE = TRUE
1 + 0 = 1         TRUE || FALSE = TRUE
0 + 0 = 0         FALSE || FALSE = FALSE
AND &&:
1 * 1 = 1         TRUE && TRUE = TRUE
1 * 0 = 0         TRUE && FALSE = FALSE
0 * 0 = 0         FALSE && FALSE = FALSE

Btw; lowercase true/false are special in that they set the respective state, standalone or as argument.
     Said state can be set to variables too, for constructs like: var=true; $var && echo True


#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Variable-Expansion

┌───────────────────────┬───────┬───────┬───────────┐
│               VAR is: │ unset │ empty │ non-empty │
├───────────────────────┼───────┼───────┼───────────┤
│ [ -z "${VAR}"       ] │ true  │ true  │ false     │
│ [ -z "${VAR+set}"   ] │ true  │ false │ false     │
│ [ -z "${VAR-unset}" ] │ false │ true  │ false     │
│ [ -n "${VAR}"       ] │ false │ false │ true      │
│ [ -n "${VAR+set}"   ] │ false │ true  │ true      │
│ [ -n "${VAR-unset}" ] │ true  │ false │ true      │
└───────────────────────┴───────┴───────┴───────────┘

Btw,
[ -z $var ] &&
[ -n $var ] ||
are *not* the same; the first ist exact match, rather false, the second forgiving, rather true.

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Parameter expansion

# Use these in place of awk or sed calls when possible
┌─────────────────────────┬─────────────────────────────────────────────┐
│ Parameter               │ Description                                 │
├─────────────────────────┼─────────────────────────────────────────────┤
│ ${VAR/PATTERN/REPLACE}  │ Substitute first pattern with replacement   │
│ ${VAR//PATTERN/REPLACE} │ Substitute all pattern with replacement     │
│ ${VAR#PATTERN}          │ Remove shortest match of pattern from start │
│ ${VAR##PATTERN}         │ Remove longest match of pattern from start  │
│ ${VAR%PATTERN}          │ Remove shortest match of pattern from end   │
│ ${VAR%%PATTERN}         │ Remove longest match of pattern from end    │
│ ${#VAR}                 │ Length of var in characters                 │
└─────────────────────────┴─────────────────────────────────────────────┘

Summary:
* String manipulation with ${VAR#PREFIX}, ${VAR##PREFIX}, ${VAR%SUFFIX} and ${VAR%%SUFFIX}.
* Conditional treatment of unset variables with ${VAR-DEFAULT}, ${VAR=DEFAULT}, ${VAR+FALLBACK}
   and ${VAR?MESSAGE} as well as the unset-or-empty variants with :-, :=, :+ and :?.
* Variable length with ${#VAR}.

filename=/foo/bar.baz
"${filename%/*}"  # /foo      # dirname
"${filename%.*}"  # /foo/bar  # filename
"${filename##*/}" # bar.baz   # basename
"${filename##*.}" # baz       # file-ext

Btw, if it goes over 100 to 150 loc, go Python at least. No matter how disciplined you are or how clean your code is, it gets messy.

You Suck at Programming on Youtube

https://www.youtube.com/channel/UCMN0a7GHQnC6H74SmCGSmdw

YSAP, does a lot of basics, but has some videos about more obscure stuff too Well delivered and interesting

To be fair, bash is pretty simple. You can find the syntax for regular expressions, string manipulation and stuff like that by searching the syntax on the internet. It is not too long.

You can read the manual, it explains all that. That should be enough, I would not say you need much more than that.

Now, if you’re talking about using bash scripts professionally, I’d say you should focus on studying programming in general, not really focused on bash scripting. But at that point you’ll realize that bash scripts are pretty much a useful quick utility, not something you’d really want to write complex logic with.

If you want to be proficient in using your system, rather than learning the whole syntax of bash I’d say knowing what the GNU tools are is very much more useful.

You want to get the number of unique values in a column of CSV? cut | uniq | wc at this point bash just becomes a way to put pieces together and you do not need very advanced features.

Everyone here is throwing resources about where to learn more about Bash instead of answering the question. I’d say regex is good to learn regardless as it’s pretty much used everywhere, but advanced bash scripting probably isn’t worth the trouble unless you’re using sysvinit scripts or something. Bash was really the first language I learned and nowadays I find myself starting scripts in bash and then quickly converting over to python the moment I have to manipulate strings. Python is much more straightforward in that regard.

Shh, LLMs are quite good at stuff like this. Let them teach you. Use a command line harness like opencode or whatever tickles your fancy.

Use a local model like Qwen 3.6 if you can, and start having fun. You might to have to learn how to use a LLM effectively though, to mitigate their disadvantages like hallucinating and their non-deterministic nature. Also, they want to do everything with curl, maybe find some alternatives to that.

The Advanced Bash-Scripting Guide and Classic Shell Scripting[PDF] are both great IMO.

Overhewire bandit is a tutorial and introduction to CTF’s. It covers some of the lesser known commands like strings or uniq, by making you use them in challenges. Of course, it later goes on into basic exploits. But it’s a good intro to some of that stuff, and I like that it’s hands on.

I run Qwen2.5 Coder 14B locally for boiler plate stuff that I then edit myself and it’s been great. I write code irregularly so using an LLM is nice when I know what I want to do, how to logically do it, but I’ve since forgotten the syntax.

Edit: I figured this would be a little contentious. If you write scripts so often that you feel like it’s worth it to invest time in becoming better at them, then by all means. This is just a hobby for me. As much as I’d love to do so, investing time in getting better at scripting is unfortunately a waste.

My personal basic tools for learning:

• man bash. That’s the documentation for everything. It’s very careful and serious though, so sometimes you need…
• Search in internet if you think your particular question is very “repeatable”. Stackoverflow used to be good, but now they’re all “AI AI AI by the way have you heard about AI?”. So I’m not recommending it anymore. For “advanced bash” there are pages that go over those “advanced topics”, too!
• Run shellcheck to read your code and give suggestions/warnings. It’s a great tool for learning, too, besides the primary goal of reviewing code to be production-ready.
• Sometimes, with extreme care, ask an LLM to review your code or give siggestions. It tends to hallucinate a lot, makes up wrong and unexisting stuff, but sometimes it’s useful, too. Especially at finding bugs. Again, it can be useful, but use with care. Oh, and it can actually be great at explaining, too. Throw it some syntax/code and it’ll explain wtf is going on. This part is very reliable and good.

At my current level of experience I need mostly man bash, and occasionally all of the rest. Before I used a lot of stackoverflow and simply thinking of what I even want.