Follow Slashdot blog updates by subscribing to our blog RSS feed

 



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

Wicked Cool Shell Scripts 569

norburym writes with a review of Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems. "This incredibly fun book (really!), written by Dave Taylor, a veteran UNIX, Solaris and Mac OS X author, is chock full of 101 scripts to customize the UNIX (Bourne) shell." Read on for the rest.
Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems
author Dave Taylor
pages 368
publisher No Starch Press
rating 10
reviewer Mary Norbury-Glaser
ISBN 1593270127
summary 101 Scripts for Linux, Mac OS X, and UNIX Systems

Chapters are divided into an array of topics sure to catch the attention of any UNIX based system user: The Missing Code Library, Improving on User Commands, Creating Utilities, Tweaking Unix, System Administration: Managing Users, System Administration: System Maintenance, Web and Internet Users, Webmaster Hacks, Web and Internet Administration, Internet Server Administration, Mac OS X Scripts, and Shell Script Fun and Games.

In true "cookbook" fashion, each hack is numbered and divided into The Code, How It Works, Running the Script, The Results and Hacking the Script. Throughout, the author clearly describes the syntax and functionality of each script, often with additional notes in How It Works detailing the syntax process and interesting asides. But Hacking the Script is what gives Wicked Cool Shell Scripts true value; where applicable, the author uses this section to describe script modifications to achieve a variety of alternative real world, practical results. This additional section alone easily triples the total number of scripts the reader is exposed to.

This book enables the reader to get "up close and personal" with their UNIX based system and explore the possibilities afforded by becoming intimate with the command line interface. The reader will find themselves easily propelled into the world of scripting, thanks entirely to Dave Taylor's ability to take what some might describe as a fairly dry topic and translate it into a logical and user friendly construct. Just reading through the table of contents is inspiring and intriguing; did you know you could write a script to retrieve movie info from IMDb? or track the value of your stock portfolio? or that you can use a very simple script to check spelling on your web pages?

Sysadmins and webmasters will find this book fundamentally critical to day-to-day operations; there are dozens of invaluable, customizable scripts highlighted in this book to enable professionals to save time and add simple, elegant solutions to annoying issues in their work environment. User account management, rotating log files, cron scripts, web page tweaks, apache passwords, synchronizing via ftp, etc. are all eminently useful and tweakable.

Geeky home users will discover they can use these scripts to work with files and directories, create spell-checking utilities, calculate loan payments, create summary listings of their iTunes libraries, and of course, play games. Many of the sysadmin scripts would also be of interest to the power user: analyzing disk usage, killing processes by name and backing up directories, to name a few. Both types of users will find this book inspiring and truly fun!

One of the secret pleasures of a technical book reviewer is finding those wonky bits of code that suffer from misplaced or missing punctuation, misspelled words and other basic typographic errors inherent in the book publishing process. I randomly selected many of these scripts to try out in the process of doing this review and...dang, haven't found any errata yet. But be sure to check out the errata page on Dave Taylor's web site for any that more astute readers may find (there were none, as of this writing).

Also be sure to take a closer look at Dave's shell script library, which lists additional scripts that didn't make the cut for the book. As convenient as it is to download the entire script library, I would like to stress the value of buying the book, which will provide you with invaluable instruction and guidance in understanding the syntax of the scripts and it also illustrates how making small but significant tweaks can modify the output to match your specific needs.

