I've discovered a bash bug that causes the "jobs" command to produce incorrect output after an ERR trap has been defined and triggered.
I've seen it with bash 4.3.11(1)-release on Linux Mint 17 and bash 4.3.30(1)-release on Debian 6.
I have *not* seen it with 3.2.25(1)-release on CentOS 5.10.
The demonstration is interactive; you have to interrupt the "cat" command by typing Control-C, and you have
to run the "jobs" command before the "sleep" commands expire.
$ bash --norc
bash-4.3$ echo $BASH_VERSION
4.3.11(1)-release
bash-4.3$ show_error() { echo ERROR ; }
bash-4.3$ trap show_error ERR
bash-4.3$ cat
^C
ERROR
bash-4.3$ sleep 60 &
[1] 32225
bash-4.3$ : && cat
^C
bash-4.3$ sleep 70 &
[2] 32229
bash-4.3$ jobs
[1]- Running sleep 60 &
[2]+ Running cat &
bash-4.3$ exit
$
Once the bug is triggered, "jobs" shows the command name for the command ("cat" in this case)
that triggered the problem rather than the actual name of the command.
Note also that the show_error() function was invoked when I interrupted the "cat" command the first
time, but not the second time.
The original version of the "trap" command was:
show_error() { printf "\e[1mExit $?\e[m\n" ; }
trap show_error ERR
intended to mimic tcsh's $printexitvalue setting.
--
Keith Thompson <
Keith.S.Thompson@gmail.com>