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


Forgot your password?

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:
  • BASH != Bourne Shell (Score:5, Informative)

    by llamalad ( 12917 ) on Wednesday August 13, 2008 @02:02PM (#24587003)

    'sh' is the Bourne shell.
    'bash' is the Bourne Again SHell.

    They're not the same.

  • Bourne-Again Shell (Score:5, Informative)

    by cos(0) ( 455098 ) <pmw+slashdot@qnan.org> on Wednesday August 13, 2008 @02:03PM (#24587037) Homepage

    Bourne Again Shell [gnu.org], not Borne.

  • by UltraMathMan ( 1139987 ) on Wednesday August 13, 2008 @02:04PM (#24587055)
    Not knocking the book, especially as I haven't read it, but I've found the Advanced Bash Scripting Guide (available free online) http://tldp.org/LDP/abs/html/ [tldp.org] extremely helpful on numerous occasions.
  • Unix you say.. (Score:5, Informative)

    by The Moof ( 859402 ) on Wednesday August 13, 2008 @02:08PM (#24587113)
    As a BSD user (OpenBSD and FreeBSD), the only way I run into bash is to explicitly go and install it. Actually, the only place I have run into bash as a default install is on Linux.

    I run into alot more sh, ksh, csh, and tcsh.
  • by Ex-Linux-Fanboy ( 1311235 ) on Wednesday August 13, 2008 @02:16PM (#24587287) Homepage Journal
    Bash has been my favorite interactive shell for 12 years now. Basically, *NIX command shells, which in the 1980s had a lot of interesting ideas presented (csh, tcsh, ksh, etc.), have basically settled down. The only shells I have seen in use on modern *NIX systems (read Linux and the odd BSD) is Bash and Ash. Ash has had a resurgence in popularity lately because a version of it is part of Busybox (along with a tiny implementation of awk).

    Bash takes Bourne Shell scripting (which was always more powerful than Csh scripting), and combines it with Csh's and Tcsh's best interactive features (! expansion, arrow history, tab completion, etc.).

    The last time I saw people try to have a different paradigm with *NIX shells was with the 'rc' and 'es' shells of the 1990s, which was an attempt to introduce functional programming to the shell. Both shells stopped being actively developed before they were full featured (they never had job control, for example).

    More recently, there is a new shell out there called the 'fish' shell, which I tried and didn't like. I don't like its requirement to have everything in a bunch of colors; a true *NIX shell, in my opinion, should not try and make everything colorful (I also despise ls with colors).

    Looks like ksh finally was open sourced, but by then Bash had become the standard shell you're guaranteed to have in just about any Linux distribution (exceptions being tiny distributions which use Busybox for everything).

    More information, of course, is on the Wikipedia. [wikipedia.org].

  • by beardz ( 790974 ) on Wednesday August 13, 2008 @02:18PM (#24587315)

    I may even buy the book based on the review.

    Leaving aside stuff like not for the feint of heart, which is just poor editing, what the hell does I found Chapter 11 to be very useful (pun intended) mean?

    Maybe it's the ultimate meta-pun, where there was no pun in the first place, but the author pointed out that one was intended, so one was slipstreamed into the statement.

    I think he's actually referring to Chapter 9 which is entitled "Finding Files: find, locate, slocate" hence the pun on "found".

  • by pandrijeczko ( 588093 ) on Wednesday August 13, 2008 @02:20PM (#24587341)

    It's a play on words. In the US, if you declare bankruptcy, you "file a Chapter 11".

  • by againjj ( 1132651 ) on Wednesday August 13, 2008 @02:20PM (#24587351)
    Except for the fact that sh is generally symlinked to bash on Linux systems:
    $ ls -l /bin/sh
    lrwxrwxrwx 1 root root 4 Mar 10 2006 /bin/sh -> bash
  • by WillKemp ( 1338605 ) on Wednesday August 13, 2008 @02:25PM (#24587463) Homepage

    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.

  • Re:Unix you say.. (Score:2, Informative)

    by PetiePooo ( 606423 ) on Wednesday August 13, 2008 @02:33PM (#24587603)

    As a BSD user ... I run into alot more sh, ksh, csh, and tcsh.

    Haven't they heard the news in the BSD camps? Scripting in csh is considered harmful. [faqs.org] ;)

    In all seriousness, having scripted in both, I would consider bash more powerful than ksh, and I avoid csh/tcsh scripting for some of the (still valid) reasons listed in the legendary tome linked above.

    (Although, if performance isn't an issue, I usually attempt to stretch good old /bin/sh to its limits first. I even had it emulating expect for one task, sandwiching telnet between two scripts where the later sent signals back to the first... It worked, and kept me from having to install another package on a rigorously locked-down Solaris 8 box.)

  • by Benanov ( 583592 ) <brian.kemp@membe ... minus physicist> on Wednesday August 13, 2008 @02:48PM (#24587835) Journal

    In Ubuntu since edgy, sh has been symlinked to dash instead. This allowed for a much faster boot while breaking all the "sh" scripts that used bash-specific syntax.

    There was a bunch of whining about it when it happened but I think everyone fixed their scripts and shut up.

  • by mgessner ( 46612 ) <mgssnr@@@gmail...com> on Wednesday August 13, 2008 @02:55PM (#24587975) Journal

    It doesn't say they're the same.

    However, it's "Bourne Again SHell."

  • by Unordained ( 262962 ) * <unordained_slashdotNOSPAM@csmaster.org> on Wednesday August 13, 2008 @03:00PM (#24588055)

    From what I've seen (not used it) the new Windows PowerShell (Monad) is designed around "piping" data between apps that actually exchange .Net objects, including lists, maps, etc. of objects -- rather than character streams. There seem to be generic commands that provide sql-like "select / where" filtering clauses, etc., too. You might explore that, see if it fits your needs. It looks awfully verbose to me though, I'd have to find a way to set aliases for most everything. Just a thought.

  • by Abcd1234 ( 188840 ) on Wednesday August 13, 2008 @03:17PM (#24588329) Homepage

    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.

    You mean it makes it possible to use the wrong tool for the job, in order to avoid a little training.

    No offense, but that's a *really* terrible idea.

  • by Joe Snipe ( 224958 ) on Wednesday August 13, 2008 @03:26PM (#24588495) Homepage Journal
    If you are new to linux and are thinking about learning BASH, you need to be aware that in Ubuntu linux /bin/sh points to DASH, NOT BASH. Not alot of difference, but it can screw you up if you are not aware of it. You know I'm not trying to troll here, but I really felt this change was poorly implemented and announced. I hope it doesn't deter any newbies from probing deeper into their systems and learning the joys of scripting.
  • by greysky ( 136732 ) on Wednesday August 13, 2008 @03:27PM (#24588519)

    He FOUND chapter 11 (which is about FIND) useful. There's the pun. You had to read past the bit talking about the pun to get it.

  • by againjj ( 1132651 ) on Wednesday August 13, 2008 @03:32PM (#24588579)

    No, it doesn't. There are a couple of changes, like ~/.bashrc is not read, but mostly it stays as-is. Basically, if you invoke bash as sh, AND stay inside the sh syntax/commands, then bash works like sh.

    -sh-3.00$ /bin/sh
    sh-3.00$ help bind
    bind: bind [-lpvsPVS] [-m keymap] [-f filename] [-q name] [-u name] [-r keyseq]
    [-x keyseq:shell-command] [keyseq:readline-function or readline-command]
    Bind a key sequence to a Readline function or a macro, or set
    a Readline variable. The non-option argument syntax is equivalent
    to that found in ~/.inputrc, but must be passed as a single argument:
    bind '"\C-x\C-r": re-read-init-file'.
    sh-3.00$ echo $PS1
    sh-3.00$ export PS1='myprompt '
    myprompt export PS1='\s-\v\$ '
    sh-3.00$ exit

    Here, bind and PS1 (help maybe?) are both in bash but not sh.

  • by Krishnoid ( 984597 ) on Wednesday August 13, 2008 @03:36PM (#24588663) Journal
    Generally -- except in one notable case [ubuntu.com], and expected in Debian lenny [debian.org]. As you can imagine, this caused a lot of complaints. From what I skimmed there and other places, the attitude is that /bin/sh under Debian should be a fully POSIX-compliant shell, and if you want to use bashisms, start your program with #!/bin/bash.
  • by lmnfrs ( 829146 ) <lmnfrs@g m a i l . c om> on Wednesday August 13, 2008 @03:36PM (#24588679) Journal
    Apparently, even while in POSIX mode, bash isn't quite POSIX-compliant: http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html [gnu.org]
  • Re:Unix you say.. (Score:2, Informative)

    by Anonymous Coward on Wednesday August 13, 2008 @03:43PM (#24588793)

    ksh is far more powerful than bash. ksh93 has associative arrays, floating-point arithmetic, and coprocesses, just to name a few of the features missing in bash. In general, I've found that anything I could do in bash I could do in ksh.

  • by Anonymous Coward on Wednesday August 13, 2008 @03:56PM (#24588983)

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

    More or less, I suppose, but not exactly; at least, not in my experience. A while back I decided to make /bin/sh a symlink to dash instead of bash (part of a quixotic quest to rid my Linux system of GNU software). A good number of scripts broke, because they used bashisms that bash happily accepted even when it was /bin/sh, but dash rejected.

    Thus part of the quixotic nature of my quest: I simply patched those programs to use /bin/bash, meaning it's still around. Not as my Bourne shell, though!

  • by Anonymous Coward on Wednesday August 13, 2008 @03:59PM (#24589031)

    Yeah, that's true and all, but the pun was the fact that he "found" Chapter 11 (the chapter on "find") to be useful -- nothing to do with bankruptcy.

  • by eldepeche ( 854916 ) on Wednesday August 13, 2008 @04:43PM (#24589721)
    According to Wikipedia, Bash was first released in 1987, 21 years ago. I have no idea when it became the predominant shell in GNU/Linux-world.
  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday August 13, 2008 @05:51PM (#24590817) Homepage Journal

    Coloring the prompt? That was the "gee whiz!" moment that made me switch permanently. From my .zshrc:

    # Import color definitions
    autoload colors zsh/terminfo

    # Define common and useful things to put in a prompt
    typeset -A prc

    # Make a spiffy prompt
    PROMPT="${prc[userspec]} ${prc[timestamp]} ${prc[abbrevpath]}${prc[newline]}${prc[smiley]} ${prc[promptchar]} "

    # Unclutter the namespace
    unset prc

    See how all the colors are defined in an associative array, like ${fg[green]} gets you a green foreground? Say I'm in the directory "/usr/share/media/music/albums/Pink Floyd - A Momentary Lapse of Reason". As a regular user, my prompt looks like:

    kirk@athena [16:40] ...s/Pink Floyd - A Momentary Lapse of Reason
    :) $

    My name@host is green, the time is blue, and the path is red. The smiley face is green. Now, if I'm root:

    $ sudo -s
    root@athena [16:43] ...s/Pink Floyd - A Momentary Lapse of Reason
    :) #

    My name@host is red now, and the prompt char is "#" instead of "$". But what if I run a command and it fails?

    # crqecrqw
    zsh: command not found: crqecrqw
    root@athena [16:44] ...s/Pink Floyd - A Momentary Lapse of Reason
    :( #

    The green smiley face is now a red frowney face. Someone suggested a "big" prompt like that, and once I got used to it, I love it. It's very easy to see where command output stops and the next command starts, and the whole green smile vs. red frown thing is an instant visual indicator of a command's results (which sometimes isn't obvious, say if you're redirecting stderr to /dev/null). Sure, I could have done something similar in Bash, but I guarantee it would've been a whole lot less readable. I did that as an experiment to learn Zsh scripting, and I haven't deliberately used Bash since then.

  • This guide ... (Score:2, Informative)

    by actionbastard ( 1206160 ) on Wednesday August 13, 2008 @08:59PM (#24592953)
    by Mendel Cooper, is all you will need. PDF [riverusers.com]. tar.bz [riverusers.com].

    Save your money for beer.
  • by sciurus0 ( 894908 ) on Wednesday August 13, 2008 @10:14PM (#24593617)
    While you're waiting on Zoidberg, here are a few projects you should check out:
    1. Rush [heroku.com], a ruby shell. Rush strikes me as a very cool project. This slideshow [slideshare.net] is a good introduction.
    2. iPython [scipy.org] with the "sh" profile. About halfway into this article [redhatmagazine.com] they discuss it.
    3. Hotwire [hotwire-shell.org], an "object-oriented hypershell"
  • by Anonymous Coward on Wednesday August 13, 2008 @11:37PM (#24594379)

    I'm the poster to whom you replied (honest!)

    Why did you want to get rid of all GNU software? Could you smell RMS's beard on it?

    My primary reason for wanting to ditch GNU software is because of GNU's attitude toward man pages. That is, they think they should be replaced by info pages. Unfortunately, info documentation tends to read like a book, with sections about all sorts of various things that, honestly, I don't give a damn about when I'm looking for a brief synopsis of a program. You know what, historically, has given a good synopsis of a program? Man pages. So I decided to port over as much BSD software as I could because the BSDs still care about the kind of documentation I like.

    Did you know that GNU tar doesn't ship with a man page? Not even one of those crappy "see the info page for the full documentation" pages. Yes, you might have one on your system, but it did not come from GNU; or if it did it's either wildly out of date (I don't know when, if EVER, they shipped a tar man page) or updated by your distribution.

    There's also the annoyance of the term GNU/Linux. Yes, I understand why people push for it, but something about GNU adherents rubs me the wrong way. Anything I can do to legitimately make my system not "GNU/Linux" is a positive step. So I suppose the answer to your question is "yeah, kind of".

    Plus the BSD license gives me more freedom than the GPL.

  • by DSmith1974 ( 987812 ) on Thursday August 14, 2008 @03:27AM (#24595727)

    You might explore that, see if it fits your needs. It looks awfully verbose to me though

    You can set your own aliases in the $profile script but you don't need to; Powershell is already an elastic language

    These two one-liners are functionally identical:

    $items | foreach { $_ | get-members }

    $items |%{$_ |gm}

"The one charm of marriage is that it makes a life of deception a neccessity." - Oscar Wilde