More Simple Scripts

Mark Stockton

David Fiedler's "My Favorite One Liners" (SysAdmin, vol. 1, no. 1) prompts me to describe some additional ways of maximizing the compactness of scripts while retaining readability, saving disk space, and making the scripts a little more flexible. What's more, all of this can be accomplished within the limits of Mr. Fiedler's "KISS" (Keep It Simple, Sysadmin) philosophy.

For example, the crtolf one liner is fine for what it does, but people who need this utility will also most likely need a tool that does the opposite -- an lftocr utility. Instead of creating a separate program, which would waste disk space, how about the following:

:
#
# crtolf | lftocr
# filter all occurrences of a line feed
# and translate to a carriage return
# or filter all occurrences of a carriage
# return and translate to a line feed
#
if [ "$0" = "crtolf" ]
then
tr "\015" "\012"
exit 0
fi
tr "\012" "\015" 

In this example, only one file needs to be created and then a link can be created to the other file name used to execute the program for the desired mode of operation. If the above is entered as crtolf, the administrator merely needs to execute an

ln crtolf lftocr

to create a single script that serves both purposes. The $0 built-in shell variable will contain the name of the program and execute the shell script accordingly.

Similarly, Mr. Fiedler's kind script definitely keeps things simple, but it requires that the user be familiar with the output of the file command so that the grep utility will catch what the user wants. In keeping with my preference not to oversimplify at the expense of usability, I would suggest something like the script in Listing 1. While this is a little more complex than a one-liner, it demonstrates some other handy ways of making a single script handle multiple, but related, assignments. As in the previous example, the administrator need only enter the file once, then create the appropriate links to the arguments passed to the case statement. The `basename` $0 handles the rest. The FILE, EOL and DTOEOL variables are created to save typing; make the program logic readable; allow centralized access to redundant statements which may need to be debugged or modified; and, in the case of EOL and DTOEOL, allow the capability of building new statements which might be added later in order to increase functionality.

The above script will function basically the same way as Mr. Fiedler's. A

more `scripts /usr/local/bin` 

will pass all scripts located in /usr/local/bin to the more command.

An

execs /usr/lib

will display all binary executable programs in /usr/lib.

So, what if the user wants to recursively search a directory tree for a specific type of file? Well, place the script from Listing 2 in a script named all and you have a nice little "script system." (The use of script systems creates another definition for KISS -- Keep It Simple and Small.)

Now you have a script system which allows the use of human language syntax to get the results you're looking for. If you need a way to search your system for scripts that you may want to hack on or explore, try something like:

all /etc/conf scripts

and you'll get a listing of all scripts under the /etc/conf directory tree. One word of caution: this script will eat up processor resources, so you may want to drop its priority or execute the program when system activity is low. Note that in the interest of brevity, error checking is kept to a minimum. If the arguments passed to all are in reverse order, the program will simply return the user to a shell prompt because the find command will fail.

One final observation: even with one-liners, the use of comments is important. Careful selection of variable and program names can minimize the need, but it is quicker to read a program's comments than it is to look up rarely used commands like tr in the manual pages.

About the Author

Mark Stockton is a UNIX Case Manager in the Compaq Computer Coporation Systems Division Phone Support Group and has been involved with UNIX support and administration for over six years. He can be reached via email as mark@cpqhou.compaq.com or via CompuServe in the Compaq forum (!go compaq).