Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Bash Cookbook 278

Chad_Wollenberg writes "Anyone who has used a derivative of Unix over the past 20 years has used Bash, which stands for Borne Again Shell. The geek in all of us makes us want to extend our ability to rule the command line. To truly master a Unix environment, you need to know a shell, and Bash is easily the most popular of them. Any Unix/Linux/BSD administrator knows the power at your fingertips is fully extended by what you can do within the Bash environment, and all of us need the best recipes to get the job done." Keep reading for the rest of Chad's review.
Bash Cookbook
author Carl Albing, JP Vossen, Cameron Newham
pages 598
publisher O'Reilly
rating 9
reviewer Chad Wollenberg
ISBN 978-0-596-52678-8
summary A good book for intermediate and above users of Bash
Enter Bash Cookbook. Properly named for the series of O'reilly books that gives you valuable information on subjects in the form of recipes, this book was refreshing in that it was properly organized, and surprisingly contemporary, even citing Virtualized platforms as a way to try out different OS's for Bash. The book does a good job of pointing out the different operating systems that do run Bash, even citing Cygwin for Windows. They also use the POSIX standard, so that all of the examples are portable across platforms.

Bash Cookbook is by no means for the feint of heart. It seems that the book is meant for intermediate and above users of Bash. However, the first several chapters do a significant job of over viewing basic concepts of Bash navigation and combing simple commands. The book quickly changes gears to complex statements on how to get things done in Bash.

By Chapter 7, Bash Cookbook extends out of Bash commands and begins exploring combining the power of bash scripting with useful command such as grep, awk, and sed. To quote the authors, "if our scripting examples are going to tackle real-world problems, they need to use the wider range of tools that are actually used by real-world bash users and programmers." And that is exactly what they do. This chapter alone gave me the ability to do more in the command line environment simply by explaining the functions of the scripts put forth. That is something that any reader, intermediate to expert, can take from this book. The detailed explanations really do give everyone the ability to learn something about the commands, and the references to additional resources often lead me to the computer, looking up further details.

I found Chapter 11 to be very useful (pun intended) finally grasping some concepts on the find command that have previously escaped me. From Chapter 12 on, the book focuses on writing useful and complex scripts. This is where the book really begins to shine for the Unix enthusiast and system administrator. The scripts found in Chapter 12, and their elaborate descriptions begin to show the true power of Bash scripting, and how much you can automate. Chapter 14 is about securing your scripts, and is a heavy read, but well worth reading for any administrator that would be using their scripts in a production environment.

Just when you think this book has reached its limits, it gives very handy customization examples in Chapter 16 on how to configure and customize Bash. And also goes into common mistakes made by the novice user. Combine all of that with the Appendices for quick reference, and this book has not left my side since it arrived. While I would not recommend this book for the novice user, I would recommend this book to any system administrator that has to work with Unix or Linux. If nothing else, the examples given here are full of good, reusable code to make tasks easier in your day to day functions. Well done.

You can purchase Bash Cookbook from amazon.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.

Bash Cookbook

