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.
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.
'sh' is the Bourne shell.
'bash' is the Bourne Again SHell.
They're not the same.
So, what, does this refer to people who act like they're going to rip your heart out of your chest, only it all turns out to be a ruse so they can kick you in the balls?
Bow-ties are cool.
Bourne Again Shell, not Borne.
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
It's not " Borne Again Shell", but "BOURNE Again Shell".
Stephen Bourne created sh from which bash is derived.
:
echo "I'm an old Bourne Shell"
echo "Early on the first line was a colon to indicate a bourne shell"
echo "And that was before the convention of #!/bin/sh"
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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.
Well, ok... Cookbook sucks!
Oh, did I parse that wrong?
:(){ :|:& };:
Who already own "sed and awk" and buy a book that is supposedly about Bash scripting only to find out that the advanced section replicates what is in the sed and awk book. Which is very annoying.
Not that it's a bad book. I just believe that it should have been more focused on Bash only scripting.
If you want to learn about sed and awk, buy the sed and awk book. If you want to learn Bash scripting, there are a LOT of more useful sites online.
I wonder what is the largest BASH script ever made?
7000 lines of BASH code:
http://ra.vendomar.ee/~ivo/finstall
Now, here's what I'd like to know...
Are you serious here, showing that both shells support useful features, or are you being facetious, showing that both shells are merely acceptable stepping-stones to run Perl code?
I love CLIs but my feeling on most of them is that they're more than a little archaic - the lack of any non-trivial datatypes (and particularly the lack of support for passing structured data or live objects between shell processes) makes it needlessly difficult to get things done - I believe that is one of the major reasons people script with scripting languages these days instead of shells...
Bow-ties are cool.
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..
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_BPE
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.
Be Safe! Sleep with a Marine. Semper Fi!
plig smorlen analis
Bash is cool and I suppose this book is decent, though I've found UNIX for Programmers and Users to be the most useful as it covers Bash, SH and KSH. KSH rocks!
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
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.
Chapter 1, "Beginning bash" covers what a shell is, why you should care about it, and then the basics of bash including how you get it on your system. The next five chapters are on the basics that you would need when working with any shell - standard I/O, command execution, shell variables, and shell logic and arithmetic. Next there are two chapters on "Intermediate Shell Tools". These chapters' recipes use some utilities that are not part of the shell, but which are so useful that it is hard to imagine using the shell without them, such as "sort" and "grep", for example. Chapter nine features recipes that allow you to find files by case, date, type, size, etc. Chapter 10, "Additional Features for Scripting" has much to do with code reuse, which is something you find even in scripting. Chapter 11, "Working with Dates and Times", seems like it would be very simple, but it's not. This chapter helps you get through the complexities of dealing with different formats for displaying the time and date and converting between various date formats.
Chapter 12, "End-User Tasks As Shell Scripts", shows you a few larger though not large examples of scripts. They are meant to give you useful, real world examples of actual uses of shell scripts beyond just system administration tasks. Chapter 13, "Parsing and Similar Tasks", is about tasks that will be familiar to programmers. It's not necessarily full of more advanced scripts than the other recipes in the book, but if you are not a programmer, these tasks might seem obscure or irrelevant to your use of bash. Topics covered include parsing HTML, setting up a database with MySQL, and both trimming and compressing whitespace. Chapter 14 is on dealing with the security of your shell scripts. Chapters 15 through 19 finish up the book starting with a chapter on advanced scripting that focuses on script portability. Chapter 16 is related to the previous chapter on portability and is concerned with configuring and customizing your bash environment. Chapter 17 is about miscellaneous items that didn't fit well into any other chapter. The subjects include capturing file metadata for recovery, sharing and logging sessions, and unzipping many ZIP files at once. Chapter 18 deals with shortcuts aimed at the limiting factor of many uses of bash - the typing speed of the user and shortcuts that cut down on the amount of typing necessary. The final chapter in the book, "Tips and Traps", deals with the common mistakes that bash users make.
All in all this is a very handy reference for a vast number of the tasks that you'll come across when scripting with the bash shell along with well-commented code. Highly recommended.
Meh.
http://xkcd.com/149/
How can I believe you when you tell me what I don't want to hear?
I love this book. (well the older one)
It's a must have for linux users that want to make something happen that isn't in the canned software.
If your an old sysop from the past and you did lot's of batch file programming you'll LOVE this book.
I have the older book, not this specific new one. Just cause you keep a paper cheat sheet doesn't mean you won't want to reference this book at times.
The other book that kicks ass is the pocked sized book by O'reilly that has sys adm command reference.
I'm still waiting for jbosh, the Jason BOurne SHell, to be released. I hear it can really kick some ass.
When information is power, privacy is freedom.
True story:
A guy I go to school with (I'm in CS, he's in physics) used to talk about how he was a Bash wizard. Since he was generally talking about writing scripts to submit jobs to a PBS-based cluster, I assumed he meant just in terms of rapidly submitting a large variety of jobs. One day he complains to me that his simulations were slow and wanted me to look at it with him to help him speed them up. So I say fine, send me the file...
He'd written a particle physics Monte Carlo sim using Bash and Linux command line tools (in particular, there were calls to bc everywhere).
Anyone who has used a derivative of Unix over the past 20 years has used Bash
Wow, we could have avoided the entire SCO since AIX is not a derivative of UNIX.
Ken Thompson wrote the original sh. In Unix Version 7 sh was replaced with the Bourne shell, confusingly also called sh. Some of us never really adjusted to the Bourne shell and over time switched to csh or ksh (the Korn shell written by David Korn). In my maturity, I recognize that it was all as inconsequential as vi versus emacs. (No contest really, vi is better.)
It's a cookbook!!!
Utilizing the synergization of benchmark e-solutions to pre-workaround action items!
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).
Systemd: the PulseAudio of init systems
They can just enter "man bash" on the command line
If I could write me a script that can make me a grilled cheese sandwich and I would very happy.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
"bash Cookbook" suffers from a poorly thought out table of contents. For a 'cookbook' this lack of clean organization makes the book impractical as a reference source. After a few minutes of searching, trying to find the concept I need, I normally put the book back on my shelf and turn to Google. An online search always turns up better examples of what I'm trying to do and takes less time. Sorry O'Reilly, this book at best earns a C-.
I still miss the directory history (Ctrl-PageUp/Dn) from 4NT. I see one person does too and came up with solution
mostly to do with patents or some other guff that (I think) is gone, but while there caused many problems.
When you can't rely on many of the features of a shell, you're either portable to bash/sh or you're wasting your time on it and should consider using bash.
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.
Sometimes, life itself is sarcasm...
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.
What does bash do that tcsh doesn't ?
OK, aside from the 2>something_other_than_&1 stuff.
My wife 1.0 beta (way past the alpha years) recently spawned a child process. She takes some resources, but so far the experience has been well worthwhile.
Hmm, maybe I can try again to get her to cook/code me some grilled cheese. I know she has the algorithm and the resources, but she never seems to run that code.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
And it's "faint of heart" not "feint of heart".
And it would be "overviewing basic concepts" not "over viewing basic concepts" if "overview" were a verb.
I made it as far as:
before threwing in the trowl.
--MarkusQ
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. 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:
Which leads me to ask: has anyone tried Zsh but then gone back to Bash? If so, why?
Dewey, what part of this looks like authorities should be involved?
... Starring Matt Damon.
TIA.
Bourne Again Supremacy.
"Anyone who has used a derivative of Unix over the past 20 years has used Bash, ..."
Sure, but in the end, people who really know what they're doing use the
ultimate shell, zsh (see http://www.zsh.org/ )
tcsh and Pico! partners in crime and the only thing you will ever need... aside from root.
if it isnt tcsh, it's crap.
(also elm ftw!)
Without question Ken O. Burtch's book "Linux Shell Scripting with Bash"
Its extremely practical, very well organized, and covers just the right amount of related packages and use cases.
On top of all that, its actually readable.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Well I've not read the book, so I'm not sure what context he's using awk and sed in, but he should not be advocating the use these two unless it's absolutely necessary and only for occasional use. Under no circumstances should you ever make heavy use of them, especially when if you find yourself invoking them thousands of times inside a loop. The context switching it creates is a performance killer.
There really is no need for it, as bash has a very powerful set of features for text manipulation that can be bent to almost any task. It may require writing a little more code to get the job done, but sticking with shell built-ins as much as possible to avoid context switching will result in much much faster execution times. The same goes for other shells too, like ksh, zsh, etc.
I've re-written scripts for customers in the past to eliminate external programs as much as possible and reduced run times (for example) from several hours, to just 20 minutes.
http://www.thebestpageintheuniverse.net/c.cgi?u=puns springs to mind.
.
by Mendel Cooper, is all you will need. PDF. tar.bz.
Save your money for beer.
Sig this!
I have seen bash gurus who could cat a file into sed, then run a regexp then count the output lines...
Also many of these gurus could not check if a file existed, write a normal "if" comparing 2 variables, or write a script that w.g. found files at a place, ran grep on them, then depending on the output replaced strings in them, and created a diff directory.
Now these books are NOT JUST for these guys, and I am sure even if you are that 3133t hax0r bash guru you can still find something new in these books.
I am using bash since 92 (I know some since the 70's), and learn something new every week (at least) about bash or some pretty common UNIX command (grep, sed, bash sort, tar)......
I am programming PHP and ASP (most of the time) and do it on Mac/OSX machines, so even working on Wintel machines I still have the edge using my unix cli (just mount the SMB sucker, then run the good stuff).......
Then again, just my 2c, I just thought there were lot of bad critics here, and I though any book was a source for learning new. Or hey, just use google and "man", "man" (info) is your best friend under *NIX.....
I found Chapter 11 to be very useful (pun intended) finally grasping some concepts on the find command that have previously escaped me
I think the Chapter 11 = bankruptcy folks have it completely right; the reviewer's attempt at humor was completely bankrupt here.
I know it's not really fashionable any more, but this is the sort of thing FORTRAN was made for. The right tool for the right job and all that...
http://www.scsh.net/
Did you mean "faint-of-heart?"
If you don't know what you're doing, you can't make mistakes.
Sorry but i use CLISP for my shell.
GCS/S d-x s+(+): a C++++$ UL+$ P+ L++$ !E--- W++@ N++>$ !o !K-- w++$ !O !M !V PS++>$ PE !Y PGP+ t+ 5++ X++ R tv b
Bourne is more portable. Sun does not seem to like bash. Maybe it's just the "not invented here" thing.
The way I see it, if you need something more powerful than bourne, use perl or python. Shell scripts are good for ten line throw-aways. The only possible advantage than shell scripting has over perl, is portability, so if you want portability, use bourne.
http://xkcd.com/456/
I know full well that tobacco is bad for you, so I smoke weed with crack