Slashdot Mirror
Unix Shell Programming, Third Edition
Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts. For these we could best go back to the old ways. Combining the power of the common Unix tools, pipes and scripts in a fairly obscure and slightly arcane syntax is not easy to pick up, though the language's simplicity does, in some ways, make it easier than more complex ones such as Perl. This book does a good job at introducing shell programming and I found it an excellent book when I needed a refresher.
I don't want to sell this volume short: you won't just learn about shell programming. The first ninety or so pages provide an excellent guide to getting the best out of the shell, and the last chapter is devoted to the features specific to an interactive shell such as command-line editing and using the history.
The authors have chosen to use the POSIX standard Bourne shell ('bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell.
The book is well structured, starting out with a brief look at *nix operating systems before introducing the shell followed by some basic tools; cut, paste, sed, tr, grep, sort and uniq. One minor quibble, the book explains how to redirect STDOUT to a file and STDERR to a file, but not how to redirect both to the same file. That aside, these few chapters provide a good introduction to the shell.
The text goes on to systematically explore shell programming starting with variables and arithmetic. The chapters are kept short, in a good order and have a number of exercises at the end of each. The structure of the book and the order each new concept is introduced is well thought out; at each stage small examples are given that only use material already introduced and are complete in performing a task. In early chapters they are fairly trivial but by the end there is a fairly complete rolodex program written in shell script that would be a good model for anything you wished to do.
There is also a good summary of the shell syntax and common commands in Appendix A and good 'Further Information' in Appendix B. Kudos must go to the authors for a list of books for further reading that is not ashamed of mentioning other publishers, indeed they say "One of the best sources of books on Unix-related topics is O'Reilly and Associates" and list volumes from them before mentioning their own publishers.
There are some small typographic errors in the text but I did not find any in the script examples I tried. I found it to be well written and readable throughout, perhaps an advantage of a third edition in a slow moving technology.
You can visit the Sams web page devoted to the book which has the Table of Contents and the third chapter available for download. It has no errata or source code, I looked to see if the authors maintained a site for the book but could not find one.
I would recommend everyone read this book once or twice, it provides a comprehensive, well written tutorial on one of the most basic (and often overlooked) tools at your disposal. Even Windows users could install Cygwin and gain the benefit of a good POSIX compliant shell and this book. It also has the advantage that once purchased it will be useful for many, many years to come - the language has not changed noticeably in twenty five years and should not change in another twenty five.
You can purchase Unix Shell Programming, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
I wouldn't call it a lost art, but with all the advancements in GUI, it certainly doesn't get used as much as it should.
I find it to be a very nice tool to do simple jobs, without having to write a program to do it.
If I'm not mistaken Longhorn (next Windows) will even have a shell like interface (something other than the command prompt), so perhaps shell scripting will have some sort of a ressurection in the following years.
When I first started learning about the concept of shells, I was moving from the MSDOS world.
One of the first things I remember reading was the FAQ describing the shell differences.
Imagine my surprise that the command line could hold so much control and there were other aspects of controlling a PC. I haven't looked back since, but that page really brings back some memories.
It's funny how something you read can cause one of those lightbulb moments.
Patrick's research staff contacted me two years ago and I did some minor work for him, via email (I never met him so don't go all crazy and ask for details) and was paid very well, considering it was research for a book.
Patrick's a pretty sharp guy but he outsources a lot of his research to proffesionals (makes sense) and has several staff people help him put the pieces together, as it were.
I offered my services as part of the FTEST (final tech editing service team) but Patrick didn't want a publishing pundit as much as he was looking for computer pundits. Ah well, at least now I'm in his rolodex and hopefully I'll get more chances to work with him.
Warmest regards,
--Jack
When I really need a program I'll turn to Python or C, but 99% of the time when I just need to get something done grep, find and a knowledge of regular expressions does the trick.
Throwing in a bit of sed handles most of the rest.
The power inherent in these simple tools is really quite amazing and knowing how to use them means I've never had to upgrade from my 486 laptop.
The only real downside is a need for at least a practical understanding of formal logic and set theory and some people are agin that.
Takes all kinds I guess.
KFG
Hold on a damn minute... It's quite possible to write a virus in Bourne shell script, also. A virus that not only infects other shell scripts, but binaries as well. I know this because I did it as a project for a course in college.
Just goes to show you can do damn near anything in shell script.
No, I won't explain how it's done -- if you can't figure it out on your own, you're too stupid to handle the knowledge responsibly :-)
Is it coincidence that the quote at the bottom of this page currently is:
"It is easier to port a shell than a shell script." -- Larry Wall
?
And, after all, the article said that the book focused on /bin/sh, not bash.
/bin/sh. That's why startup scripts are written in /bin/sh - because it's always there.
And every unix system has some sort of
But these days as soon as I need a conditional or a loop I start thinking about doing the task in Perl or Python. These languages are so much easier to read and let you fork a process if you need to dip down into the shell.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology *) still has uses.
*) is available.
It's new years eve, wine made me do the grammatcal/semantic error.
And thanks, anonymour moderator, for the "troll" moderation. Want to silence any discussion that touches too close to the home, right?
Save your wrists today - switch to Dvorak
What exactly is more powerful and less fragile about Python in comparison to a sh script?
If you are serious, you need to freshen up your computing skills a little bit. Shell scripts tend to fail in unpredictable ways, often with no clue what went wrong. Python script raises an exception that immediately tells where the problem is.
Programming languages are for writing programs to do things, sh scripts are for tying things together in an automated way.
You don't realize that things have changed from the time sh was developed. Better languages for the job exist now. Some of us can recognize superior technology - others repeat obsolete tautologies like mantras, with zero understanding of technological realities.
Python is a nightmare to do nearly anything complex with for me.
I'm not sure what that sentence means.
It requires way too many dependencies, is less reliable than good old "${SHELL}", and typically requires more overhead from my CPU and memory.
I'm not sure what kind of boxen you work with, but they certainly sound pretty broken and underpowered. Buy some p5, they should go for pretty low prices these days and have enough power to run these "heavy" tools.
Happy New Year, troll.
I think this underlines your mentality. Mod down and flame, instead of sticking to technical issues. The technical points you present sound pretty childish to me, and showcase a profound lack of understanding of the issues involved w/ complex systems. You should really catch up w/ the times, or be buried w/ the obsolete Unix boxen you currently maintain.
BTW, if I notice something postworthy I post w/ my real name and skip moderation. Disagreeing with someone doesn't mean it's a troll.
Save your wrists today - switch to Dvorak