Comments Filter:
  • by Jansingal ( 1098809 ) on Wednesday August 13, 2008 @01:09PM (#24587119)

    even though there is a lot of free info, some people like a hard copy of something.

    yeah, you could print the same info, but it is not bound, etc.

  • by john_anderson_ii ( 786633 ) on Wednesday August 13, 2008 @01:18PM (#24587321)
    Bash is just plain awesome, I'm always trying to find ways to push it even further, I'm checking to see if this book is on safari right now.

    I do a lot of work in bash. I'm a Linux administrator by trade, so I think in bash all day long. For my company I've developed a set of bash libraries that we call the BPE. These libraries implement a hashmap, stack, linked list, MySQL API, SQLite API and all sorts of other useful things that one doesn't want to re-invent for every script. I'm in the process of writing man pages for the several libraries right now, and I think I'll sourceforge the project when the mans are complete. It's great to be able to begin a new script when a hashmap might be useful, and be able to do something like:

    use "hashmap"

    hm_create "myMap"
    hm_set "myMap" "key" "value"
    value="$(hm_lookup "myMap" "key")"
    echo "$value"

    In short, if organized correctly, bash can be used where a senior sysadmin would normally reach for perl or python. This is often helpful when your juniors have a good grasp of bash, but aren't very strong in other languages.
  • by Animats ( 122034 ) on Wednesday August 13, 2008 @01:26PM (#24587475) Homepage

    598 pages for a book on a shell? Oink!

    A little plastic cheat sheet would be far more useful. The important thing is to get the basic ideas and the syntax. That requires a small, tightly written book. In an oinker of a book, the concepts get lost in the verbiage.

  • by dfn_deux ( 535506 ) <datsun510 AT gmail DOT com> on Wednesday August 13, 2008 @01:28PM (#24587501) Homepage
    An interesting observation, which also points out something that I noticed in the review text. He says that all the scripts in the book are "POSIX" compliant, but AFAICT bash extends the POSIX standard bourne shell "/bin/sh" with a bunch of features which are not part of the posix standard. Calling bash from a "sh" symlink starts bash in POSIX compliance mode wherein it acts exactly like a standard bourne shell. It seems if the book has strictly POSIX friendly scripts that it isn't really a bash book so much as it is a bourne shell book.
  • by CastrTroy ( 595695 ) on Wednesday August 13, 2008 @01:35PM (#24587649) Homepage
    The lack of structured data and live objects is a feature, not a bug. The fact that everything is a string, and that everything can be piped between all the different commands means that you can string together commands in new and exciting ways that nobody ever thought was possible. Making all the commands pass around different types of objects means that all the other commands have to be aware of all these other datatypes, and have to know how to handle them. If you want something with objects and structured data in the shell, then there's MS PowerShell. But maybe there's a reason it hasn't caught on yet.
  • by CastrTroy ( 595695 ) on Wednesday August 13, 2008 @01:40PM (#24587723) Homepage
    Maybe we should all have to buy different books on grep too. Why not separate books on dd, ls, df, free, etc? sed and awk are a very integral part of bashscripting. You can't talk about bash without talking about sed and awk. Same way you can't talk about Perl without talking about regular expressions. Well, on second thought, you could, but you'd be leaving out a huge part reason for using Perl in the first place.
  • by plasticsquirrel ( 637166 ) on Wednesday August 13, 2008 @01:55PM (#24587953)

    To truly master a Unix environment, you need to know a shell, and Bash is easily the most popular of them.

    Bash is a fine shell, but it's certainly not the standard on Unixen today. Most versions of Unix still have the Korn/Posix Shell as the most common shell. This is certainly true in Solaris, HP-UX, and AIX. The BSD's typically don't use Bash, and favor more traditional, light-weight shells. However, some versions may package Bash in their distributions.

    Bash is really only the common default shell on Linux, from what I have seen. Things learned for Bash have similar syntax in other shells, but teaching newbies that Bash is the standard shell is a very bad, Linux-centric idea that leads to Bash-isms (people trying to use Bash-specific features in other shells).

  • by CastrTroy ( 595695 ) on Wednesday August 13, 2008 @02:00PM (#24588075) Homepage
    I'm not sure where our opinions differ. sed and awk are both extremely powerful. bash is extremely powerful. One of the things that makes bash powerful is the existence of sed and awk. sed and awk don't require bash, and bash doesn't require sed and awk. Yet if you write a book on using bash, and leave out sed and awk, you would be doing your readers a great injustice.
  • by Sancho ( 17056 ) * on Wednesday August 13, 2008 @02:11PM (#24588225) Homepage

    That sounds pretty neat and all, but wouldn't you be better served training people on a language which has these constructs built in? The juniors are still having to learn new programming syntax--only instead of learning Perl, they're learning something that's not used anywhere else in the world.

    Is this a way of enforcing loyalty? :)

  • by HighOrbit ( 631451 ) on Wednesday August 13, 2008 @02:43PM (#24588791)
    The review says, "They also use the POSIX standard, so that all of the examples are portable across platforms."

    So if the book and examples limit themselves to the POSIX subset of bash's capabilities and don't go into the GNU extensions, is the book really about "bash"? It sounds like the book could be called "UNIX shell cookbook" (oops already done) or "Ksh Cookbook" just as much as "Bash Cookbook". But of course, bash is the Linux default and Linux is hot while Unix is passe.

    I always thought it was the gnu extensions above and beyond POSIX (while staying backwards capatable with POSIX) that make the gnu tools like bash and gawk so much (allegedly) better than ksh and awk.

    BTW, I use bash because it is the default on most linux systems so I am familiar with it. Bash is the very first thing I install on BSD or Solaris systems and then I set it as my login shell. It's actually really rare that I need to call on the gnu extensions, so I could probably be happy with pdksh just as well.
  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday August 13, 2008 @03:11PM (#24589181) Homepage Journal

    I loved Bash (and was the maintained of the FreeBSD port of the Bash tab-completion for a while), but gave it up forever about a week after I tried Zsh [zsh.org]. For me, it's like "Bash done right", from associative arrays for easy scripting to tab-completion that's fast and doesn't pollute the namespace with thousands of tiny functions:

    $ zsh
    $ set | wc -l
    $ bash
    $ set | wc -l

    Which leads me to ask: has anyone tried Zsh but then gone back to Bash? If so, why?

  • by hal9000(jr) ( 316943 ) on Wednesday August 13, 2008 @03:29PM (#24589455)
    You've ignored the fact that for any two tools to work together, their assumptions about the structure with which data is encoded over the stream have to match.

    Dude, it is upto the programmer to format the data properly, including any escaping when piping strings from one proggie to another.

    Shell scripts aren't supposed to replace more robust programming languages. I think it silly to want to parse XML via shell scripts, BUT, a shell script could pull useful data from an XML file.

    So let me state the obvious, find the right tool for the job rather than thinking everyones tries to shoe horn everything into the same tool.
  • by swillden ( 191260 ) <shawn-ds@willden.org> on Wednesday August 13, 2008 @03:33PM (#24589499) Homepage Journal

    That fact does cause a lot of problems with poorly-written third-party scripts, though. I spent two full days scratching my head over why I couldn't run the IBM Rational Software Architect installation program on my Ubuntu box, even though it had worked just fine on Debian. Finally I realized that the installation script used BASH features, but tried to run under /bin/sh.

    That's just one example, and it's the installer that's at fault, not Ubuntu, but I've run into enough of them that I make a habit of changing the /bin/sh symlink on every Ubuntu system that I install. There's just too much crud that thinks "/bin/sh" means BASH.

  • by Anonymous Coward on Wednesday August 13, 2008 @04:02PM (#24590081)

    Probably not. The only thing that zsh lacks is marketing power it seems. It's simply way better.

  • by Anonymous Coward on Wednesday August 13, 2008 @04:39PM (#24590627)

    Except for the fact that sh is generally symlinked to bash on Linux systems:

    True. But if bash is invoked as 'sh', it works like sh.

    Sometimes. Other times it works like bash.

    Really annoying to those of us on BSD and Solaris. If you want to use bash, just specify bash, otherwise the GNU folks really need to clean things up.

    Ditto for GNU make.

  • by CrazedWalrus ( 901897 ) on Wednesday August 13, 2008 @09:35PM (#24593833) Journal

    This just bit me in the ass a couple weeks ago. Debian/Ubuntu don't symlink to bash, which is what I'd assumed. They symlink to "dash" -- a stripped-down shell where stuff you expect to work doesn't.

    For the life of me I couldn't figure out why my perfectly valid bash one-liner in my crontab wouldn't work. Some Googling and cursing Debian later, and /bin/sh -> /bin/bash, and my cron jobs are working as expected.

    Now, someone can disagree with me here, and I know you will. The stated purpose of this change is performance gains. Really? Performance gains on shell scripts that rarely go over a couple hundred lines and do all the grunt work in other utilities?

    I'm sure someone came up with a benchmark showing how dash is 100x faster than bash, but in real-world examples, I have to doubt there's any noticeable difference. That said, all the time saved by dash running faster was lost completely when I had to waste my time figuring out what in the hell was wrong with cron.



  • Re:Bash gurus (Score:1, Insightful)

    by Anonymous Coward on Thursday August 14, 2008 @07:35AM (#24597573)

    I am using bash since 92 (I know some since the 70's)

    That's very impressive. Bash was created in 1987 by Brian Fox. [wikipedia.org]

"Pay no attention to the man behind the curtain." -- The Wizard Of Oz