(A special nod of appreciation to Dave Taylor's Tintin references!)


You can purchase Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Wicked Cool Shell Scripts

Comments Filter:
  • by Anonymous Coward on Wednesday March 10, 2004 @03:03PM (#8523555)
    "Wicked cool" and "Windows" just don't go together....
  • by robslimo ( 587196 ) on Wednesday March 10, 2004 @03:05PM (#8523581) Homepage Journal
    ...everything looks like a nail

    Actually, I agree that shell scripting is a powerful tool and well worth understanding. But 'a loan calculator' script? Gee, once you know the formula, a coupla minutes in a spreadsheet will do the trick.

    I guess all people, myself included, fall into the hammer/nail trap. I know C very well, so I use it for just about every little app. Hmm... maybe I oughta buy this book.

    -RatOmeter
  • Webmasters?? (Score:3, Insightful)

    by Vo0k ( 760020 ) on Wednesday March 10, 2004 @03:06PM (#8523601) Journal
    ...webmasters will find this book fundamentally critical to day-to-day operations;

    What webmaster uses SHELL scripts?!

    I understand, PHP, Perl, some other CGI. Marginal use for scripts for log analysis, maybe some file management, making their own work a bit easier.
    But shells were never meant to do any web work. They are too slow, too heavyweight, too vulnerable to abuse by malicious users to be used as server side extensions!
  • by Anonymous Coward on Wednesday March 10, 2004 @03:06PM (#8523607)
    Gee. This book must cater to Solaris users.. or some other *NIX not blessed with a killall command.
  • RTFT (Score:2, Insightful)

    by Anonymous Coward on Wednesday March 10, 2004 @03:07PM (#8523624)
    Wicked Cool Shell Scripts
  • Re:Webmasters?? (Score:3, Insightful)

    by ADRA ( 37398 ) on Wednesday March 10, 2004 @03:11PM (#8523667)
    The reviewer said Day to day operations, not implementation.

    I don't believe that the reviewer ment that the scripts were being used for a web site, but as a tool for automating web site administration.
  • by happyfrogcow ( 708359 ) on Wednesday March 10, 2004 @03:21PM (#8523782)
    I haven't seen or read this book, but my first impression from reading the review is that it's just a book that lists some shell scripts. There's no real challenge. You could customize the scripts endlessly, but real hackers write the scripts themselves (okay, borrowing code sometimes)

    So what? I just bought a cookbook on sauces. What's different? Maybe I like a little more garlic in most my sauces so I'll throw some in here and there. Most of the sauce recipes, i would have never have thought to go with something I usually eat. Why does there need to be a "challenge"? It simply makes my meal more enjoyable.

    Having 101 shell scripts that I can tinker with and add things that I like, or use them in a way that makes using my computer more enjoyable is great!
  • by Anonymous Coward on Wednesday March 10, 2004 @03:26PM (#8523841)
    perl thrashes and crashes trying to crunch seriously large amounts of data.

    the stuff in /bin and /usr/bin are usually written in C and often quite robust. at least if it's GNU. Solaris "awk" and "fgrep" and SGI "ls" are pieces of crap.

    perl is good for using when you have smaller amounts of data and can't quite do it with sed/awk/ls/grep/sort. it is especially good with "associative arrays" (most people call them "hash tables").

  • Re:Why shell? (Score:5, Insightful)

    by ComputerSlicer23 ( 516509 ) on Wednesday March 10, 2004 @03:27PM (#8523849)
    Last time I checked, /bin/bash is on the / partition, and perl is either on /usr/bin/perl, or /usr/local/bin/perl.

    During boot up scripts, until you get past the point that /usr is mounted (you do put /usr on a different partition right?), you can't use anything. That's how you determine what goes on /bin and what goes in /usr/bin (well mostly). When things go wrong, and you need to recover, trying to fix things on a busted machine, is much more reliable if you are using shell then perl (it's got a smaller foot print, and it's not an intertangled mess of libraries).

    Intertangled messes of libraries are a great thing when you are developing. They are a beast, if things are broken. What if you fsck can't finish because part of the library is dorked. Thus you can't mount the filesystems you need to use to fix the problem.

    During boot up, you want to use the easiest, and most reliable method of booting. Shell scripts are probably better off then perl scripts. It's easy to have readable, reliable shell scripts with scoping, it's just not something you are used to doing apparently.

    Besides all that, you'd spend all your time in perl doing exec/fork/system. The /bin/sh is more efficient at doing that then perl is (in terms of code, if not runtime).

    Kirby

  • by mekkab ( 133181 ) * on Wednesday March 10, 2004 @03:32PM (#8523907) Homepage Journal
    Please, DON'T.

    Why? If I know awk better than PERL, its a much better idea to use AWK.
    Vice versa.

    P.S.- At two different points in my life I did serious perl scripting. Now, I can't remember a darn thing. Awk looks like C. So these days, I use awk. Different strokes for people with different amounts of brain power/memory.

    And some scripters tend to be just as zealous about the power of scripting as perl mongers are about perl!
  • by Anonymous Coward on Wednesday March 10, 2004 @03:34PM (#8523923)
    Shells tend to be statically linked and available as soon as the root file system is mounted.

    Try getting to anything in NFS when running in single-user mode.

  • by sporty ( 27564 ) on Wednesday March 10, 2004 @03:44PM (#8524033) Homepage
    shell == programming langauge...

    'cause every executable becomes a function which you pass params and get return values, if you want to.
  • by Anonymous Coward on Wednesday March 10, 2004 @03:46PM (#8524049)
    No FePe, that's not how it works. REAL hackers follow conventions. Hacks just wing it on their own. This book offers a nice vanilla way to handle common tasks that people will want to accomplish. The user can take it from their to customize it to his or her actual needs. Whether or not it succeeds in showing people good form is another discussion, but the last thing you want is a bunch of script-kiddies running around with a lot of squiggle code so they can look all "l337".

    --
    There's nothing like a good AC reply on Slashdot... and this was nothing like a good AC reply.

  • by frodo from middle ea ( 602941 ) on Wednesday March 10, 2004 @03:48PM (#8524061) Homepage
    Yes but you are missing a big point here.

    The programming languages like C, C++, Java etc, are strongly typed languages and the compiler will give you sufficient information to correct your incorrect syntax problems.

    So even when you switch from say C++ and Java, with a little common sense and reading the compiler errors and warnings you can easily pick up java syntax, keywords etc.

    But with scripting languages it is not so, as they are not compiled. This is especially a headache when you are dealing with multiple unix machines having differnet shells.

    I once worked at a job where I had to use , csh (c-shell) , sh (original bourn shell) , ksh ( korn shell ) and bash (bourn shell ) on different linux, solaris and HP-UX boxes. It was a real headache maintaining the scripts.

    All these scripts differ quite a lot in syntax , especially for arethmatic, redirects , invoking sub shells , comparision operators etc.

    What is needed is a good shell cross referencing manaul which will provide comparative features of at least the major shells like , bash , sh, ksh, csh, tcsh , zsh.

  • by guacamolefoo ( 577448 ) on Wednesday March 10, 2004 @03:53PM (#8524116) Homepage Journal
    ...but grandma didn't need no stinking cookbook and her sauce kicked ass.

    Yeah, and she only knew how to make a couple of kinds of sauce. Even a master chef needs a cookbook. Or a hundred.

    The whole "real hackers do it themselves" argument is crap. No man is an island, and we all learn something from others. If someone wants to be an elite h4x0r d00d, does he have to be raised like a veal in front of a computer with nobody to tell him how to turn the fucking thing on?

    The whole point of networks is to share knowledge. If you don't try to build and add to that knowledge, then you are a free rider, and you are land and annoying. If you take the knowledge you can find easily and extend it or use it in a new, fun, or productive way or in an unexpected context, then you are doing what, IMHO, "hacking" is all about.

    Taking an elitist "I am uber h4x0r, and I did it all by myself!" attitude is alienating and contrary to my notion of what hacking should be about. It's also bullshit. Even Torvalds had help. Going the reductio ad absurdum route, if you didn't write your own OS, then you are just a lamer according the lone wolf hacker theory. JFC.

    GF.
  • by jlusk4 ( 2831 ) on Wednesday March 10, 2004 @03:55PM (#8524139)
    I use 'em both. Start-up costs for writing shell scripts are a lot less. No 'FileHandle->new("blah") or die'. No '$rc = system( $cmd); if ($rc >> 8) {die}'.

    quick-n-dirty hack and/or small script that will grow ==> shell. Yes, I know perl can be quick-n-dirty, too, but then what's the point? I'd rather read shell q-n-d than perl q-n-d line noise.

    complex stuff (like parsing html/xml), and/or something that might get complex in future ==> perl

    John.
  • Re:Why shell? (Score:3, Insightful)

    by Moderation abuser ( 184013 ) on Wednesday March 10, 2004 @04:01PM (#8524184)
    Because of Perl versioning problems. Half a dozen different versions on a single platform.

    Because Perl exists in random locations.

    Because a particular Perl installation will have random modules installed.

    Because Perl is not on *everything*.

    Because writing a shell script take a fraction of the time a Perl script takes.

    Because Perl encourages monolithic scripting.

    Perl has tried so very hard (and suceeded) to become a fully featured programming language, it hasn't been suited to small scripting tasks since version 4.

  • by unixbob ( 523657 ) on Wednesday March 10, 2004 @04:04PM (#8524218)
    Surely the point of books like this is not to show you how to write a shell script which lets you calculate interest payments, but to show you how to write a script with integers and maths calculations in. And to do that in an interesting way. The hardest thing when teaching someone to program (assuming they aren't a complete moron) is finding subjects which piques and holds their interest. I bet most people who read the review didn't think "wow, I can use a shell script to calculate my interest payments instead of MS excel" but instead thought "neat idea"
  • by Moderation abuser ( 184013 ) on Wednesday March 10, 2004 @04:09PM (#8524265)
    It just doesn't do quite what you might expect if your only experience is Linux.

  • Re:sounds cool (Score:4, Insightful)

    by jafac ( 1449 ) on Wednesday March 10, 2004 @04:12PM (#8524293) Homepage
    It's because you have to be creative to solve problems. Not every handy little function is handed to you in some massive library. Sometimes, you have to do some really klugy, ugly things to get it to work. And that's fun.
  • Re:Why shell? (Score:3, Insightful)

    by pclminion ( 145572 ) on Wednesday March 10, 2004 @04:32PM (#8524563)
    If I was your boss, I'd want "scripts" and not "hacks," too.

    The real question is, was your 4 line shell script only 4 lines long because it really was that simple, or was it because, as you say, it was a "hack?"

    I'll take 10 lines of code I can understand over 1 line I can't, any day of the week.

2.4 statute miles of surgical tubing at Yale U. = 1 I.V.League

Working...