0

I have a bash script that for some reason on my iMac running GNU Bash 3.2.57 that comes with Mojave (10.14.5) is continuing to cause ERR signals to be fired and handled by signal traps even when the eval command generating it is used in a condition:

trap 'exit $?' ERR
if ! eval false; then
   echo THIS NEVER SHOWS
fi

On linux machines this executes as expected, and I believe on some other Macs too (though I found at least one other where it doesn't). Seems the only way to avoid is disable the trap and re-enable afterwards. Removing 'eval' also works, but in the actual script I have this would not be straightforward to do.

Dylan Nicholson
  • 1,301
  • 9
  • 23
  • that version is about 12 years ago, but yea it runs fine with v4.4 – Rorschach Feb 23 '20 at 22:20
  • Short answer: stop expecting `bash` 3.2 to behave compatibly with modern versions of `bash`. Either write a POSIX-compatible script (which doesn't provide for `ERR` traps at all) or require a reasonably modern version of `bash` (4.2 or later). – chepner Feb 23 '20 at 22:22
  • The main issue does seem to be the eval, and to be honest I don't like using it for all sorts of other reasons (mainly to do with escaping). But it's used to enable the scripts to have a "dry run" mode where it just prints out the commands to be executed rather than executing them. If there's a good way of doing that without 'eval' I'm all ears! – Dylan Nicholson Feb 23 '20 at 23:49

1 Answers1

1

The code in the question also triggers the ERR trap on an ancient Linux system running Bash 3.2.25. This code avoids the problem on that system:

trap 'exit $?' ERR
if ! (eval false); then
   echo THIS NEVER SHOWS
fi
pjh
  • 6,388
  • 2
  • 16
  • 17
  • Thanks, handy trick. Not particularly worried about the expense in this case. I have an idea we can easily avoid 'eval' but it would mean cleaning up all the code already in place that does the extra quoting/escaping necessary to use it! – Dylan Nicholson Feb 24 '20 at 21:40