Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Bash Cookbook

samzenpus posted more than 5 years ago | from the read-all-about-it dept.

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

cancel ×

278 comments

BASH != Bourne Shell (4, Informative)

llamalad (12917) | more than 5 years ago | (#24587003)

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

They're not the same.

Re:BASH != Bourne Shell (5, Funny)

laejoh (648921) | more than 5 years ago | (#24587105)

It doesn't matter. If you code like I do you don't need to worry about the difference between /bin/sh and /bin/bash:

<begin file A>
#!/bin/bash

perl <<EOP
print "hello world\n";
EOP
<end file A>

<begin file B>
#!/bin/sh

perl <<EOP
print "hello world\n";
EOP
<end file B>

See? Both work, it's so easy!

Shell as a scripting language... (1)

Tetsujin (103070) | more than 5 years ago | (#24587257)

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

Re:Shell as a scripting language... (1)

retchdog (1319261) | more than 5 years ago | (#24587347)

For this reason, I wish that things like the zoidberg shell [freshmeat.net] would hurry up & mature. (Yeah, yeah, I would work on it myself except I would probably be about as useful as the namesake Dr. Zoidberg is as a doctor.)

"Ask not what you can do for your shell, ask what your shell can do for you!"

Re:Shell as a scripting language... (0)

Anonymous Coward | more than 5 years ago | (#24587495)

Most data translation projects don't need advanced data structures to get the work done. This common misconception is responsible for a great deal of the software project failures over the last few decades.

Re:Shell as a scripting language... (0)

Anonymous Coward | more than 5 years ago | (#24587589)

And a great deal of software projects.

Re:Shell as a scripting language... (1)

Tetsujin (103070) | more than 5 years ago | (#24587673)

Most data translation projects don't need advanced data structures to get the work done. This common misconception is responsible for a great deal of the software project failures over the last few decades.

I'm just talking about basic data structures here - support for anything beyond strings or text streams. Shell programming has become mired in translation steps. Scripting languages let you avoid all that because the language provides data structures and objects, as well as a reasonable set of baseline data types, which modules written in the language can work with.

Some shells support some data structures and containers, but I think Powershell is the only one right now that can actually pass these between processes...

Re:Shell as a scripting language... (1)

colmore (56499) | more than 5 years ago | (#24588191)

Yeah, old-school bash is about as fun as doing trivial tasks in C. And I love C. But still...

I use bash and a little folder in my $PATH as a more robust solution to alias-ing.

But for anything over 1 or 2 lines, calling shell utilities from Ruby is about a hundred million times easier.

I can't keep that archaic syntax in my head for more than a day at a time.

Re:Shell as a scripting language... (4, Insightful)

CastrTroy (595695) | more than 5 years ago | (#24587649)

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.

Re:Shell as a scripting language... (4, Interesting)

Tetsujin (103070) | more than 5 years ago | (#24588255)

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.

This is true of textual data as well - you're simply glossing over the complexity of serializing and re-parsing any non-trivial data structure in textual form... 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.

See, if your text-encoded data is simple enough that you can simply choose a character as a field delimiter and another as a record separator, it's easy to split your data into individual records and fields again. It gets a little harder if you want to provide for the possibility that your records may actually contain the delimiter characters (then you're into parsing - at least enough parsing to distinguish between an escaped character and an unescaped one) Setting up the format so you can really encapsulate anything - that reaches the point where it's worth having a tool whose only job is interfacing with this format...

The problem here is that normally when you want to interpret some encoded form of a piece of data, you first translate it into something that's easier to work with. But in BASH (and most CLI shells, I believe) there is no "more convenient form" to which you can readily translate any moderately complex structure. (Consider, for instance, how you would implement an XML parser for Bash - as an external command it simply wouldn't work... it'd have to be done as a Bash plug-in module, and even then its capabilities would be limited. And then suppose you want to filter the parsed data and pass it to another process? You've got to re-encode it, and then the next process has to know how to decode this encoding (probably still XML) as well...

I contend that the "encode everything as a string" mentality was an asset, due to computer limitations in the time period in which the convention started - but these days I think it's pretty limiting.

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.

I think Powershell has been progressing (in terms of popularity, I mean) quite satisfactorily... The reason it hasn't caught on with me, however, is 'cause I want a Unix solution (that is, runs on Unix, and fairly Unix-styled), not a Windows one - and while I agree with the logic behind some of their design decisions (like the verb-noun convention for command names) I don't like the consequences (the language is much too verbose for my tastes...)

I think it's a step in the right direction but not quite what I'm looking for.

Assuming Powershell hasn't been embraced and taking that as a sign that one particular facet of its design was a bad idea is pretty laughable. Any new tool takes time to be adopted - and Powershell is a tool for a fairly small niche - CLI users on Windows.

Shell as a general-purpose language... (5, Interesting)

daedae (1089329) | more than 5 years ago | (#24587669)

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

Re:Shell as a general-purpose language... (1, Funny)

Anonymous Coward | more than 5 years ago | (#24587739)

+1 bowing to my new master...

Re:Shell as a general-purpose language... (5, Funny)

morgan_greywolf (835522) | more than 5 years ago | (#24587865)

He'd written a particle physics Monte Carlo sim using Bash and Linux command line tools (in particular, there were calls to bc everywhere).

Well, I, for one, welcome our new particle physicist bash programming overlord!

Re:Shell as a general-purpose language... (1)

colmore (56499) | more than 5 years ago | (#24588235)

Hey just throw more hardware at it right? His time on the hours he'd spend writing it in a faster language are worth more than the cost of a few new boxes, natch.

Re:Shell as a scripting language... (3, Informative)

Unordained (262962) | more than 5 years ago | (#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.

Re:Shell as a scripting language... (1)

laejoh (648921) | more than 5 years ago | (#24588275)

Hey, I agree. I love CLIs and all the little tools but if they don't 'cut' it...

Here's what I do when I get stuck in awk:

awk 'BEGIN { system("ls;perl -e \"print \"Hello World!\"\"") }'

Re:BASH != Bourne Shell (-1, Offtopic)

MPAB (1074440) | more than 5 years ago | (#24587215)

BS = Maaatt Daaamon!

Re:BASH != Bourne Shell (0)

Anonymous Coward | more than 5 years ago | (#24587221)

Who implied that they were the same?

Re:BASH != Bourne Shell (0, Offtopic)

llamalad (12917) | more than 5 years ago | (#24587665)

Who implied that they were the same?

Um, the first line of the summary?

"Anyone who has used a derivative of Unix over the past 20 years has used Bash, which stands for Borne Again Shell."

'sh' has been shipping with UNIX operating systems for ages; 'bash' has only recently.

IIRC, it didn't ship with Solaris 7 and I know that Solaris 8 at the very least didn't have it installed by default. Do believe it's installed as part of Solaris 9 and above. As far as AIX goes, I'm guessing bash only came in with 5L. HPUX... yeah, right.

Re:BASH != Bourne Shell (2, Informative)

mgessner (46612) | more than 5 years ago | (#24587975)

It doesn't say they're the same.

However, it's "Bourne Again SHell."

Re:BASH != Bourne Shell (2, Informative)

againjj (1132651) | more than 5 years ago | (#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

Re:BASH != Bourne Shell (4, Informative)

WillKemp (1338605) | more than 5 years ago | (#24587463)

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:BASH != Bourne Shell (2, Insightful)

dfn_deux (535506) | more than 5 years ago | (#24587501)

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.

Re:BASH != Bourne Shell (1)

timonvo (1063686) | more than 5 years ago | (#24587575)

So that means that everything that is backwards compatible/compatible with some other software is identical to that software?

Re:BASH != Bourne Shell (5, Informative)

Benanov (583592) | more than 5 years ago | (#24587835)

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.

Re:BASH != Bourne Shell (0, Offtopic)

dashesy (1294654) | more than 5 years ago | (#24587433)

Now I get that! Bush Bashing means having Bush fight with Jason Bourne in a new shell.

"feint" of heart? (4, Funny)

Tetsujin (103070) | more than 5 years ago | (#24587033)

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?

It's for people like me. (5, Interesting)

khasim (1285) | more than 5 years ago | (#24587187)

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.

Re:It's for people like me. (2, Insightful)

CastrTroy (595695) | more than 5 years ago | (#24587723)

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.

Re:It's for people like me. (1)

MikeBabcock (65886) | more than 5 years ago | (#24587951)

That just shows ignorance of how much power exists within bash without using sed or awk. It also shows a lack of understanding of how powerful each sed and awk are as individual programs (or language, in awk's case).

You can write some substantial software in awk, and in bash, or in a combination of both, or using sed.

Of course, mentioning 'make' in a book on C programming makes sense, but not realizing how powerful make is is probably a result of how people associate it with programming only.

(example: I have a Makefile in /etc/samba to build my smb.conf from an smb-master.conf file after checking it for errors and stripping out comments)

Re:It's for people like me. (5, Insightful)

CastrTroy (595695) | more than 5 years ago | (#24588075)

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.

Bourne-Again Shell (4, Informative)

cos(0) (455098) | more than 5 years ago | (#24587037)

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

Re:Bourne-Again Shell (0, Offtopic)

Kingrames (858416) | more than 5 years ago | (#24587183)

And before anyone asks, no it's not the next installment in the movie series starring Matt Damon.

Re:Bourne-Again Shell (5, Funny)

Ecuador (740021) | more than 5 years ago | (#24587479)

Seriously now, this is like posting a LOTR review by someone who thinks it was written by RJ Tokelen. Or a Star Trek review from a fan of "the late Rod N. Barry".
You gotta love our editors!

Anyway, back to my review of Dark Night... Chris Nolon did it again!

What about the Advanced Bash Scripting Guide? (5, Informative)

UltraMathMan (1139987) | more than 5 years ago | (#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.

Re:What about the Advanced Bash Scripting Guide? (2, Insightful)

Jansingal (1098809) | more than 5 years ago | (#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.

Re:What about the Advanced Bash Scripting Guide? (1)

UltraMathMan (1139987) | more than 5 years ago | (#24587355)

Sure, but I find that when I'm scripting it's generally on a computer - IMHO it's easier to reference something online (and to find it) than it is by combing a 598 page printed book.

Don't get me wrong, books have a place too, but I can't run a find on my printed copy. My intention was to point out that good free resources exist and, at least in this case, are well maintained.

Re:What about the Advanced Bash Scripting Guide? (1)

WillKemp (1338605) | more than 5 years ago | (#24587599)

Both forms have their advantages. The benefit of a hardcopy book is that you can sit down, away from the computer, and read it sequentially (if you're that way inclined!). That way, if you read the whole thing and the book's good, you get the whole picture.

I dunno about you, but i'm rarely capable of reading a big online document from start to finish. I tend to pick out bits i need to know about. That means i miss out on things i don't know i need to know.

But you can't grep a hard copy!

Re:What about the Advanced Bash Scripting Guide? (1)

Jansingal (1098809) | more than 5 years ago | (#24587611)

u r right there.

but for the folks that have an hour on a bus/train to work each direcction, this is good reading material.

Re:What about the Advanced Bash Scripting Guide? (1)

iminplaya (723125) | more than 5 years ago | (#24587437)

802 pages. Get a very big stapler.

Re:What about the Advanced Bash Scripting Guide? (1)

Jansingal (1098809) | more than 5 years ago | (#24587675)

good point.

Re:What about the Advanced Bash Scripting Guide? (1)

iminplaya (723125) | more than 5 years ago | (#24587405)

That was the first place I went after seeing the price of the book. This appears to be yet another ad for Amazon.

BOURNE (1)

homb (82455) | more than 5 years ago | (#24587059)

It's not " Borne Again Shell", but "BOURNE Again Shell".
Stephen Bourne created sh from which bash is derived.

Re:BOURNE (4, Funny)

ArsonSmith (13997) | more than 5 years ago | (#24587127)

It's the Born again Bourne Again shell. Now with more Jesus.

Re:BOURNE (2, Funny)

maxume (22995) | more than 5 years ago | (#24587343)

Crackers or wine?

Re:BOURNE (2, Funny)

pandrijeczko (588093) | more than 5 years ago | (#24587197)

Is that the one-and-only time that you will be telling us this information.

Because if it is, then you have just issued a BOURNE ULTIMATUM!!! ...I'll get my coat.

Re:BOURNE (0)

Anonymous Coward | more than 5 years ago | (#24587633)

*slow clap*

Ken Thompson wrote sh (1)

Version6 (44041) | more than 5 years ago | (#24587725)

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

Re:Ken Thompson wrote sh (1)

homb (82455) | more than 5 years ago | (#24587871)

hehe. nice trolling at the end. let me add fuel to the fire and contend that since Perl became ubiquitous, shells have lost most of their programming importance.

Bourne shell (1)

Z00L00K (682162) | more than 5 years ago | (#24587073)


:

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"

Nice review, but I don't understand something. (5, Interesting)

gardyloo (512791) | more than 5 years ago | (#24587077)

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.

Re:Nice review, but I don't understand something. (0)

Anonymous Coward | more than 5 years ago | (#24587115)

Chapter 11--> Bankruptcy.

Re:Nice review, but I don't understand something. (1)

Jansingal (1098809) | more than 5 years ago | (#24587259)

>>Chapter 11--> Bankruptcy.

what do you mean?

Re:Nice review, but I don't understand something. (3, Informative)

pandrijeczko (588093) | more than 5 years ago | (#24587341)

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

Re:Nice review, but I don't understand something. (1)

Anonymous Coward | more than 5 years ago | (#24587385)

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

Actually, you file for Chapter 11 bankruptcy protection. [wikipedia.org]

Re:Nice review, but I don't understand something. (1)

pandrijeczko (588093) | more than 5 years ago | (#24587597)

That's as maybe, but just because Dick Van Dyke said "Gor blimee Mary Poppins" whilst dancing round a chimney brush, that didn't make him British like me either...

Re:Nice review, but I don't understand something. (1)

Jansingal (1098809) | more than 5 years ago | (#24587571)

me dumb.

Re:Nice review, but I don't understand something. (1)

pandrijeczko (588093) | more than 5 years ago | (#24587125)

It's been out a while but definitely worth the money.

Even "Linux Format" magazine here in the UK gave it 10/10 in a review a few months ago.

Re:Nice review, but I don't understand something. (1)

dlgeek (1065796) | more than 5 years ago | (#24587149)

He continues to say he learned stuff about the "find" command which I assume the chapter focuses on.

Re:Nice review, but I don't understand something. (5, Funny)

techstar25 (556988) | more than 5 years ago | (#24587263)

Why is everybody bashing his review?

Okay, somebody had to say it.

Re:Nice review, but I don't understand something. (1)

Smidge207 (1278042) | more than 5 years ago | (#24587941)

Heh. That's nuthin'. In China they would shhh it.

Yikes.

=Smidge=

Re:Nice review, but I don't understand something. (1)

bunratty (545641) | more than 5 years ago | (#24587297)

what the hell does I found Chapter 11 to be very useful (pun intended) mean?

I think he meant, uh, what's that thing that spells the same backwards as forwards? A palindrome.

Re:Nice review, but I don't understand something. (1)

cain (14472) | more than 5 years ago | (#24587395)

Notlob!

Re:Nice review, but I don't understand something. (2, Informative)

beardz (790974) | more than 5 years ago | (#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".

Re:Nice review, but I don't understand something. (1)

gardyloo (512791) | more than 5 years ago | (#24587349)

Thank you. I understand (no likey!) it now.

Re:Nice review, but I don't understand something. (1)

mechanyx (960689) | more than 5 years ago | (#24587505)

I'm pretty sure it was a reference to this: "Chapter 11 is a chapter of the United States Bankruptcy Code, which permits reorganization under the bankruptcy laws of the United States." http://en.wikipedia.org/wiki/Chapter_11 [wikipedia.org] It took me a moment as well as none of the review had anything to do with bankruptcy and not really anything to do with restructuring.

Re:Nice review, but I don't understand something. (1)

againjj (1132651) | more than 5 years ago | (#24587531)

I was thinking it maybe was somehow based on the chapter title, so I looked up the book [oreilly.com] , but the chapter title was "Chapter 11: Working with Dates and Times". Maybe AC above got it right with Chapter 11 meaning bankruptcy. Or something got edited out of the review?

Re:Nice review, but I don't understand something. (1)

Duhfus (960817) | more than 5 years ago | (#24588267)

> what the hell does I found Chapter 11 to be very useful (pun intended) mean?

May be the (poor) pun is about "Chapter 11" (http://en.wikipedia.org/wiki/Chapter_11 [wikipedia.org] ) also referring to a bankruptcy code in the US.

Re:Nice review, but I don't understand something. (1)

gedhrel (241953) | more than 5 years ago | (#24588295)

http://oreilly.com/catalog/9780596526788/toc.html [oreilly.com]

Perhaps the author intended to write, "...to be very timely", realised that made no sense, but left in the aside?

Unix you say.. (5, Informative)

The Moof (859402) | more than 5 years ago | (#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.

Re:Unix you say.. (0)

Anonymous Coward | more than 5 years ago | (#24587173)

You'll find bash in cygwin and OSX too.

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

PetiePooo (606423) | more than 5 years ago | (#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.)

Re:Unix you say.. (1)

morgan_greywolf (835522) | more than 5 years ago | (#24587647)

Wrong. Bash is the default shell Mac OS X, which is definitely Unix. Also on Cygwin and the Debian GNU/Hurd system, which is not Linux.

Bash cookbook? (4, Funny)

mea37 (1201159) | more than 5 years ago | (#24587131)

Well, ok... Cookbook sucks!

Oh, did I parse that wrong?

Re:Bash cookbook? (1)

morgan_greywolf (835522) | more than 5 years ago | (#24587677)

...And this is why more parsers are written in Perl these days. /me ducks.

Bash this: (0)

Anonymous Coward | more than 5 years ago | (#24587185)

:(){ :|:& };:

Largest BASH script? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#24587245)

I wonder what is the largest BASH script ever made?

7000 lines of BASH code:
http://ra.vendomar.ee/~ivo/finstall [vendomar.ee]

Bash has been my favorite for 12 years (4, Informative)

Ex-Linux-Fanboy (1311235) | more than 5 years ago | (#24587287)

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

Re:Bash has been my favorite for 12 years (0)

Anonymous Coward | more than 5 years ago | (#24587499)

The only shells I have seen in use on modern *NIX systems (read Linux and the odd BSD) is Bash and Ash.

Really? Which BSD derivatives ship with Bash or Ash? The most popular once sure don't. Although Bash is ubiquitous on Linux, other operating systems often use the Bourne shell for scripting and a C-like shell for interactive use.

Re:Bash has been my favorite for 12 years (1)

Black-Man (198831) | more than 5 years ago | (#24587579)

In my experience, any ksh script would run under bash. It was my impression that bash was a catch-all, taking the better ideas from Korn and Bourne.

Re:Bash has been my favorite for 12 years (1)

thogard (43403) | more than 5 years ago | (#24587629)

One key issue is that systems on boot may not have access to all the libraries that make bash a nice human interface. A core system needs a shell that uses no shared libraries at all and does only simple things to start up programs (like a real shell)... If all that can be kept in nice clean text files that include #!/bin/sh to indicate that they won't be doing anything complicated, then it makes it much easier for developers. While I love to use bash, I wouldn't ever consider if for the rc scripts or single user mode if I had an option.

Re:Bash has been my favorite for 12 years (1)

morgan_greywolf (835522) | more than 5 years ago | (#24587719)

BSD boxes don't use bash by default. If you want functional programming in the shell, get yourself a LISP machine. Or Emacs. ;)

Re:Bash has been my favorite for 12 years (1)

Jason Quinn (1281884) | more than 5 years ago | (#24587839)

Good comment. From my perspective however, the two real shells are bash and tcsh. I've been using bash for the last year or so simply because I got tired of changing the default shell in modern distros. But I prefer tcsh for scripting because it is much cleaner syntax-wise even if bash has a few more powerful features. I honestly never even heard of the Ash shell. I'll have to check it out but I just learned it doesn't have tab-completion and I love that feature.

Re-usable libraries (2, Insightful)

john_anderson_ii (786633) | more than 5 years ago | (#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_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.

Re:Re-usable libraries (1)

farmer11 (573883) | more than 5 years ago | (#24587811)

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.

Speaking of useful things that one doesn't want to re-invent... But seriously, when you're implementing stuff like hashmap you're either creating a new programming language or it's time to select a better tool.

Re:Re-usable libraries (1)

john_anderson_ii (786633) | more than 5 years ago | (#24588077)

Not when your hobby is doing fun/weird things with bash.

Re:Re-usable libraries (2, Insightful)

Sancho (17056) | more than 5 years ago | (#24588225)

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? :)

fnashre0n smilleee!!!! (0)

Anonymous Coward | more than 5 years ago | (#24587409)

plig smorlen analis

Power scripters don't limit shells (2, Interesting)

al0ha (1262684) | more than 5 years ago | (#24587451)

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!

Another morbidly obese "programming" book (2, Insightful)

Animats (122034) | more than 5 years ago | (#24587475)

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.

Re:Another morbidly obese "programming" book (1)

MikeBabcock (65886) | more than 5 years ago | (#24588105)

It could be argued that Bash has more language features than many programming languages.

Bash is a huge and very powerful system for both shell work and programming work. The programmable tab-completion being one of my favourites, spell checking is fun too, although I still prefer tcsh's syntax.

Review of BASH COOKBOOK (2, Interesting)

ylikone (589264) | more than 5 years ago | (#24587549)

This book covers the GNU Bourne Again Shell, which is a member of the Bourne family of shells that includes the original Bourne shell sh, the Korn shell ksh, and the Public Domain Korn Shell pdksh. This book is for anyone who uses a Unix or Linux system, as well as system administrators who may use several systems on any given day. Thus, there are solutions and useful sections for all levels of users including newcomers. This book is full of recipes for creating scripts and interacting with the shell that will allow you to greatly increase your productivity.

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.

Obligatory. (3, Funny)

pushing-robot (1037830) | more than 5 years ago | (#24587585)

Re:Obligatory. (1)

grub (11606) | more than 5 years ago | (#24587895)

That is hilarious. Thanks :)

I love this book (0)

Anonymous Coward | more than 5 years ago | (#24587615)

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.

Holding Out (2, Funny)

Jah-Wren Ryel (80510) | more than 5 years ago | (#24587643)

I'm still waiting for jbosh, the Jason BOurne SHell, to be released. I hear it can really kick some ass.

Re:Holding Out (4, Funny)

corbettw (214229) | more than 5 years ago | (#24588097)

Do you really want a shell that runs out of memory and starts killing all of your processes?

If we only had Chad 5 years ago! (1)

lelitsch (31136) | more than 5 years ago | (#24587695)

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.

To Serve Webpages (3, Funny)

AP31R0N (723649) | more than 5 years ago | (#24587857)

It's a cookbook!!!

Standard Unix Shell? (2, Insightful)

plasticsquirrel (637166) | more than 5 years ago | (#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).

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...