bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Incorrect "jobs" output after "trap ... ERR" command


From: Keith Thompson
Subject: Incorrect "jobs" output after "trap ... ERR" command
Date: Wed, 7 Jan 2015 12:57:27 -0800

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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]