Slashdot Mirror
Wicked Cool Shell Scripts
Chapters are divided into an array of topics sure to catch the attention of any UNIX based system user: The Missing Code Library, Improving on User Commands, Creating Utilities, Tweaking Unix, System Administration: Managing Users, System Administration: System Maintenance, Web and Internet Users, Webmaster Hacks, Web and Internet Administration, Internet Server Administration, Mac OS X Scripts, and Shell Script Fun and Games.
In true "cookbook" fashion, each hack is numbered and divided into The Code, How It Works, Running the Script, The Results and Hacking the Script. Throughout, the author clearly describes the syntax and functionality of each script, often with additional notes in How It Works detailing the syntax process and interesting asides. But Hacking the Script is what gives Wicked Cool Shell Scripts true value; where applicable, the author uses this section to describe script modifications to achieve a variety of alternative real world, practical results. This additional section alone easily triples the total number of scripts the reader is exposed to.
This book enables the reader to get "up close and personal" with their UNIX based system and explore the possibilities afforded by becoming intimate with the command line interface. The reader will find themselves easily propelled into the world of scripting, thanks entirely to Dave Taylor's ability to take what some might describe as a fairly dry topic and translate it into a logical and user friendly construct. Just reading through the table of contents is inspiring and intriguing; did you know you could write a script to retrieve movie info from IMDb? or track the value of your stock portfolio? or that you can use a very simple script to check spelling on your web pages?
Sysadmins and webmasters will find this book fundamentally critical to day-to-day operations; there are dozens of invaluable, customizable scripts highlighted in this book to enable professionals to save time and add simple, elegant solutions to annoying issues in their work environment. User account management, rotating log files, cron scripts, web page tweaks, apache passwords, synchronizing via ftp, etc. are all eminently useful and tweakable.
Geeky home users will discover they can use these scripts to work with files and directories, create spell-checking utilities, calculate loan payments, create summary listings of their iTunes libraries, and of course, play games. Many of the sysadmin scripts would also be of interest to the power user: analyzing disk usage, killing processes by name and backing up directories, to name a few. Both types of users will find this book inspiring and truly fun!
One of the secret pleasures of a technical book reviewer is finding those wonky bits of code that suffer from misplaced or missing punctuation, misspelled words and other basic typographic errors inherent in the book publishing process. I randomly selected many of these scripts to try out in the process of doing this review and...dang, haven't found any errata yet. But be sure to check out the errata page on Dave Taylor's web site for any that more astute readers may find (there were none, as of this writing).
Also be sure to take a closer look at Dave's shell script library, which lists additional scripts that didn't make the cut for the book. As convenient as it is to download the entire script library, I would like to stress the value of buying the book, which will provide you with invaluable instruction and guidance in understanding the syntax of the scripts and it also illustrates how making small but significant tweaks can modify the output to match your specific needs.
(A special nod of appreciation to Dave Taylor's Tintin references!)
You can purchase Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I could use some wicked cool batch files.
And here I thought I was done with buying books.
*Bookmarks this page for when I get money*
I've got more mod points and GMail invi
i like shell scripting. i dont know why, it just seems more enjoyable than programming big apps in java or c++. maybe its just the size, they are done sooner. i use a script that upon booting writes the new IP on a dynamic IP machine to the httpd.conf file, i thought that was kinda cool. nothign complicated, just necessary.
use your turn signal! you people act like it's divulging information to the enemy
Step 1. Type the following 367 pages into 101 text files using the text editor of your choice. ./*' and hit enter.
Step 2. Type 'chmod a+x
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
did you know you could write a script to retrieve movie info from IMDb?
Please please tell me it's not
#!/bin/sh
wget 'http://imdb.com/title/tt0151804/'
Tsunami -- You can't bring a good wave down!
...everything looks like a nail
Actually, I agree that shell scripting is a powerful tool and well worth understanding. But 'a loan calculator' script? Gee, once you know the formula, a coupla minutes in a spreadsheet will do the trick.
I guess all people, myself included, fall into the hammer/nail trap. I know C very well, so I use it for just about every little app. Hmm... maybe I oughta buy this book.
-RatOmeter
Hopefully it also features a grammar checking script to ensure that you don't start using phrases like 'Wicked Cool'.
There needs to be a chapter on bash prompts. I have seen some slick prompts. Displaying; uptime, current directory size, time, battery power, etc. I'm pretty satisfied with a user@host:~, but i do like to put color in mine.
If the script is not working as you want, put a
on the fist line and on the last line.You will see the exact execution path and variable expansion, very neat for debugging
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
A guy I know that is into Geocaching likes to use archaic shell scripting to scrape web pages for information. While the scripts work they require other applications and quite a bit of messy code.
Why would you use awk and sed along with a really ugly shell script to get something done when you could have just as easily used perl to acheive the same effect?
Sometimes you should just use what is best for the job. I really don't think that using shell scripts to pull IMDB movie info is the best way to go.
YMMV,
No. You do not have to settle for less. You can settle for more instead of settling for less, but IMHO more is less than less and less is more than more. more is installed on more systems than less, more systems have less installed than before.
rm -rf *
:)
A better idea is to write "rm -rf ~/*", name the script "ls" and put it in your home directory to punish people with "." in $PATH . Now _that's_ teh funnay.
if you use a good enough junk-filter, slashdot.org will display a single, *blank*, page
You might want to read imdb's robot.txt before using wget.
Very recently, after reading a (Score:5, Insightful) idea on what would "make Linux four times what it is today" I decided to write a shell script which does exactly that. Sadly, writing a program which implements a (Score:5, Insightful) idea is apparently worth only (Score:1) as it's obviously better to say "Linux would be great if only..." than just doing it. Anyway, I have released it under the GNU General Public License. Enjoy!
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
(i) Many people, like myself, don't know perl, and don't see the point in learning when shell scripts are perfectly adequate for their purposes.
(ii) Sometimes it's just easier. viz. this quote from bash.org:
Jurisprudence Fetishist Gets Off On A Technicality --theonion.com
Um, me.
My web server has 6 megs of RAM. (it's an embedded device). That gives me two choices: C or sh. Obviously sh doesn't work for everything, but it's sure a heck of a lot nicer than using C for the non-critical stuff.
Ironically, I usually use Python for administration type tasks during development on real computers, and sh for the web sites themselves on the embedded servers.
Bryan
I haven't seen or read this book, but my first impression from reading the review is that it's just a book that lists some shell scripts. There's no real challenge. You could customize the scripts endlessly, but real hackers write the scripts themselves (okay, borrowing code sometimes)
So what? I just bought a cookbook on sauces. What's different? Maybe I like a little more garlic in most my sauces so I'll throw some in here and there. Most of the sauce recipes, i would have never have thought to go with something I usually eat. Why does there need to be a "challenge"? It simply makes my meal more enjoyable.
Having 101 shell scripts that I can tinker with and add things that I like, or use them in a way that makes using my computer more enjoyable is great!
I can hardly wait for: Wickity Wacked Scripts PHPhat Programs 101 Scripts With Bling Bling /bin/Shizzle Your Scripts
Sucka MC Unix Administration in a Nutshell
-w
During boot up scripts, until you get past the point that /usr is mounted (you do put /usr on a different partition right?), you can't use anything. That's how you determine what goes on /bin and what goes in /usr/bin (well mostly). When things go wrong, and you need to recover, trying to fix things on a busted machine, is much more reliable if you are using shell then perl (it's got a smaller foot print, and it's not an intertangled mess of libraries).
Intertangled messes of libraries are a great thing when you are developing. They are a beast, if things are broken. What if you fsck can't finish because part of the library is dorked. Thus you can't mount the filesystems you need to use to fix the problem.
During boot up, you want to use the easiest, and most reliable method of booting. Shell scripts are probably better off then perl scripts. It's easy to have readable, reliable shell scripts with scoping, it's just not something you are used to doing apparently.
Besides all that, you'd spend all your time in perl doing exec/fork/system. The /bin/sh is more efficient at doing that then perl is (in terms of code, if not runtime).
Kirby
usually the really important scripts are running /bin/sh - a STATICALLY compiled binary of a shell that is pretty much everywhere.
why not dynamically compiled? Well if your glibc barfs all dynamically compiled binaries barf with it - including perl, and including any shells that you use to start up your system. With a statically compiled shell to handle all of those startup scripts you can boot linux without glibc working, and you probably have enough of a system still running to get things fixed. with a dynamically linked startup file interpreter, when glibc or something glibc depends on goes, your whole system goes, single-user mode and all.
Besides, while perl can execute system commands and make decisions based on input, i think the shell is a better tool for things like this. sh and bash were designed to do startup scripts (among other things) and they do them well. why fix what isn't broken? shell scripts work, and they can do anything you'd need them to do during startup.
Is there a shell script included that makes it look like you are working? Isn't that the purpose of all good shell scripts?
Freedom is trouble :)
Here's to losing my Karma Bonus again....
Here's other stuff I have grouped by sections in my .cshrc
First, I have my shell variables. The comments say what they do. The most important one is autolist.
Second, bindkeys are pretty neat. I rebind the up and down arrow keys. By default they scroll up and down one at a time through the history. You can bind them to search the history based on what you've typed so far.
Third, completes allow for customizing tab completion. When I change directories, tab only completes directory names. This also works for aliases, sets, setenvs, etc.
Fourth, I have all my aliases. I had to cut a bunch because of the lameness filter.
The ultimate goal of science is to unify all forces of nature to a single law that can be silk-screened onto a T-shirt.
Quick! Somebody pick this up for Taco!
rm -rf /
One of the reasons I love unix, is that it will let you shoot yourself in the foot, and it will steady the gun while you take aim at your toe.
S.E.S.S.D.E.N.E.E.NW from west end of hall of mists
If you like scripting and all things Unix I highly recommned Unix Power Tools. I bought a copy last month. All the things about Unix that could not necessarily fill an entire book other their own nicely packaged together.
UNIX/Linux Consulting
Another good book is The Unix and X Command Compendium Shows shell commands, and explains what they do. A very good Unix reference book.
:(){ :|:&};:
Do *not* run this on your production servers.
In the free world the media isn't government run; the government is media run.
Well yes obviously perl would have to be in /bin, but I don't see what is wrong or difficult with that? I just looked and bash is over 600k so it is not like it is lightwieght or anything.
Libraries other than the standard set of libraries are not be required for doing the simple tasks that shell scripts often do. I am sure the entire functionality of bash is well within the core of Perl.
It's easy to have readable, reliable shell scripts with scoping, it's just not something you are used to doing apparently.
No I admit I do very little in shell scripting mainly because I do not see the need. Perl supports many many features that ease program and script development.
Also perl has builtins like open, readdir, socket, etc. In shell programming would you not have to do things like `cat file` to read file? Does this not increase the overhead of shell scripts by forking another shell?
Eventhough my original post was mod'd flamebait it is not just a curious enquiry.
The shell helper that I am totally lost without is one that adds directory history to bash and ksh. You can find it here: _cd
I guess I never really got the idea of a stack of dirs being useful, since I seem to bounce around more at random than anything else. I prefer to have a cache of places I've recently been.
Bonus puzzle for slashdot readers: using the cd with history function, what directory is this command likely to take me to?
From the site:
This tutorial assumes no previous knowledge of scripting or programming, but progresses rapidly toward an intermediate/advanced level of instruction (...all the while sneaking in little snippets of UNIX wisdom and lore). It serves as a textbook, a manual for self-study, and a reference and source of knowledge on shell scripting techniques. The exercises and heavily-commented examples invite active reader participation, under the premise that the only way to really learn scripting is to write scripts.
Together, we will drive the rats from the tundra.
The trick with Windows is that you can do many of these same things, but this power comes from doing it in WSH or VB (or C/C++ or an ASP or whatever language you're comfortable with. I've even done it in Perl.) You use the COM interfaces of the shell object to enumerate through directory trees and files. You can stream each of those files into the COM interface of another program that accepts streams. You can search, you can pipe stuff all over, and you're not limited to a single instance of stdin, stdout and/or stderr.
It's not unlike shell scripting, it's just a different language. Each application is able to expose whatever it feels is most important in whatever fashion it thinks is best. DevStudio, for example, lets the scripting host user get to the workspace, the project, and any of the tools.
The biggest problem I have with it is that stdio is not "guaranteed" to be supported by every application under Windows. stdio is the glue that binds all the UNIX utilities together. That's the beauty of stdio -- as the sole mechanism for I/O for most tools, it became the defacto application interaction interface. Windows doesn't have that: most Windows apps don't offer any automated IO at all. And some of the ones that do seem to have interfaces pasted on after the fact. But the ones that do expose properties and methods via COM are easy to access, and easy to control from anywhere. And using the interfaces tends to remove the ambiguities: in UNIX if you're using 'cut' to parse a phone list but the name field sometimes contains commas, you end up hacking around solutions to make them work. A COM-based solution would provide an interface containing a Name field.
Windows is not alone in this limiation, either. UNIX suffers from a similar problem: how do you meaningfully pipe data to and from an X window, or even to a curses app? Is it consistent between apps? Most apps I am familiar with that offer such features in their applications had to have code added to actively support a meaningful commandline interface to their programs through the use of dozens of command line switches. Without this sort of code, using stdio to parse the output of a curses-based application becomes a tedium of screen scraping.
Don't get me wrong: I have a bevy of UNIX-like command line utilities for Windows, I use Cygwin and bash when I need to (although the file system mapping is worse than I could have imagined), and I will fire up a CMD script long before I think to write it as a VB or C++ program. I'm far more comfortable with the sh-style tools -- I grew up with them.
I'm not saying stdio is better or worse than using the COM interfaces of Windows; I'm just saying it's "different." And you certainly shouldn't be reinventing the wheel to script up utilities in Windows.
John
This would make a great programming/scripting language:
./skriptizzl /bin/shizle detected a non rhyme stizzle in your shizzle. Line 10 son, check it out yo!
#/bin/shizle -yo
#declare a gangsta (variable) called slim
I'm a big ass gangsta and my name is slim
#link in the math pimp (library)
math pimp is in tow and don't you fsck with him
#initialize slim to the hos (linked list) 4,3,2,1
# this causes an error because there is no rhyme
4 and 3 and 2 and 1 now slim and his hos be comming for you
#open a shoutout (file)
Yo, here's a shoutout to the users out there
hey Andy (CR LF)
hey Amy (CR LF)
hey Ben (CR LF)
hey Zack (CR LF)
#exit with no error code
peace out
%
errah
JET Program: see Japan, meet intere