Comments on: Book

By: unixshell

unixshell — Thu, 07 Oct 2010 23:20:33 +0000

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.

By: unixshell

unixshell — Thu, 03 Jul 2008 00:51:04 +0000

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!

By: tresh

tresh — Wed, 02 Jul 2008 16:48:15 +0000

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

By: unixshell

unixshell — Thu, 19 Jun 2008 22:16:05 +0000

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.

By: dj

dj — Wed, 18 Jun 2008 03:22:27 +0000

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

By: unixshell

unixshell — Sat, 24 May 2008 23:38:43 +0000

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.

By: tsuehpsyde

tsuehpsyde — Sat, 24 May 2008 16:21:06 +0000

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.

By: unixshell

unixshell — Mon, 05 May 2008 21:56:41 +0000

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

By: kamper

kamper — Mon, 05 May 2008 14:49:45 +0000

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.