BASH Template Promises Safer Scripts

Many bash scripts start out as something quick and dirty but then become so useful that they live for years, indeed sometimes seeing more use than our traditional programs. Now that you can even run bash well under Windows (although, you’ve always been able to run it there if you tried), there are even more opportunities for your five-minute bash script to proliferate. [Maciej] decided he was tired of always having to patch up his quick and dirty scripts to be more robust, so he created (and shared) his boilerplate template for scripts.

Probably most of us have at least some basic template we start with, even if it just our last script project. What’s nice about [Maciej’s] template is that he documents what’s going on with each part of it. It is also relatively short without a lot of excess stuff. Of course, you’ll probably customize it, but it is a great place to start.

The template has a good shell selection line using env and also sets up basic error handling. That includes a trap function that runs on termination and argument parsing including a help message. There’s a oneliner that sets the current directory to the script directory (although you don’t always want that).

The only real excesses in the template are the short example script and a function that sets colors based on the terminal type that you might not need for your script. However, it is nice to print warnings with highlight color when they are not redirected and this code handles that for you.

If you don’t want to bother yanking the code from a web page, the template is also on a GitHub Gist. As [Maciej] points out, there are other similar projects out there, but some of them are a bit bloated.

If you want to clean up your scripts, try lint in the form of ShellCheck. We’ve talked about writing safer scripts before and also our own system for dealing with traps.

21 thoughts on “BASH Template Promises Safer Scripts

    1. This week I was working with Windows batch file that has almost 500KB and checks/downloads curl.exe before doing anything useful. I bet “2-3 VT220 screens” are taken up by cmd window size changer and menu ASCII art.

      1. I recently had to do an analysis of “which language to use” for a client. The language needed to be available across many types of systems, stable, and easy to write in the manner of scripts. The three top contenders were C (including C++), Python, and Perl.

        Python lost out because it’s very new, and still changing in myriad ways. I just recently had to convert a project between python2 and python3 for a client, and it still has a lot of what appear to be ill thought out features that make it look like it was designed as a final project by a CS undergraduate.

        (I’m not intending to knock python, lots of people like it and that’s fine – just be aware that it’s in flux, and has issues.)

        Perl has all the features of Python and then some, has been stable for decades, and is available on all systems. It’s installed by default on linux, and has a wide selection of libraries available. Since (for example) file manipulation and task management are defined as part of the language, it’s implemented *the same* across all architectures, so instead of having to deal with different library calls and features with #ifdef selecting which architecture or library call, you can have one source that’s used everywhere. You can also compile it and the executable will run on a system that doesn’t have the language installed.

        If you have good coding discipline so that your code is easy to read and straightforward, perl is a good choice for scripting. You can do a lot in a few lines, which greatly reduces the time it takes to make something.

        A lot of people can’t write readable code without being constrained to do so by the language, and that’s fine – write code in something else.

        But when you’re ready to take the training wheels off, perl can be a pretty powerful tool – much *much* more powerful than bash or other scripting languages.

        1. I’m a bit lost about your comments about python. Python 3 came out in 2008 and initially they were gooing to sunset python2 in 2015, but extended that to Jan 2020. It’s not really a new language at this point, though i will concede it is newer than C and Perl.

          Can you elaborate on the issues in python3?

        2. I tend to slightly disagree with you. For new Programmes Python 3.7 ( or later9 would be a good and stable choice . I have use Python3./ as an alternative to Bash AND as a full level programming language. I an no fan of Python using 4 blanks to separate programme if blocks…much prefering the C { and } .

  1. Ah… Takes me back to the days of scientific computing. Had a manager that didn’t like the new-fangled modern scripting languages and insisted that all terminal scripts and web-consoles were done in awk / bash implementations.
    That resolved in long (but interesting) discussions on how to do robust and useful script boilerplating for re-use and maintenance.

    These days I barely try, and just use python3.

    1. I can’t tell if this is trolling or not, but I’ve actually said once before “and then what parts depend on which others is documented in the Makefile.”

      For better or worse, the basic idea of make is brilliant, but it’s full of so many over-and-above kludges in practice that people get put off of it.

      Half of the dumb grunt work for Hackaday is done by Makefiles.

    1. Horrible to use? A Bash script is just the series of commands written to a file, which one would use on the command line anyways.

      That’s how such scripts get written here: simply don’t type into the command line directly, but into a text editor. Then copy&paste line by line to see what happens. Once the series of lines does something useful, give the file a name and the script is done.

      Can’t think of an easier way to write code. No need for includes, no need for main(), no need for opening files, just hack away. Because this works with the shell only, Python, Perl & Co. never got a foothold here.

      1. Yes. Welcome to the ‘happy-path’ of the script. ^_^
        I agree ofcourse, that’s basically what a script is.

        But not how a script is kept robust.
        How often do you have to do commands that have a condition?
        – If a file exists, remove it (or if not exists, copy it in)
        – If diskspace is over 80% remove some stuff.
        – If a mount is open, close it. (or other way around.)

        The CLI (and thus any (type of sh)-script) is Turing-complete for the sake of being capable to check these conditions and loops / jumps.

        A boilerplate mostly helps to make stuff readable and such.
        ‘source’ (include) it in and you magically have a whole new set of functions.

          1. For instance, a common problem on Macintosh systems is not understanding shell quoting. Then someone has a disk volume with a blank in its name (like “Macintosh HD”) and suddenly a badly escaped rm -rf command wipes everything.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.