A bash irritation: the incompatible exec

August 14, 2008

There are a reasonable number of good things about bash (and the general GNU program attitude of which it is a standards-bearer). But every so often it does something that causes me to grind my teeth. This time around the irritation is what bash has done to the innocent exec command.

What they've done is simple: they've made exec take options.

The easiest way to explain the problem with this is in illustrated form. So:

sh$ exec -rc
<... program runs ...>

bash$ exec -rc
bash: exec: -r: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
bash$ exec -- -rc
<... program runs ...>

sh$ exec -- -rc
exec: --: not found


Since bash's exec takes options, it must complain about invalid options. This makes it reject valid programs that happen to start with a dash, so it needs a way around that, but the way is not compatible with other Bourne shells because, of course, exec does not take options so there is no need to support an option to ignore things that look like options.

(As a bonus irritation bash does this all the time, not just when invoked as bash. So much for compatibility.)

If you are in this situation, it may be helpful to know that one way of checking to see if you are in bash is to look for the presence of a $BASH_VERSINFO environment variable. There are probably better ways, but this one works well enough for me and I could spot it in the bash manpage.

(I stubbed my toe on this today because Ubuntu 8.04 changed /bin/sh from bash to another, more strictly Bourne compatible shell, which made my previous slapdash workaround stop working so I had to actually pay attention to this issue.)

Written on 14 August 2008.
« The first principle of analyzing compromised machines
Using a non-standard shell as your login shell »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Aug 14 00:57:10 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.