Book

A serious publisher has contacted me about writing a serious book about Linux shell programming.

It is all really very serious. I’m not used to being serious, as you can probably tell from the fact that I have now used the word “serious” four times in this three-sentence post.

I am rather keen to write a book on the subject, not because I’m vain, or desperate for money, but because the stuff I have seen out there in dead-tree format has been of rather low quality. Also because of all the emails I’ve received over the years, they have all been positive, and none has said anything along the lines of “I didn’t need any of that because I bought Book[X]”, or indeed any book. People have emailed me, asking for advice as to what book to buy, and I have been unable to recommend any book that I have seen.

So:

What would you like to see in your ideal book about UNIX / Linux shell scripting, be it Bourne, Bash, ksh, tcsh, zsh, whatever?

Please don’t be timid; if you want to know how to work out how many nose-flutes can be fitted into the area of a Boeing 757, you won’t be anything like as strange as some of the correspondants I’ve had over the years, so please, tell me what is bugging you, what has bugged you, or even what you think might be likely to bug you in days / months / years to come.

I’m likely to answer any specific questions here and now, whether or not they end up in the book, but anything you’d like to see in a book, too… post that here, and I’ll have a stab at it.

Also, I would of course be interested to know if you have found any useful books on or around the subject, and what they did particularly well.

Steve

9 Responses to Book

  1. kamper says:

    One of the reasons Jeff Friedl’s regular expressions book is so good is that it spent a lot of time discussing how a regex engine could/would be implemented (but not at such a low level as to be tedious). Knowing the underlying concepts means not having to memorize a bunch of random stuff because you can pretty much predict how it’s going to work.

    Accordingly, I think it would be good to have a couple of chapters on the implementation of the rudimentary concepts of a bourne shell. How is script parsed? When and how is each fragment executed and how are the outputs and inputs piped around? The more conceptual and portable (not a bunch of bashisms) the better. Going light on the various unix utilities would also be good. Yes, they’re an integral part of any script, but they’re easy to learn via manpages. Explaining utils like test and expr would be necessary but I’d like to read “here’s roughly what they do, now go read the manpage if you want to follow along.”

    Also, I’d personally like to have a bit of a csh survival guide for sh users, but I can probably find that online. But a deeper look at the underlying differences (why are they different?) could be interesting.

  2. unixshell says:

    Thanks kamper – really good points, especially about the “how it works”, not “how to do it” – that makes a big difference.

  3. tsuehpsyde says:

    I’m not all too concerned about what you write about, so long as you write it. πŸ˜‰ Your guide online has been pretty useful to me (got me back into shell scripting, and probably going to move to some other scripting languages as well) and I’d have been stuck without it. So I’m sure whatever you write in a book will be good. My only concern is to keep it up to date (that means using bash), since too many shell scripting guides are painfully out of date with stuff like ksh, csh, and the like. Maybe someone uses those in production environments for cgi scripts or cronjobs, but I’ve never seen it. The main focus should be bash, as that’s what’s here and what is used most often.

    Just be sure to have a section heavily weighted on incorporating sed and awk, as those two little guys bring shell scripting up a notch or two.

    Keep up the good work. πŸ™‚

  4. unixshell says:

    Thanks for that, too. As you say, bash is being more and more widely used these days, with traditional Unix systems as well as Linux. As you mention, for system scripts, Bourne compatibility is essential; for the majority of uses, Bash offers much more power and flexibility.

    Therefore, both need to be covered; the way I see this book dealing with that issue, is to generally go for Bash stuff, but to make it clear that certain things are different (or sometimes impossible) in Bourne shell.

    Both comments so far have also mentioned the importance of how the shell interacts with external utilities; in itself, the shell is a useful, but limited language… with sed, awk, grep, find, and a whole bunch of other tools, combined with the *nix fork/exec mechanism, the whole thing really comes to life – with pipes, redirections, and so on. It’s a bit of a cliche, but “everything is a file” is a really important metaphor. Similarly, chmod / mknod / etc etc are all relevant to the overall picture.

  5. dj says:

    I have plenty of programming experience, but it was a little tricky picking up Bash. I started with the manpage, bash reference (which is from Network Theory), and FAQ. I reviewed briefly TLDP two Bash docs. However, the web site, http://linuxcommand.org/writing_shell_scripts.php, was my salvation ;-). It helped me put it all together and develop complete scripts that included getopts, heredoc help, functions, and trap, among many things. The FAQ, GUIDE, PITFALLS at http://wooledge.org:8000/BashFAQ were also helpful.

    There is a lot out there, but a lot is old and plain wrong and when you are learning, it doesn’t help πŸ™‚ What seems like little things can trip you up big time. Suggestions made here are good, especially the how it works. I’d say cover Bash expansion in details, all 8 of them (brace, tilde, parameter, command, arithmetic, process, splitting, globbing), quotes, $@ vs $*, strings, numerics, and arrays, the string and numeric operators, as well as command pipeline. Took me awhile to understand && and || in a command pipe verses an expression – context is everything. Have good examples, and maybe a complete application, slowly building it up. Stay away from chapters on installation and history πŸ˜‰

    Is the test command or [, being replaced with [[? I’ve seen lots of examples that use -eq in [[ but -eq is a [ operator. The whole [, [[, ((, $((, &&, ||, -o, -a, etc could be covered, maybe the topic is building successful expressions.

    I just found your site while looking for bash specifics, and the organization of the tutorial looks good. I’m going to review it in more detail. Thx

  6. unixshell says:

    Thanks for so many really detailed responses; I’m blown away.

    Lots of great stuff there, DJ; I think I’ve got them all covered (no “installation”, though I have got a “history” chapter… it’s really short, honestly!). The series that I’m writing it for has a policy to have lots of examples, so there will be lots of that, and expanding them to wider, more general uses too.

  7. tresh says:

    One of the premium requirements, in my book, as a quick reference section in logical groups. For example, “Section I – Loops. Section II – Conditional expressions. Section III – Bitwise expressions.” Something of that nature.

    On the rare occasions I’ve been up 40 hours and I’m parsing an “if” statement wrong, finding it in the bash manpage is.. Well, you can imagine, I’m sure. XD

  8. unixshell says:

    Many thanks again; I am really inspired by the quality of the quantity and level of feedback on this subject.

    Unfortunately, my employer has suggested that they’re not too happy with me writing this in the 128 hours a week that I don’t work for them; for now, I’m going to let the original project lie, though I am more inclined to write a book based upon suggestions posted here than on the ideas of a random publisher wanting to publish yet another half-ton book…..

    Keep these excellent ideas coming: Cutting out the middle man could well be a good thing, after all!

  9. unixshell says:

    Just over 2 years later, I am happy to report some good news; the awkward employer has removed himself from the equation (and from the country, and from the taxman, and from such trivial annoyances as paying salaries and expenses to his employees, but that’s another story).

    Now that I am a truly free agent, the book project is back on. Again, please comment with anything that you would like to see.

Leave a reply to unixshell Cancel reply