Shell scripts are notorious. It doesn’t matter which way you look at them they are usually quick, dirty, thrown together to suit a particular purpose and then forgotten about 10 minutes later in favour of something more sparkly.

That being said, shell scripts are the backbone, the nitty gritty of any server environment. Many of our quick and dirty scripts are in service long after we’ve moved on to bigger and brighter things binding parts of the server environment together like duct tape and superglue.

As developers we love our standards. There is a standard for everything, whether it be the POSIX standard for environments or a language or framework standard for how we format our code. These standards are in place to ensure that our code works as expected and that developers who come after us can read and maintain what we have written further down the line.

Within shell scripts however, there is a general feel of “I don’t care”. They serve a purpose, do their job and their existance is usually forgotten about, hooked into a cron job somewhere that nobody every really knows about or understands the reason for.

Should we care about the quality of code within these scripts? My answer to this is most definitely yes. When scripting tools such as sed, awk and grep which are difficult to understand in the first place, the quality of the scripts that tie them together should be of the highest possible standard. After all, these scripts tie together some of the most dangerous commands ever devised and a mis-placed space can mean the difference between a perfectly functioning system and the smouldering remains of Nagasaki in 1945.

When we care so much about the quality of our software and web applications, is it right that the servers they run on are held together with undocumented obscene monstrosities which if written in PHP, C# or Java would never have made it past the scrutiny of a dead walrus let alone QA?

In some instances most definitely the answer has to be yes. If you’re shoring up a system at 3am in order to make sure a critical service is able to run then that ragged piece of duct-tape you slapped into position is exactly what is needed however when developing a more complex script which is intended to keep the lights on for the next 2 years then it needs to follow a standard and be entirely maintainable.

Quick fix scripts should never be permanent solutions. Just like you remove a sticking plaster once a wound has healed, leaving a quick fix script in place once the underlying cause has been resolved is pointless and can often cause more harm than good.

Longer term scripts however need to be fully documented and adhere to standards. They should be both readable and testable. If they rely on non-standard tools like the script in my previous blog on Plotting events with gnuplot, they need to be highlighted. Complex conditions and commands should be documented so that the person tasked with maintaining it in the future knows what the script is doing. They should adhere to standards laid out for all code, follow the same naming conventions and similar structures.

If I come to a shell script that I cannot read or understand I posit that I am well within my rights to toss the developer or engineer responsible into the darkest part of the basement with little more than bread, water and a copy of the clean coders handbook.

[Update] I’ve just been informed that I was being overly generous by offering bread and water so in light of that they don’t get the bread, just water and a book. But no light. They can read in the dark!

Leave a Comment