Bash – When is it important to write portable scripts

bashportabilityscriptingshell

Most code I write is in PHP. I have recently started learning shell scripting. Most of the resources and tutorials that I've come across are specific to Bash. Some warn about bashisms and some don't. I've been reading a lot on here and Stack Overflow.

Whenever an answer uses bashisms, someone will inevitably comment to say:

You shouldn't use <insert bashism here>. It's not portable.

This happens even when the question was tagged with bash. To me, that's like telling a PHP programmer that they shouldn't use code that's new in PHP 5 because it can't be used with PHP 4. Or telling someone they shouldn't write something for Mac because it can't be used on Windows.

When I write in PHP, I pick a minimum requirement and I write forward-compatible code. I don't worry about making it backward-compatible.

If I use #!/bin/bash as the shebang, why shouldn't I use bashisms? I'm starting to get the impression that some people just like to bash bashisms (pun intended) just for the sake of it.

People often use bash and shell interchangeably – probably due to the fact that bash is the default shell on many systems. So I can understand adding a comment to warn that the code uses bashisms, but I don't understand the implication that it's wrong to use them.

Obviously, if I am writing a script strictly for personal use I can write it in whatever language I want. But I'd like to think some of the code I write could be useful to others.

I tried searching for an answer to my question before posting. I found a lot of information about how to test for portability, but couldn't find anything about when it's important to do so.

So, when is it important to write portable scripts?

For example,

what types of scripts should be as portable as possible?
how common are systems that do not have Bash installed?
if the system has Bash installed, will it also have the GNU version of find and other utilities?

Best Answer

As a member of this community I do not often see people disregarding bashisms for things that target bash. When talking about portability, GNUisms are much worse than bashisms. As long as you use bash for your shebang, you can expect the script to be executed using bash. However, you can't guarantee the version unless you explicitly check. Bash version 4 brought some useful features such as associative arrays, but Bash v3 is still widely used on OS X and RHEL 5.

what types of scripts should be as portable as possible?

This is more about your needs and what you choose to support as the developer. If you are writing an install script for an application that supports all types of *NIX, then portability will be very important.

how common are systems that do not have Bash installed?

FreeBSD and Solaris 10 are examples of systems that do not come with bash installed by default. Most Linux systems will have it, with the exception of embedded systems.

if the system has Bash installed, will it also have the GNU version of find and other utilities?

No, and this is the real issue with portability. If portability is important, you should only use shell command features that are defined by the POSIX standard. GNU utilities can be installed on non-GNU systems such as FreeBSD, but they are unlikely to be first in PATH, and you can not rely on those tools to be installed.

Related Solutions

Portable Shell Programming – Resources and References

The autoconf manual has a section on portable shell programming.

Although that's not specifically targeting POSIX, it's probably the most complete collection of what to do and not to do when attempting to write portable shell code.

When to Use Alias, Script, or Function in Bash

An alias should effectively not (in general) do more than change the default options of a command. It is nothing more than simple text replacement on the command name. It can't do anything with arguments but pass them to the command it actually runs. So if you simply need to add an argument at the front of a single command, an alias will work. Common examples are

# Make ls output in color by default.
alias ls="ls --color=auto"
# make mv ask before overwriting a file by default
alias mv="mv -i"

A function should be used when you need to do something more complex than an alias but that wouldn't be of use on its own. For example, take this answer on a question I asked about changing grep's default behavior depending on whether it's in a pipeline:

grep() { 
    if [[ -t 1 ]]; then 
        command grep -n "$@"
    else 
        command grep "$@"
    fi
}

It's a perfect example of a function because it is too complex for an alias (requiring different defaults based on a condition), but it's not something you'll need in a non-interactive script.

If you get too many functions or functions too big, put them into separate files in a hidden directory, and source them in your ~/.bashrc:

if [ -d ~/.bash_functions ]; then
    for file in ~/.bash_functions/*; do
        . "$file"
    done
fi

A script should stand on its own. It should have value as something that can be re-used, or used for more than one purpose.

Best Answer

Related Solutions

Portable Shell Programming – Resources and References

When to Use Alias, Script, or Function in Bash

Related Question