bugThe GNU Bourne-Again SHell - Bugs: bug #67679, Exit due to -e can be canceled by...

 
 

bug #67679: Exit due to -e can be canceled by ERR trap

Submitter:  None
Submitted:  Thu 06 Nov 2025 10:53:59 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Wed 12 Nov 2025 02:29:30 PM UTC, comment #4: 

On 11/12/25 7:08 AM, anonymous wrote:

> Follow-up Comment #3, bug #67679 (group bash):
>
> If you declare this as a feature, I will not oppose. Just wanted to raise
> this.
>
> My reasoning was: The concept of cleanup/exit/termination handlers is
> widespread (atexit() system call, Java JVM shutdown hooks, etc.), but none of
> them can revise the decision to exit/terminate. They can just react to that
> fact. For consistency, I had expected this behavior here as well.


I don't believe those other languages have a feature equivalent to
`set -e'. Their exit hooks (e.g., atexit()) are similar to the EXIT
trap, not the ERR trap.

> If a trap is meant to be a general purpose feature to provide code that is
> called when a certain (usually abnormal) condition occurs but otherwise must
> not assume that the shell is going to terminate, then my expectation was
> wrong.


If you do nothing special, the shell will terminate. If you don't want
the shell to terminate on the error, you as the programmer have to take
specific action. I don't think this is the same thing as the "trap not
assuming the shell will exit."

Chet Ramey <chet>
Group administrator
Wed 12 Nov 2025 12:07:53 PM UTC, comment #3: 

If you declare this as a feature, I will not oppose. Just wanted to raise this.

My reasoning was: The concept of cleanup/exit/termination handlers is widespread (atexit() system call, Java JVM shutdown hooks, etc.), but none of them can revise the decision to exit/terminate. They can just react to that fact. For consistency, I had expected this behavior here as well.
If a trap is meant to be a general purpose feature to provide code that is called when a certain (usually abnormal) condition occurs but otherwise must not assume that the shell is going to terminate, then my expectation was wrong.

Anonymous
Tue 11 Nov 2025 03:48:50 PM UTC, comment #2: 

It's an interesting question. The whole idea behind the ERR trap is to give
the shell programmer more flexibility than simply exiting (cleanup, print a
warning message, etc.). The current behavior provides that flexibility: if
you don't want to exit, turn off set -e; if you do, leave it alone.

Chet Ramey <chet>
Group administrator
Thu 06 Nov 2025 10:40:24 PM UTC, comment #1: 

Given that non-zero exit does not always mean failure, ‘set -e’ is necessarily prone to false positives.

It follows that it is essential to have some way to cancel exiting when a false positive is detected. What else would you suggest?

Martin D Kealey <kurahaupo>
Thu 06 Nov 2025 10:53:59 AM UTC, original submission:  

Configuration Information
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall
uname output: Linux VMX-T16-7661 6.8.0-86-generic #87-Ubuntu SMP PREEMPT_DYNAMIC Mon Sep 22 18:03:36 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 21
Release Status: release

Description:
    The man-page says under set -e: "...A trap on ERR, if set, is executed before the shell exits. ..."
    If such a handler sets "set +e", the original flow is resumed after the handler exits.
    I would expect that once the exit due to "set -e" is initiated, it should not be cancelable.

The example script in Repeat-By (also find attached) produces the following output:
    main: the next command will fail
    handler: the next command will fail
    handler: after failing command
    main: after failing command

Expected output:
    main: the next command will fail
    handler: the next command will fail
    handler: after failing command

Repeat-By:
    handler () {
      set +e
      echo "handler: the next command will fail"
      false
      echo "handler: after failing command"
    }

    trap handler ERR

    set -e
    echo "main: the next command will fail"
    false
    echo "main: after failing command"

Anonymous

 

Attached Files

Attached Files
file #57786:  set-e-handler.sh added by None (224B - application/x-shellscript - Bash script to illustrate the observation)

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by kurahaupo (Posted a comment)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-11-11 chet StatusNone Wont Fix
    2025-11-06 None Attached File- Added set-e-handler.sh, #57786

    Back to the top

    Powered by Savane 3.16-598c.
    Corresponding source code