The innermost circle of Hell, as we all know, is trying to resolve printer driver issues for all eternity. Ben doesn’t work with the printers that we mere mortals deal with on a regular basis, though. He runs a printing press, three stories of spinning steel and plates and ink and rolls of paper that could crush a man.
Like most things, the press runs Linux- a highly customized, modified version of Linux. It’s a system that needs to be carefully configured, as “disaster recovery” has a slightly different meaning on this kind of heavy equipment. The documentation, while thorough and mostly clear, was obviously prepared by someone who speaks English as a second language. Thus, Ben wanted to check the shell scripts to better understand what they did.
The first thing he caught was that each script started with variable declarations like this:
GREP="/bin/grep"
CAT="/bin/cat"
In some cases, there were hundreds of such variable declarations, because presumably, someone doesn’t trust the path variable.
Now, it’s funny we bring up cat
, as a common need in these scripts is to send a file to STDOUT. You’d think that cat
is just the tool for the job, but you’d be mistaken. You need a shell function called cat_file
:
# function send an file to STDOUT
#
# Usage: cat_file <Filename>
#
function cat_file ()
{
local temp
local error
error=0
if [ $# -ne 1 ]; then
temp=""
error=1
else
if [ -e ${1} ]; then
temp="`${CAT} ${1}`"
else
temp=""
error=1
fi
fi
echo "${temp}"
return $((error))
}
This ‘belt and suspenders’ around cat
ensures that you called it with parameters, that the parameters exist, and failing that, it… well… fails. Much like cat
would, naturally. This gives you the great advantage, however, that instead of writing code like this:
dev="`cat /proc/dev/net | grep eth`"
You can instead write code like this:
dev="`cat_file /proc/dev/net | ${GREP} eth`"
Much better, yes?