Unless you tell it otherwise, Unix assumes input is coming from the keyboard, and output is to the screen. When you're running a script, that's not always what you need, so redirection comes into play. For example, if you type ls -l, you get a directory listing on your screen. If you type ls -l > filename, the output is written to the named file. Similarly, you can use a file's contents as input to a command by entering command < filename.

Pipelines, on the other hand, connect programs. The command Program1 | Program2 makes the output of program1 become the input to program2. For example, if you want to print a directory listing to a specific printer, you can type ls -l | lp -dprintername. The output of the ls command (a directory listing) becomes the input to the lp command.

These commands work the same way in a script, with the added wrinkle that you can use parameters to vary the elements. Say you want to write a script called "person" that looks to see if a specific user is logged on, and then performs some task based on the result. The first command in it (after the shell definition, of course) would be who | grep <username>, where <username> is the person you're looking for. The who command asks the system who is logged on, and pipes that information to the grep command, which searches for and displays the string, in this case a user name, that you're looking for.

That's pretty useless if you want to know about a different person each time; you'd spend half your life editing the script. But if you change it to who | grep $1, and then include the username when you run the script (say, person sam, which would look for username sam), you now have a flexible utility that looks something like this (Lines preceded by the # character are treated as comments):

#! /bin/sh

# This looks for a specific user 
#
if who | grep $1
then
# Perform some task if the name is found, in this case a directory listing
ls
else
#Do something else if it isn't, in this case just display a message
#
echo  "$1 not logged in"
fi

Now save the file, make it executable using chmod +x person, and try it out. Looks like a real programming language, doesn't it?

Shell scripting actually offers most of the functions you'd expect in a "real" (compiled) language — loops and case statements and conditions and even math — yet, it's fairly straightforward to whip up a script in an hour or two that would have taken days in a compiled language. That's what has endeared it to administrators for all these years.

How do you learn shell scripting? There are, of course, Internet sites that provide tutorials and examples (here's a good one for the Bash shell, for example), but you can't beat a good book that you can have at your elbow to refer to as you muddle through those first efforts. The most up-to-date and comprehensive book I've found is Classic Shell Scripting, by Arnold Robbins and Nelson H.F. Beebe, published this year by O'Reilly. The authors walk you through creating your first script, and from there take you on a fascinating ride through the ins and outs of progressively more complex scripts, such as the ones in the sample chapter online (PDF). Virtually every scripter, from novice to veteran, can learn something from this book.

But, you say, I don't play in Unix. I'm strictly a Windows type of guy (or gal). Never fear: shell scripting has moved beyond DOS batch files there too. Stay tuned — next time, we'll talk about KiXtart, a free language designed to help administrators cope with the trials of managing computers, especially on a domain.