Article development led by
can More code
Mean Fewer Bugs?
One of the coders I work with keeps
removing my calls to system() from
my code, insisting it is better to write
code that does the work I am doing via
the shell. He keeps saying it is far safer
to code using the language we are using than to call out to the shell to get
this work done. I would believe that if
he did not add 10 to 20 lines of code
just to do what I do in one line with
system(). How can increasing the
number of lines of code decrease the
number of bugs?
happy with the one-Liner
You almost had me with your appeal
to simplicity, that having a single line
with system() on it reduces the potential for bugs. Almost, but not quite.
ImAgE BY VIKTORUS
When you call out to the shell from
any language, you are not using a single line of code, but thousands. Calling
a shell at this point is like using a nuke
to kill a flea. That flea will be very dead
when you are done, but you have also
wasted a lot of energy in killing it, and
it may result in collateral damage. Each
and every call to system() is trusting
all that underlying code, and the issue
is not only that there are a lot of lines
under there, but also that the things
the shell can do are extremely powerful—it is probably the most powerful
program on any system.
A command shell on any system—
Unix, Windows, or otherwise—is there
to command the system, and it has accreted to itself, over time, the ability to
do things to the system in a single line
that really should require a bit more
thought. The obvious example is moving and removing files. I would actually
like to think that most programmers
know better than to do something like
calling system() with an rm command, in particular one in which they
supply unchecked user input to the
call to system(). While I say “I would
like to think that,” a voice—a very loud
voice—in the back of my head is screaming, “It’s not so! It’s not so! They’ll do it!
Stop them now!” I hate that voice, but
no matter how I try to drown it out—and
I have tried—there it remains.
A worse offense than invoking the
rm command in a system command
is calling a shell script via system().
Why? Because the poor sap reading
your code later will probably have no
idea what the script does. I am sure it
will have a descriptive name such as
update_sales_2.sh, and that it will
be checked in to the source repository
rather than being stored in the /home/
bob/update_test2/ directory, but
perhaps it won’t, and the fragile setup I
describe here will ring true: when Alice
comes to read the code, she will then
have to go read update_sales_ 2.
sh, so long as she has read access to
Bob’s home directory. She will be reading it at 3 A.M. when something has
broken, and this will all go well and everyone will live happily ever after.
Perhaps my very favorite abuse of
the system() routine in code is when
it is used to build up a complex pipeline of commands. Using pipes in a call
to system() in a program is a fine way
to launch a fork bomb into your system, especially if the pipes are built up
on the fly.
Running a complex piped command from a shell by hand has less
risk of hammering the machine because humans are slow—and supposedly they are paying attention to what
they are doing. Once you put a set of