Is it possible to emulate older versions of Bash?

Question

Is it possible to emulate (is that the right word?) previous versions of Bash?

I am using 4.3.11, and I am curious to know if my scripts are compatible with some earlier versions, but I don't want to actually install an earlier version. I could dig through the changelogs and figure out what features I'm using that are lacking from previous versions, but that seems a bit tedious. I was hoping for some kind of magical command line option or script command, instead (wishful thinking, probably).

Answer 1

No, bash can't emulate older versions of bash. But it's pretty easy to set up a test environment that includes an older version of bash.

Installing older version of individual software is tedious if you have to install each software package manually, not to mention resolving the library incompatibilities. But there's an easier solution: install an older distribution. Installing an older distribution, with a consistent set of software including development packages, costs about $1 of hard disk space and maybe an hour to set up the first time.

The schroot package makes it easy to install an older (or newer!) Linux distribution that's running on the same system as your normal Linux system. You can easily make a schroot setup where you can run a program in an environment (a chroot) where the system directories point to the older software, but the home directories are those of the normal environment. I wrote a guide for Debian-based distributions; you can easily go back to Debian slink (with bash 2.01.01) this way.

If you want to test with different Unix variants, different CPU architectures, or very very old software, you can run other OSes in a virtual machine. There's a little more overhead (in RAM, disk space, CPU and maintenance) but it's still very much doable.

Answer 2

You can easily test against any version of bash in a docker container.

You can start up a docker container running bash 3.2 like so:

$ docker run -it bash:3.2 

You can mount a folder in the docker, so you can easily test scripts from your machine in the docker container. The following would allow the folder /Users/myuser to be available in the docker container at /myuser

$ docker run -v /Users/myuser/:/myuser -it bash:3.2 

Note, you can use any bash version that's listed here:

https://hub.docker.com/_/bash

and the source for these images can be found here:

https://github.com/tianon/docker-bash/

Answer 3

Write your scripts in a POSIX conforming manner, and then test with a completely different shell, like dash, zsh, pdksh or what have you. Avoid dark corners and gray areas of the shell language; do everything in "canonical" ways.

Of course, that doesn't prove your code isn't stepping on some Bash bug in an old version, but it improves the confidence. For one thing, Bash bugs are more likely found in Bash-specific constructs (which are not exercised by portable scripts) and in those dark corners and gray areas (which are not exercised by many scripts).

In other words, don't do be the world's first shell scripter to land a quadruple reverse eval.

One benefit of making the script portable is that, suppose a user does find that your script doesn't work in their installation which has an older Bash. Well, since the script isn't Bash-specific, maybe they can get it to work with an alternative shell, and one that they are already have installed.

There are only two ways to know whether your code steps on some historic Bash-specific bug. Only one of those ways is halfway reliable (the one you don't want to do: pull out old versions of Bash and test). The other way is to pore over the Bash change history and try to determine whether bugs which existed in any old versions that you care about might be affecting something that your script is doing.

I would just keep a virtual machine hosting some older distribution, and do a regression test on it from time to time.