More Simple Scripts
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,
space, and making the scripts a little more flexible.
all of this can be accomplished within the limits of
"KISS" (Keep It Simple, Sysadmin) philosophy.
For example, the crtolf one liner is fine for what it
but people who need this utility will also most likely
need a tool
that does the opposite -- an lftocr utility. Instead
creating a separate program, which would waste disk
space, how about
# 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" ]
tr "\015" "\012"
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
the program for the desired mode of operation. If the
above is entered
as crtolf, the administrator merely needs to execute
ln crtolf lftocr
to create a single script that serves both purposes.
The $0 built-in shell variable will contain the name
program and execute the shell script accordingly.
Similarly, Mr. Fiedler's kind script definitely keeps
simple, but it requires that the user be familiar with
of the file command so that the grep utility will catch
the user wants. In keeping with my preference not to
at the expense of usability, I would suggest something
like the script
in Listing 1. While this is a little more complex than
it demonstrates some other handy ways of making a single
multiple, but related, assignments. As in the previous
administrator need only enter the file once, then create
links to the arguments passed to the case statement.
$0 handles the rest. The FILE, EOL and DTOEOL
variables are created to save typing; make the program
allow centralized access to redundant statements which
may need to
be debugged or modified; and, in the case of EOL and
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.
more `scripts /usr/local/bin`
will pass all scripts located in /usr/local/bin
to the more command.
will display all binary executable programs in /usr/lib.
So, what if the user wants to recursively search a directory
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
for KISS -- Keep It Simple and Small.)
Now you have a script system which allows the use of
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
when system activity is low. Note that in the interest
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
About the Author
Mark Stockton is a UNIX Case Manager in the Compaq
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 email@example.com or via CompuServe
in the Compaq forum (!go compaq).