UNIX Scripting Tips and Ideas – Kimball Hawkins

Compatibility Concerns

Posted on October 4, 2010. Filed under: Opinion |

There are those who consistently beat the drum for shell script compatibility.  They will warn you not to use certain, more modern features of one shell because it “isn’t compatible” or “isn’t portable”.

Now, that is a valid concern in some cases.  If you use lots of bash-only syntax and features, and then have to port your many scripts to a server that doesn’t have bash, you are going to be in trouble.

If you care about that sort of thing.

Because I’ve worked at many companies and on many different operating systems, and because I have developed a large tool set of utility scripts, the problem of compatibility is important to me, but I do not think it should be important to everyone in every situation.

And even with my attention to compatibility, I do draw the line.  I do not need my scripts to be compatible with every possible type of ksh-compatible shell, nor with all versions.

If a syntax or feature is available in all or almost all sh-compatible shell versions of the last ten years or so, I’m just not going to worry about it.  Why should scripts be constrained by the most brain-dead shell version still extant somewhere in the world?

I’ve seen people use only backticks for embedded command execution (i.e. “VAR=`command`”).  Is there any modern sh-compatible shell that doesn’t recognize “VAR=$( command )”?  I don’t care for backticks because, on many terminals, they are hard to see and almost impossible to differentiate from apostrophes.  I like readable code.

I’ve seen people insist on using “if test $var = y” instead of the much simpler “if [ $var = y]”.

Now, come on! The “[ … ]” syntax has been around forever and it’s hard to find a modern shell that doesn’t recognize the improved “[[ … ]]” syntax.

And don’t even mention the “let” command.  All modern sh-compatible shells support both the “var=$(( expression ))” and “(( var = expression ))” syntax.

Why deny yourself the features of modern shells that are, pretty much, universally recognized?  Why restrict yourself to ancient brain-dead syntax?

But, hey, if I ever ran into that situation and I just had to convert all my script utilities to run on some limited, brain-dead shell, I’d just write another script to do the conversion.

Kimball

Recently on UNIX Scripting Tips and Ideas - Kimball Hawkins…