Blog Tags: 

Friends don't let friends program in shell script

Lately I've been going over a hellish patch-work of old shell scripts we wrote to automate some internal processes and I realized something: friends shouldn't let friends program in shell script.


  • Shell script is ugly.
  • Shell script is unreliable.
  • Shell script doesn't have exceptions.
  • Shell script is hard to debug.
  • Shell script is hard to test.
  • Shell script isn't object oriented.
  • Shell script is full of idiosyncratic cruft.
  • Shell script doesn't have any decent data structures.
  • Shell script doesn't scale.
  • Shell script encourages code duplication.

The problem with shell script is that it's so deceptively easy to get started. Once you've started adding each bit of extra complexity seems easier than trashing the whole thing and starting from scratch in a decent language (e.g., Python) with a decent design.

Speaking from personal experience, nearly every time I have used shell script in recent times for something that isn't completely trivial, I have come to regret it. Ugh.

Sometimes you don't have a choice. For example, one time I had to use shell script to create a transparent command line hijacking function for a utility I was working on, and just look at the abomination I am ashamed to have been forced to write:

hijack_command() {

    ORIG_COMMAND=$(which $COMMAND 2>/dev/null)

    eval "

        function $COMMAND() {
            for arg; do
            if $CALLBACK; then
                eval $NEW_COMMAND \${args[*]}
                if [ \"$ORIG_COMMAND\" ]; then
                    eval $ORIG_COMMAND \${args[*]}

When a language forces you to do nested metaprogramming something as trivial as this, run and don't look back!

Have you ever regretted using shell script? Share your thoughts!


Couriersoftware's picture

Hi Liraz

So, lets say a Shell script is ugly; what is shiny?

What is the alternative?

Scripting languages like Perl/Python will to the job?



Jimmy O'regan's picture

Python is nice and neat. It's easy to program in, easy to read, and has an extensive standard library which comes with the kitchen sink so you can get many common tasks done with just a couple of lines of code.

I used to program in Perl and I don't recommend it, unless job security is your primary motivator in which case use Perl, go nuts, and pass it all through Liraz's Perl obfuscation service too:

Neil Aggarwal's picture

For anything beyond trivial, I use Java.  It is a very structured language so the compiler catches most errors.

Daniel Serodio's picture

Java intentionally hides the Operating System from the programmer, and these kind of automation tasks are very OS-specific. Most *nix sysadmins know and like Perl, which is fine for quick hacks, but I think Python is much more elegant, and therefore, maintainable.

Besides, programming in Python is a real joy, and having a REPL shell is great for prototyping.

Neil Aggarwal's picture

Java has system calls for common OS-specific tasks.  It also allows you to call any arbitrary system command using an exec call.

Python/perl may be better if you are doing a lot of system automation tasks, but since I program in Java for higher level stuff, it is better for me to be able to stick to the same environment for low level stuff too.

Liraz Siri's picture

My take on this is that a programming language is just a tool. Use the right tool for the job. Depending on what you want to accomplish different languages may be better suited. I use Python for most of my programming these days. It's not a speed demon though there are several very serious efforts to bring it's performance up to par with languages such as Java.

Note that for most applications Python's performance is not an issue at all. In the past when I've needed to squeeze out more performance out of a specific bottleneck in my code I've implemented that part in C and then created bindings to Python.

But heck it's not a religious thing. To this day I still use Perl when I need to write a dirty one-liner.

Michael Grünewald's picture

The hijack-command would be easier to write if you use an auxiliary function hijack_command__generate_function that outputs the code that you eval, instead of writing everything between double quotes. At least, it would be easier to write and to read.

The shell is actually hard to debug and to test, but it becomes much easier if one takes the habit to delegate complete treatments to filters: it is then very easy to mock and to prepare for unit testing and it is also very easy to break a pipeline or to `tee` it to see what the program is doing.

I discussed the issue in my last post, I would love to hear your opinions and comments about it!

FOAD's picture

You need to stop wasting resources and get off this planet in a jiffy, moron.
Jeremy Davis's picture

We're pretty clear on the need for users to not be abusive on our forums, so when I saw this, I was on my way to delete your posts.

But then I realised that you were responding to a spammer (that I had previously missed). TBH, I still think that your language was a little harsh, but I must admit that I sometimes have similar thoughts when spammers waste our time and resources posting their crap!

Have an awesome day! :)


Add new comment