Shell Objects

Christopher A. Jones

Maintaining UNIX systems often involves programming. Unlike programming for application development, a compiled language usually isn't appropriate to perform routine system tasks. The usual tool for such tasks is a scripting language such as the Korn shell, which can help automate the countless configurations, updates, file distributions, and statistic gathering that's required in system administration. It is rarely the case that a UNIX machine is alone, and as a result, network-wide shell programming definitely has its complications. Every flavor of UNIX varies slightly in its architecture. While most features are present, file paths and command syntax often vary from machine to machine. These variations complicate network-wide tasks such as copying a network-wide version of inetd.conf to multiple systems or tracking stats from syslog.

Although shell programming can be powerful, it can also seem inefficient if you make frequent calls to standard UNIX tools, or have to write several different versions of your script for different systems on your network. It's easy to picture shell scripts as a simple string of UNIX commands, and to many, that is solely what they're used for, but shell scripts can be much more. If you've tried to perform a network-wide system change, or gather statistics, you've probably started with a list of host machines, and then executed a remsh command to each one, and collected your data or issued your command. Upon retrieving the information or evidence of the change, you may run awk or grep through the resulting file to pull out the information needed. Although this works, it can involve rewriting the script several times, or weighing it down with case statements to meet the differences of the machines on your network.