Slashdot Mirror
Book Review: Linux Shell Scripting Cookbook
vellorean writes "I have been reading Linux
Shell Scripting Cookbook by Sarath Lakshman, published by Packt,
for a while. While most people I know learn shell scripts themselves,
I was looking to refresh my concepts a little as well as have a
reference lying around on the table for fast access." Read below for the rest of vellorean's review.
Linux Shell Scripting Cookbook
author
Sarath Lakshman
pages
360
publisher
Packt Publishing
rating
9
reviewer
Kumar Appaiah
ISBN
1849513767
summary
A book for beginners and intermediates, which introduces shell scripting and proceeds to provide several practical real-world recipes of useful shell scripts
First of all, let me remark by saying that shell scripting is
something learned more on a need basis than as a tool to solve the
main problem. People would seldom write shell scripts as standalone
programs (exceptions exist). However, what makes shell scripting
invaluable to know is the fact that knowing some tricks can save
several minutes, or hours, of work by automating and simplifying
certain tasks, generally (but not restricted to) file management and
data processing. Linux
Shell Scripting Cookbook does go quite far in pursuing this goal,
and is appropriate for both beginners who are looking to gain
dexterity in shell scripting, as well as intermediate users who wish
to polish their skills. The book also can double up as a quick
reference, though I would argue that the "Advanced Bash Scripting
Guide" would suit that more.
At the outset, the author clarifies that the focus will be on Bash. This, people may or may not like, but the fact that bash has become ubiquitous in terms of the available shells on Unix-like systems today, starting out with bash is not a bad thing to do. Besides, learning other shell scripting languages while knowing bash isn't too hard, since the paradigm remains the same.
The book is organized into chapters based more on utility than scripting concepts themselves, although the language aspects are brought onto the reader gradually. For instance, the examples in the first chapter focus more on the basic data elements (variables, arrays, functions etc.) as well as operators (for numbers, files etc.), and all the examples demonstrate simple usage of these concepts, and he further chapters build upon these in a gradual manner.
At the same time, if he reader has some familiarity with shell scripting and needs to only refresh or learn a certain concept, he/she needs to just read the relevant chapter. It is not too difficult to grasp the examples of the later chapters, provided some basic shell knowledge is assumed.
A positive trait in the presentation of this book is that it is all based on practical everyday examples which, with minor adaptation, can be used by many for their own daily tasks. For instance, there are several examples which describe searching for and processing files, which, I'd imagine, many users would want to do on a regular basis. Thus, providing realistic examples allows the book to double its utility. The language and approach used is simple and conversational, and the presentation is very clear, with each idea being described as a problem statement followed by a "How to do it" section with the actual code, and ending with a discussion of the nitty-gritties of the code. It is easy to go for a quick scan for those in a hurry, while those who with to read in more detail will not be disappointed either.
The book also covers a wide array of applications. For instance, there are examples on automating fetching web pages and processing them, demonstrations of parsing and simplifying and even some queries around databases wrapped around in shell. It also spans to utilities and tasks connected to statistics, backups, compression, version control and many more.
The book goes into a fair amount of detail in terms of describing the shell scripting concept under consideration. The examples used go into a fair amount of detail in order to describe to the user all the aspects involved in the method or command being used. The concepts described are fairly complete, and would be sufficient for the reader to use immediately or with just a little bit of fine tuning. In terms of breadth, the book covers most of the features of shell scripting while also describing the various facilities the shell provides access to in a Unix-like environment. Thus, the book does not disappoint in this front either.
In summary, probably the only thing I'd have liked to see more of is some emphasis on how to write more efficient shell scripts. Granted, most of the shell scripts described in the book are very simple and succinct, but a some words on how loops can be made better, or how to spot situations where pipes are not needed to solve a problem etc. might have been a nice addition. Some explanation of differences with dash, tcsh, zsh etc. might also have been nice, since a lot of users have different default shells. But all this isn't going to prevent me from giving this book a high rating, since it delivers quite well on the promises it makes at the beginning.
This is definitely a good book to have near your desk, and kudos to the author for having taken the effort to put it together. I would highly recommend it to the beginner and occasional shell user for a thorough read, and to an intermediate to have on his/her desk for borrowing the cool scripting ideas and applications the author has written in this book.
You can purchase Linux Shell Scripting 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.
At the outset, the author clarifies that the focus will be on Bash. This, people may or may not like, but the fact that bash has become ubiquitous in terms of the available shells on Unix-like systems today, starting out with bash is not a bad thing to do. Besides, learning other shell scripting languages while knowing bash isn't too hard, since the paradigm remains the same.
The book is organized into chapters based more on utility than scripting concepts themselves, although the language aspects are brought onto the reader gradually. For instance, the examples in the first chapter focus more on the basic data elements (variables, arrays, functions etc.) as well as operators (for numbers, files etc.), and all the examples demonstrate simple usage of these concepts, and he further chapters build upon these in a gradual manner.
At the same time, if he reader has some familiarity with shell scripting and needs to only refresh or learn a certain concept, he/she needs to just read the relevant chapter. It is not too difficult to grasp the examples of the later chapters, provided some basic shell knowledge is assumed.
A positive trait in the presentation of this book is that it is all based on practical everyday examples which, with minor adaptation, can be used by many for their own daily tasks. For instance, there are several examples which describe searching for and processing files, which, I'd imagine, many users would want to do on a regular basis. Thus, providing realistic examples allows the book to double its utility. The language and approach used is simple and conversational, and the presentation is very clear, with each idea being described as a problem statement followed by a "How to do it" section with the actual code, and ending with a discussion of the nitty-gritties of the code. It is easy to go for a quick scan for those in a hurry, while those who with to read in more detail will not be disappointed either.
The book also covers a wide array of applications. For instance, there are examples on automating fetching web pages and processing them, demonstrations of parsing and simplifying and even some queries around databases wrapped around in shell. It also spans to utilities and tasks connected to statistics, backups, compression, version control and many more.
The book goes into a fair amount of detail in terms of describing the shell scripting concept under consideration. The examples used go into a fair amount of detail in order to describe to the user all the aspects involved in the method or command being used. The concepts described are fairly complete, and would be sufficient for the reader to use immediately or with just a little bit of fine tuning. In terms of breadth, the book covers most of the features of shell scripting while also describing the various facilities the shell provides access to in a Unix-like environment. Thus, the book does not disappoint in this front either.
In summary, probably the only thing I'd have liked to see more of is some emphasis on how to write more efficient shell scripts. Granted, most of the shell scripts described in the book are very simple and succinct, but a some words on how loops can be made better, or how to spot situations where pipes are not needed to solve a problem etc. might have been a nice addition. Some explanation of differences with dash, tcsh, zsh etc. might also have been nice, since a lot of users have different default shells. But all this isn't going to prevent me from giving this book a high rating, since it delivers quite well on the promises it makes at the beginning.
This is definitely a good book to have near your desk, and kudos to the author for having taken the effort to put it together. I would highly recommend it to the beginner and occasional shell user for a thorough read, and to an intermediate to have on his/her desk for borrowing the cool scripting ideas and applications the author has written in this book.
You can purchase Linux Shell Scripting 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.
Is Packt desperate for books sales that they have 2 shill reviews in just the last couple of days? Or is it that Slashdot is low on funds and needs another shill check from Packt?
Why does anyone still use shell scripts anymore? Every major(and most minor) distro ships with python, ruby, and perl either built in or a trivial statement away. These languages give you access to basic OS functions and much more sane syntaxes. Shell scripting is something I haven't felt the need to do in 5 years.
In summary, probably the only thing I'd have liked to see more of is some emphasis on how to write more efficient shell scripts.
For that, you'd want a book on Perl, Python or Ruby.
Really, as soon as you've got more than a screenful of shell code, you're better off rewriting it in a regular scripting language. You can do amazing things with Unix utilities, but a huge amount of it winds up requiring launching 6 processes to, e.g., read the greatest value of the third field of the output of 'ls'. That's nuts.
Every topic is littered with them...
ELOI, ELOI, LAMA SABACHTHANI!?
my eyes are burning... argh! Damn you!
This would actually be pretty useful for total noobs (to Bash) like me. I haven't played with programming since 1997 and Fortran. Before that it was C64 Basic. I find that lots of the resources online about Bash scripts are not very good at explaining what the heck is what, syntax and how it all goes together. I can muddle my way through it, but not at the level I like.
I call it 'The Aristocrats'
MY EYES... dude i am at work here "S
OT: What is it with url shortening services? At best, the damn service works and it's a blind link to what the author claimed (which is inferior to just LINKING). At worst it's goatse. Somewhere in between is someone who f-ed up using it (like parent). Can Slashdot please ban links to url shortening services?
mod down, link is gotse
Yes, I write web applications with little to no programing. Yes I use scripts, and even some unix commands called from my HTML+scripts.
<<date +%d/%m/%Y>>
works on my pages. ya it prints the date... Powered by PERL.
PS. I can read an write SQL on my web pages. no programing needed.
Apparently, backslashdotperiod is a model and wants us all to see his picture.
First of all, let me remark by saying that shell scripting is something learned more on a need basis than as a tool to solve the main problem. People would seldom write shell scripts as standalone programs
/etc/init.d scripts in something other than bash (or csh if on solaris, or ksh if on aix)? Granted not everyone would want, let alone try, to write 500+ line bash scripts like I occasionally do; but, there are a ridiculous number of 100+ line perl scripts that could have been done in bash or ksh in fewer lines, and with more clarity, and without the overheard of loading dozens of perl modules due to interdependencies among them.
Seriously? So you write your application's
So the bash fork bomb got popular back while I was at UNH. If you're not familiar with it, it's similar to this: ;(){ :|:& };: (I changed one character so that you dont paste it on recommendation) The way it works is trivial, and it's mystique is only in that it uses punctuation marks in lieu of letters for its own name: make a new function called :, run it and force the output into a new fork of itself in the background; then a final call to the new function. h4rdc0r3 1337.
So, we had this UNH policy that if you hung a shared unix dev box, you got evicted from CEPS (the college for the engineering/cs kids). They could give you a warning or go straight to evict. Their call.
I wrote to their head unix admin once, and with some humility, cause I knew they knew this, pointed out that they could just change the system's ulimit values to disallow casual fork bombing. The default system ulimits on the distro back then (still?) allowed a single user to consume all memory. So we saw a couple kids run the fork bomb and they never actually got evicted, cause maybe 40 grand tuition outvotes a cranky unix admin's wanton lust for cruelty.
Anyways, as a student, my issue was this - set the damned ulimit so that my editor session doesn't get wiped with my homework -- you can't argue for frequent backups when more than 0 seconds of hard work are arbitrarily on the line solved by a simple config change.
But the UNH unix admin guy replied to me and told me that yeah, he knew about ulimit back when I was in diapers, but he wasn't going to change it up. And a few more times that semester, I lost a couple lines of uncommitted code due to some clown pressing enter on a dare.
Fork ya later,
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
If I stick it in root's cron on, say, an AIX system and it pukes I'm not interested in rewriting somebody's bash script to handle running under sh, csh or ksh. I want it written by its original author in sh. And I don't want to hear about a shebang line (#! /bin/bash) - if I haven't installed bash, it'll still puke.
Script replaces you.
I have a quad core phenom-II. I had no idea how fast it was until I clicked on that link. Well done.
BTW it's a while since I've seen goatse.cx. Very funny.
The script receiving stdout from telnet would watch for input lines, keeping track of what response was expected, and send either a USR1 or a USR2 back to the script outputting commands into telnet's stdin, which would then either bail or send the next command. It was rudimentary pass/fail error checking, but much better and faster than echo a; sleep 1; echo b; sleep 1; echo c...
I often prefer #!/bin/sh as I know it's a common denominator on all *nix systems, and often my scripts work even if the shell is busybox. Yes, perl or python may handle the task more efficiently and with less code, but keeping fresh on Bourne shell makes it easier to fiddle with initramfs images and embedded systems with limited space and no advanced shells. In fact, I'll often stick with it just for the challenge. I like making the original Bourne shell truly sing...
Open your eyes. There's much more to the world than just "every major (and most minor) distros." Even more than just Linux and the BSDs.
Crikey. If nobody learned assembly, we wouldn't even have operating systems.
This, people may or may not like, but the fact that bash has become ubiquitous in terms of the available shells on Unix-like systems today, starting out with bash is not a bad thing to do.
Go on, I dare you to diagram that sentence!
That's somewhat clever, but some of us do know what base-64 encoding is.
Il n'y a pas de Planet B.
I've just had a look through the book via Amazon's Look Inside.
I simply cannot fathom how so many authors manage to get a book published on a subject they don't even master properly. "Shell scripting" is by far the worst in this category. So much that I recommend anyone to run screaming in the other direction when you see mention of "shell scripting" in any title. If it mentions "Linux", it's usually also an excellent indicator of junk. Not to take away from the beauty of the Linux kernel (which obviously has nothing at all to do with shell scripting, but let's ignore that fact).
I obviously haven't read the book, but when I skim through it and I see failure to quote parameters, failure to recognize the difference between executing a script with /bin/bash in the hashbang and running it by passing it as an argument to sh, and more, I know for a fact that I'm going to be sitting in #bash trying to re-educate poor misguided souls for as long as I can suffer it.
To those interested in the subject: Do not read this book. Do not read this "Advanced Bash Scripting Guide" mentioned in this review. You will end up writing junk.
Go see Greg Wooledge's wiki, it's got an extensive FAQ of actually useful issues (http://mywiki.wooledge.org/BashFAQ), it's got a great newbie guide (http://mywiki.wooledge.org/BashGuide), it's got a great cheat sheet (http://mywiki.wooledge.org/BashSheet), and much more. Best of all: Unlike that broken ABS, they're all community supported and unlike this book, the knowledge is free.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
It really should just expand them when the comment is submitted.
I move they ban any user that clicks them without first expanding them.
The only interesting thing about this book was to find the author's web site and see how many hoops there are nowadays to get through the Yahoo interview process. I've a friend who managed to get a senior sysadmin role at Yahoo a few years ago who can barely program and has no computer science knowledge whatever - his only previous experience was some ISP admin work, although he was a tremendous suck-up to^W^W^Wgood friends with a few core FreeBSD developers. Anyway, I had the impression that the company was a has-been which runs on inertia.
This text shows how to write portable Bourne shell, a virtue IMO:
http://www.amazon.com/Portable-Shell-Programming-Extensive-Collection/dp/0134514947
I would be happy with this. BUT it is way more work than just forcing people to NOT link to URL shortening services. Expanding links can be made difficult by people "shortening" already shortened URLs. A quick wget does the job, of course, but it would be better to just offload task to the poster (who probably made the damn "shortened link" in the first place).
The problem is then these folks will link to blog pages that they setup to host this material. Some have already started doing that.
You left yourself wide open. Here's my answer:
#!/usr/bin/perl
exec("du -x | sort -n");
Would I use it in place of
#!/bin/sh
du -x | sort -n
No. But it's not something I have to "try" very hard to do in the same number of lines and not many more characters.
I had been limping long with the Advanced Bash Scripting Guide and Google searches for a while. The Wooledge guide looks like a vast improvement. Thanks.
We don't see the world as it is, we see it as we are.
-- Anais Nin
It's trivial to do it in perl!
#!/usr/bin/perl
system("du -x / | sort -n");
As a career Perl hacker, I sympathise, but you're enthusiasm is misplaced in this situation.
"you're" is a contraction. What do you suppose it's a contraction of?
Bow-ties are cool.
Cosplay Wigs is an attractive option for people now adays. you can find your friends buy wholesale Cosplay Wigs ,your colleagues buy Costumes and wholesale Costumes .You can see the wholesale Costumes , wholesale Cosplay Costumes ,is the trend of fashion. Christmas Suits , wholesale Christmas Suits and all kinds of Maid's Suits are appear in our daily life.