Thank you for the feedback! It's not a beginner's guide; it really is intended for people with at least a reasonable understanding of programming concepts such as scope and the difference between imperative and other types of programming.
Maybe you are right, but I don't think you and the publisher did justice to your book.
It's clearly a course - 99 lessons, wow! First look at the index may confuse potential reader. It's about signals and copy and paste at the same time. Copy and paste actually CAN be tricky and is mostly not well understood for people not raised on a Linux desktop. But the headline itself confuses me and my first though was that it's more of a beginner course like those RedHat has at the begging of the certification path, before tests start. - what is console, what is Gnome, files, users, groups etc..
What usually made me interested in such products was a clear, full chapter that I can read. Even better if it's an actual chapter that can be used individually, without the context of the rest of the book. Not the introduction. It is usable on it's own, so it's linked by people - that is some good publicity. It worked on me and some of my friends!
Also how does it compare to other books, like https://tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Gui...? Yours looks like for beginners but it's just targeted towards devs that don't know bash and linux terminal well. The linked one is titles "for beginners" but it's not really :)
I hope this gives you some insight that you can use in future. I really didn't wanted to just complain in vain. Some of my friends wrote large IT books and I know how weird experience it is to work with a publisher. Good look!
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.
