No worries - the book grew out of a Bash course[1] I developed and ran at my previous and current employer, which mostly goes through a bunch of WTFs and non-tr

No worries - the book grew out of a Bash course[1] I developed and ran at my previous and current employer, which mostly goes through a bunch of WTFs and non-trivial syntax and solutions to common problems which turn out to be more subtle than the naive implementation would indicate. I haven't read the guide you linked to, but scanning the index I'd say my book is quite different: - A big portion of my book is about quality assurance - exiting early, automated testing, linting, the most readable forms of commands, and the like. - It's focused much more on scripting than command-line use. - It avoids common pitfalls like using `which` to determine what will be run[2]. - Rather than give a surface treatment of `sed` and `awk` it treats those as separate subjects which would be better learned from some other source. Personally I avoid `sed` and `awk` in scripts where possible, since a lot of the things they do can be achieved with more maintainable commands, anything non-trivial is really hard to read, and using either is an indication that the problem might better be implemented in another language. - It's opinionated about interactive scripts. Basically I consider them a bad idea the vast majority of the time because they pretty much preclude wrapping in a sensible way, and add a bunch of extra code irrelevant to solving the problem. [1] https://victor-engmark.gitlab.io/advanced-shell-scripting-with-bash/ https://victor-engmark.gitlab.io/advanced-shell-scripting-wi... [2] https://unix.stackexchange.com/q/85249/3645 https://unix.stackexchange.com/q/85249/3645