Slashdot Mirror


Bash Cookbook

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.

14 of 278 comments (clear)

  1. BASH != Bourne Shell by llamalad · · Score: 4, Informative

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

    They're not the same.

    1. Re:BASH != Bourne Shell by WillKemp · · Score: 4, Informative

      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.

    2. Re:BASH != Bourne Shell by Benanov · · Score: 5, Informative

      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.

    3. Re:BASH != Bourne Shell by againjj · · Score: 4, Informative

      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
      \s-\v\$
      sh-3.00$ export PS1='myprompt '
      myprompt export PS1='\s-\v\$ '
      sh-3.00$ exit
      exit
      -sh-3.00$

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

    4. Re:BASH != Bourne Shell by Krishnoid · · Score: 4, Informative

      Generally -- except in one notable case, and expected in Debian lenny. 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.

    5. Re:BASH != Bourne Shell by eldepeche · · Score: 3, Informative

      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.

  2. Bourne-Again Shell by cos(0) · · Score: 4, Informative

    Bourne Again Shell, not Borne.

  3. What about the Advanced Bash Scripting Guide? by UltraMathMan · · Score: 5, Informative

    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/ extremely helpful on numerous occasions.

    --
    Registered Linux User #423733
  4. Unix you say.. by The+Moof · · Score: 5, Informative

    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.

  5. Bash has been my favorite for 12 years by Ex-Linux-Fanboy · · Score: 4, Informative
    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..

  6. Re:Nice review, but I don't understand something. by pandrijeczko · · Score: 3, Informative

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

    --
    Gentoo Linux - another day, another USE flag.
  7. Re:Shell as a scripting language... by Unordained · · Score: 3, Informative

    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.

  8. Re:Not the only choice by Just+Some+Guy · · Score: 3, Informative

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

    # Import color definitions
    autoload colors zsh/terminfo
    colors

    # Define common and useful things to put in a prompt
    typeset -A prc
    prc[abbrevpath]='%{${fg[red]}%}%B%45<...<%~%<<%b%{${fg[default]}%}'
    prc[newline]=$'\n'
    prc[promptchar]='%(!.#.$)'
    prc[smiley]='%(?.%{${fg[green]}%}:).%{${fg[red]}%}:()%{${fg[default]}%}'
    prc[timestamp]='%B%{${fg[blue]}%}[%T]%{${fg[default]}%}%b'
    prc[userspec]='%B%(!.%{${fg[red]}%}.%{${fg[green]}%})%n@%m%{${fg[default]}%}%b'

    # 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.

    --
    Dewey, what part of this looks like authorities should be involved?
  9. Re:Shell as a scripting language... by sciurus0 · · Score: 3, Informative
    While you're waiting on Zoidberg, here are a few projects you should check out:
    1. Rush, a ruby shell. Rush strikes me as a very cool project. This slideshow is a good introduction.
    2. iPython with the "sh" profile. About halfway into this article they discuss it.
    3. Hotwire, an "object-oriented hypershell"