49 of 65 people found the following review helpful
2.0 out of 5 stars
For beginners..., 5 Jun 2002
Traditional shell scripts are horrible. They are not nice languages with orthogonal instruction sets: they have grown organically, and inconsistently. Quotes, double-quotes, and escaped characters are often needed to slip something past one parsing layer to get it to another one.
Chapter one starts off describing what a terminal session actually is, so this is aimed at real beginners.
If you are a beginner, and you are able to chose your scripting language for your job, you might want to look at some of the more recent languages, such as 'python'. They are more regular, and easier to learn and maintain.
Anyway, back to the book. There are things you shouldn't do in a book that may be uses as an introduction and a reference. You should not give examples of code with bugs in, that you explain in the following chapter (ta-daa, aren't I clever?!). You should not give tables of functions or commands unless you list all the commands. If there is an exception to a rule, then you should at least mention it even if you haven't covered that case yet, or, better still, re-arrange the book so the exceptions are explicable. You must resist the urge to surprise the reader: this is shell scripts, and the reader will probably have had their fill of surprises. Last of all, and a personal one this, lay off the Lewis Carroll, please?
You need to be ultra-careful about quotes. When "@" appears in the text, does this mean a string of one character or three? Can you see whether the quotes are in heavy type?
You need to be really careful to distinguish what is 'in' the shell, and what commands and variables are outside it. Pattern matching is a key part of the shell, so regexps ought to be explained in some detail. The simple demo scripts should not have 'ed' and 'sed' commands stuck in without saying where they came from.And why not mention the debug flag before chapter 9?
There are some dubious comments about programming style. Is it really bad to use the 'break' statement in a loop? Is '<command1> && <command2>' really an obscure and unnecessary way of doing command2 if command1 fails? - I find it neat and compact.
This is a pity, because there are some good bits. The flow diagram on p178 and the attendant text about how command lines are processed is good (well, right up to the "-and it's not the whole story!", but you get the idea). But, for completeness, I reckon if there is something I want to look up about the bash shell, I am going to use my old Korn shell book rather than this book.