Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Unix Books Media Operating Systems Software Programming Book Reviews IT Linux Technology

Unix Shell Programming, Third Edition 292

Posted by timothy from the 10-hold-up-to-ear-20-goto-10 dept.
honestpuck writes "Back when dinosaurs roamed the earth and NCR made Unix computers I first started to program for a living. Back then when someone said 'script' they meant a shell script, generally for a Bourne shell." Even if the definition of "scripting" has grown somewhat, honestpuck argues, the old meaning still has merit and use. Read on for his review of the latest edition of Unix Shell Programming.
Unix Shell Programming, Third Edition
author Stephen G. Kochan and Patrick Wood
pages 406
publisher SAMS
rating 8 - Well written, good topic coverage, some small flaws
reviewer Tony Williams
ISBN 0672324903
summary Good introduction to shell programming and using the shell

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.
This discussion has been archived. No new comments can be posted.

Unix Shell Programming, Third Edition More

Unix Shell Programming, Third Edition

Comments Filter:

  • Shell scripting is a Lost Art (Score:3, Insightful)

    by Saeed al-Sahaf ( 665390 ) on Wednesday December 31, 2003 @01:12PM (#7846124) Homepage
    Shell scripting is a Lost Art. You know the True Gurus in the IT department by how comfortable they are with shell scripting. And of course, in the world of Microsoft, now one knows what you're talking about when you talk about scripting, they assume VBScript (the language of virii).

    • Re:Shell scripting is a Lost Art (Score:4, Interesting)

      by MoonFog ( 586818 ) on Wednesday December 31, 2003 @01:15PM (#7846149)
      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.
      • if I recall correctly, the plan for Longhorn is to be able to do ANYTHING from commandline. If it can be tweaked in a GUI, there's a shell command that will do the same thing.
    • 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.

      Ta
      • 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.

        Those can usually be done on a single pipeline. Some people insist on using multiline shell scripts to do the trick.
    • There's a lot to hate about VBScript, but has good points. VBScript/WSH has a lot of hooks to the Win32 guts, and comes pre-installed on all your machines.

      BTW, you can't honestly tell me you ENJOY programming in straight bash?!?!?
    • when you talk about scripting, they assume VBScript (the language of virii).

      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 :-)

    • Re:Shell scripting is a Lost Art (Score:5, Informative)

      by rmdyer ( 267137 ) on Wednesday December 31, 2003 @02:38PM (#7846966)
      In my mind shell scripting sits at the highest level of process control. You are basically working above all other methods to control your machine with a thin and light interface. In shell scripts, you typically start and stop processes, check for active processes, log information about processes, control the flow of or filter process data. You also work directly with files on the file system by checking for them, moving them, renaming them, deleting them, appending to them, etc. In short, shell scripting is exactly what it says it is...scripting what you would otherwise do by hand at the shell prompt.

      Shell scripting usually trumps all other programatic languages in that the engine is so small. That allows it to start up and shutdown really quick, not like the bloated Perls, Pythons, Java's, VBs, etc. A typical shell script engine might use about a Meg or less. Shell scripting is not programming in the strict sense of the word. You are not working in a well structured and cohesive language to be used for a variety of application development. No, shell scripting was made primarily for process and file system management. Making shell scripting work much beyond those means is an art, and not something that should ordinarily be done because other better languages should be used to fulfill broader purposes.

      In our Windows environment we use CMD.EXE, or the command shell engine for just about all of our network control scripting. It comes with Windows, and is the only standardized default shell console. The command shell of NT/2k/XP is NOT your fathers BATCH language. Microsoft made some extensive professional changes to the command shell engine starting way back with Windows NT 3.51. The command shell is now very functional and has many Bourne shell syntax features.

      Microsoft hasn't promoted the use of the command shell until very recently. This is because early on, they wanted to push system programmers and admins into using their GUI tools and VB scripting languages so that you would have to buy other products. Microsoft really pushed people away from using command shell scripting for the purpose of their own gain. Recently, with the gowing popularity of Linux and Unix again, they are now pushing to get people to use the command shell. They've finally documented most of the many changes they've made to the shell over the years, those changes that were kept in secret to all but the most diehard shell users.

      The most popular changes come with the following commands...

      CALL, GOTO, EXIT, FOR, and SET.

      These commands have been expanded for the development of subroutines, string manipulation, math functions, tokenizing, file system recursion and enumeration. The command processor is fairly powerful in its own right because you don't have to exit very much for externals like FINDSTR, or SED/AWK type executables.

      Under NT/2k/XP if you are using the ".BAT" extension for your scripts, or the "COMMAND.COM" processor, then don't. These are now outdated. If you fire up command.com, the the 2k kernel must startup the 16 bit virtual dos machine (VDM). This is S-L-O-W, and the BATCH language is indeed very poor. You should now use the ".CMD" extension for your command shell scripting.

      See the following for more command shell (cmd.exe) documentation...

      Command Shell Docs [microsoft.com]
      • hood stuff. however, using the '.BAT' extension on NT doesn't cause a VDM to be started. unless, of course, you associate '.BAT' with a 16-bit executable like command.com, but by default it's associtaed with 'cmd.exe' which is a regular win32 console app.
        • You are correct. The command shell has backward compatibility with the ".bat" extension. Just for separation, I personally use ".bat" for strictly older command.com stuff and ".cmd" for command shell scripts. However, I also don't change the association, so yes, most of the application ".bat" scripts startup using the command shell.
    • Yup, you can tell the True Gurus in a MS-based IT department by how comfortable they are with WMI scripting. (of course, most of them will also have the cygwin tools installed for piddling around with text files).

  • This raises an interesting question... (Score:2, Insightful)

    by Anonymous Coward
    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.

    Now that machines are getting much faster, can we expect shell scripting to be totally forgotten and unused? Are there movements for this already?
    • A shell script for me automates things I could do by hand. For instance to start apache properly I need to do a number of things. Check if I want to start or restart or reload config. Also if apache is already running and if not why not. Then to see if my command is actually carried out. Etc etc etc

      All of these I can do by hand and on machines where the scripts are borked I do. I then replace the IF WHEN WHILE bits of the scripting language with my brain. In fact that is how I write scripts. I write down i

    • Generally, fast computers are used as an argument _for_ scripting languages; for a lot of things, shell scripts are still preferable to Perl/Python/etc 'cuz with shell, running external programs is very natural; there's no function calls and whatnot involved.
  • Froogle Link [google.com]
    Amazon Link [amazon.com]

  • SCO (Score:2, Funny)

    by Gilesx ( 525831 ) *
    Maybe Darl could give a free copy away with every SCO-Linux license he sells....

  • Default shell? (Score:5, Informative)

    by christurkel ( 520220 ) on Wednesday December 31, 2003 @01:16PM (#7846155) Homepage Journal
    As the risk of being flamebait here, Bash is not the default shell on *BSDs (Is this the reason its dying?), its tsch. Neither is it the deault shell on QNX (ksh is). Perhaps the statement that bash is the default shell on most system seems overly broad.

    • Re:Default shell? (Score:5, Funny)

      by morelife ( 213920 ) <f00fbug&postREMOVETHISman,at> on Wednesday December 31, 2003 @01:23PM (#7846231)
      The csh/tcsh default in freebsd is a mystery.

      When bash is ultimately so much more feature ridden than tcsh/ksh. Ok, just my observation/opinion.

      But since bash is the default shell in Linux, and there are probably more linux systems than any other unix-like platform on planet earth, I vote that bash become earth's default shell.

      Windows' default shell can probably be considered either Symantec or McAfee Anti Virus.

    • Perhaps the statement that bash is the default shell on most system seems overly broad

      He said Bourne (sh), not Bash. I'm don't agree that his statement is overly broad, Bourne is the default shell on the greatest number of installed systems. Most admins work on systems where Bourne is the default shell.

    • Re:Default shell? (Score:2, Informative)

      by ogre57 ( 632144 )
      .. the statement that bash is the default shell on most system ..

      Appears we interpret this differently ..

      .. chosen to use the POSIX standard Bourne shell ('bash', available on many *nix systems, is a superset of the POSIX standard).

      I read that as stating they chose the original Bourne shell, eg /bin/sh, with an aside (for Linux folks?) that bash is a superset of sh.

    • Not the default shell on Solaris either. But it should be !
    • The Borne Shell is what I would call, The Mother of All Shells. Other shells (ksh, bash) are usually a superset of /bin/sh. Csh (and its ilk) is another beast entirely, but I never really considered it a REAL shell for doing programming in.

      Basically, if you have a *NIX like system, you are pretty much guaranteed to have a /bin/sh, and it will always work the same. Bash is common, but not universal. Ksh is proprietary, though there are open source versions (pdksh), but you won't find it everywhere. Csh

  • Shell scripting is great, even in Windows! (Score:4, Informative)

    by simetra ( 155655 ) on Wednesday December 31, 2003 @01:16PM (#7846161) Homepage Journal
    I use shell scripts for many things under Windows using the free version of many Unix utilities found HERE [sourceforge.net]. Scripts are fast, and don't break (short of being over-written). Many times, scripts can be written that perform the functionality of expensive Windows programs, with the advantages of being free, not easily broken, and not subject to dll version issues, continual upgrades, etc, etc, etc.

    Shell Scripts are really The Cat's Pajamas.

  • Oldie, but goodie differences ... (Score:5, Interesting)

    by pgrote ( 68235 ) on Wednesday December 31, 2003 @01:17PM (#7846169) Homepage
    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. [faqs.org]

    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.
    • Here's a script for that nicely written post. Happy New Year!

      GET http://www.perfidious.org/award|\
      sed '1!G;h;$!d'|sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//'|\
      write `whoami`

  • The Land of the Lost (Score:3)

    by RevMike ( 632002 ) <revMikeNO@SPAMgmail.com> on Wednesday December 31, 2003 @01:19PM (#7846183) Journal

    Back when dinosaurs roamed the earth and NCR made Unix computers

    I used to work on an AT&T 3b2. I can also script pretty well in DCL. Does that make me a sleestak?

    Extra points for anyone younger than 30 who can prove they actually know DCL. Demonstrate something good - maybe set up IPC using mailboxes or something.

    • I was just mourning the fact that the internet wayback machine's archives didn't include the collection of VMS .COM files I had set up on our campus's VMS cluster. (Running OSU's webserver for VMS)

      Unfortunately, it's almost all left me, though I suppose I could still puzzle out the quoting rules to pass quoted arguments down three levels of @-signing. (Doubling the quotes each time...)

      And hey, _I'm_ still under thirty (for two more years...)
    • Demonstrate something good - maybe set up IPC using mailboxes or something.

      10 years ago I've created document-oriented transactioned RPC based on Sendmail, Procmail, PGP, and Shell scripting (and OraTCL). It was secure and reliable on very unreliable phone lines (ever connected with 1200 bod ?). Does it give me any points? :)

  • Or, for the free speech *and* beer people (Score:5, Informative)

    by Zocalo ( 252965 ) on Wednesday December 31, 2003 @01:25PM (#7846243) Homepage
    The LDP includes the "Advanced Bash-Scripting Guide" which is available in both HTML [tldp.org] and PDF (1MB!) [tldp.org] formats, and there is even a version for PalmOS! Since I found it, it's been the only reference I've *ever* needed when I've stumbled over some obscure nuance of shell scripting.
    • I tried reading Advanced Bash-Scripting Guide.. well, you're right. It's a reference. No good for learning about scripting.

      Can anyone point me to something (other than the reviewed book) I can read to learn about shell scripting?

      • I tried reading Advanced Bash-Scripting Guide...

        Not too closely it appears, since as it says in bold on the front page "the only way to really learn scripting is to write scripts". It's right. There seems to be a view amongst people who "can't" write shell script that it needs to be taught which is utterly wrong. It is not an arcane programming language like C for crying out loud; it's the commands you use at the command line *every* day, unless you are entirely reliant on a GUI.

        The only major diffe

        • Hi there. Do you need help down from that soapbox? ;)

          Yes, shell scripting seems obvious, I would have just liked something less intimidating than an A-Z reference (maybe a limited subset that just covers the bit you need to get started).

          Advanced Bash Shell Scripting conveniently glosses over somethings like how variables work in a Bash script and so on. (or at least, if it's there it isn't well explained).

  • I did some work for him on this book (Score:3, Interesting)

    by Jack Wegnar ( 736840 ) on Wednesday December 31, 2003 @01:29PM (#7846287) Homepage Journal
    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

  • Download scripts and errata here (Score:5, Informative)

    by Helevius ( 456392 ) on Wednesday December 31, 2003 @01:30PM (#7846293) Homepage
    You can download their scripts and fixes for the text at http://www.kochan-wood.com/ [kochan-wood.com].

    The one Amazon.com [amazon.com] review gave this book 4 stars.

    Helevius

  • Shell scripts (Score:5, Insightful)

    by RealProgrammer ( 723725 ) on Wednesday December 31, 2003 @01:31PM (#7846302) Homepage Journal

    I make my living as a Unix sysadmin, to support my hobby as a Real Programmer :-p.

    Without shell scripts, I'd be lost.

    Shell scripts provide the ability to leverage the work of every well-behaved perl (etc.) script, binary in /bin, and other shell script ever written. While the same can be said for perl scripts (which I happily use or write when needed), with shell scripting this is the intended paradigm.

    Scripts are intrinsically open source, even if copyrighted and under a closed license. The techniques are visible, and thus instructive.

    Given Unix's design attribute of easy process creation, shell scripting is often the best way for me to handle a task.

    See some examples here [healconsulting.com].

    • Scripts are intrinsically open source, even if copyrighted and under a closed license. The techniques are visible, and thus instructive.

      Ok, slowly: notice the use of lower case in "open source". Notice the next sentence, which talks about techniques being instructive. Copyright does not disallow copying verbatim into your head. Once in your head, you can examine it any way you wish. You can even write it down. You just can't let someone else have a copy.

      But the point about techniques being ins

  • The quote for this page when I loaded it:

    "It is easier to port a shell than a shell script." -- Larry Wall

  • Really the better one is this one: (Score:3, Informative)

    by funwithBSD ( 245349 ) on Wednesday December 31, 2003 @02:07PM (#7846652)
    UNIX(r) Shell Programming, 4th Edition [amazon.com]


    Of the same name, not related. Go figure. I got both and the one above is the better of the two, IMHO. Chapter 5 of this one is golden, lots of simple tables covering built in operaters, varibles, and control structures.

    I really did not GET programming until the book above, it made it click for me. Perl came right after, as this got the concepts in my thick head.

    A shell-less admin is a useless as a mermaid, and not as pretty to look at.
  • 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
    ?

  • Not such a great option these days (Score:3, Interesting)

    by imnoteddy ( 568836 ) on Wednesday December 31, 2003 @02:12PM (#7846716)
    I've done shell scripts for over two decades now. Did a one liner two days ago that checks on my bus and uses Mac OS X text to speech to tell my whether the bus is on time. It's amazing sometimes what you can do piping stuff through grep, awk, sed and so on.

    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.

  • Another good book (Score:2, Informative)

    by rsmith ( 90057 )

    And free as in beer:

    Advanced Bash-Scripting Guide [tldp.org]

  • Aaaauuugh! NCR! (Score:3, Funny)

    by ThesQuid ( 86789 ) <a987@@@mac...com> on Wednesday December 31, 2003 @03:23PM (#7847468) Journal
    Please don't mention NCR! It's been almost 3 years since I quit as a field engineer and I still have nightmares...
  • language has not changed noticeably in twenty five years and should not change in another twenty five

    Is this a good thing? I mean don't we sometimes have to abandon the ideas of old in order to progress? How has English evolved over the past 50 years? Besides the branch of American English and the ones the UK speaks and writes. Maybe not much but how about 300 years? As technology progresses further than a Moore breaking speed should the language not evolve as well?

    I agree that Unix language is so
  • Steve Bourne [steve-parker.org] calls them shell procedures not shell scripts. I figure since he created the shell named after him, he should know. So I call them that too.
  • Maybe a good example of how shell scripting can be made to good use is smartadmin, which i wrote during a weekend :

    ftp://ftp.crashrecovery.org/pub/linux/smartadmin/ [crashrecovery.org]

    smartadmin - Create/Edit/Remove a UNIX/Linux user and/or a Samba user.

    smartadmin was created out of sheer misgrief about total contra produc-
    tive effects of packages like webmin, requiring rediculous resources to
    perform basic user administration on a UNIX/Linux and Samba server. The
    requirements for smartadm

  • My mantra (Score:2, Insightful)

    by jjgm ( 663044 )

    When the Junior Unix Sysadmin comes to me, as they do, and asks "what language should I write this tool in?", here is my decision sequence:

    • shell (with sed/awk/grep) for process management/job control and line-by-line text processing.
    • C for servers, time-sensitive applications, interfaces to syscalls.
    • Python or Ruby for complex system tools that benefit from an object model.
    • Perl for text mangling. I know; Perl can do anything, and often it's the fastest to write. But as the corollary has it: in Perl

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Close