Re: How to print the actual command for BASH_COMMAND in trap?

[Koichi Murase]

2021年6月13日(日) 12:50 Peng Yu <pengyu.ut@gmail.com>:
>
> I don't get it. I still only get 'true' instead of 'false'. Could you
> let me know what is wrong?

Ah, OK. The behavior seems to have changed in Bash 5.1.

$ bash-3.0 c.sh
declare -- BASH_COMMAND="declare -p BASH_COMMAND"
declare -- BASH_COMMAND="declare -p BASH_COMMAND"
$ bash-3.1 c.sh # The same for 3.2, 4.0, 4.1, 4.2, 4.3, 4.4, 5.0
declare -- BASH_COMMAND="true"
declare -- BASH_COMMAND="false"
$ bash-5.1 c.sh # The same for the current devel branch
declare -- BASH_COMMAND="true"
declare -- BASH_COMMAND="true"

This is changed by the commit 9831556e (commit bash-20200117
snapshot). The related changes are

----------------------------------------------------------------------
diff --git a/CWRU/CWRU.chlog b/CWRU/CWRU.chlog
index 90451e4f..5cfbebdd 100644
--- a/CWRU/CWRU.chlog
+++ b/CWRU/CWRU.chlog
@@ -7085,5 +7085,18 @@ sig.c
    run_pending_traps the next time a trap handler for that signal
    runs. Bug report from Martijn Dekker <martijn@inlv.org>

+          1/15
+          ----

+trap.c
+ - run_pending_traps: save and restore the value of running_trap around
+   cycle through pending signals so recursive trap handler calls don't
+   set running_trap to 0
+ - _run_trap_internal: allow some signals the shell treats specially
+   (e.g., SIGINT) to run recursive handlers
+ - _run_trap_internal: don't turn off SIG_INPROGRESS flag if it was on
+   for this signal when _run_trap_internal was called
+ - _run_trap_internal: save and restore the value of running_trap around
+   running the trap handler, except for SIGCHLD. Fixes bug reported by
+   Martijn Dekker <martijn@inlv.org>

diff --git a/trap.c b/trap.c
index 3cb67cdf..a4c991bc 100644
--- a/trap.c
+++ b/trap.c
@@ -330,6 +331,7 @@ run_pending_traps ()
 #if defined (ARRAY_VARS)
   ps = save_pipestatus_array ();
 #endif
+  old_running = running_trap;

   for (sig = 1; sig < NSIG; sig++)
     {
@@ -440,7 +442,7 @@ run_pending_traps ()
      }

    pending_traps[sig] = 0; /* XXX - move before evalstring? */
-   running_trap = 0;
+   running_trap = old_running;
  }
     }

@@ -976,6 +979,8 @@ _run_trap_internal (sig, tag)
   ARRAY *ps;
 #endif

+  old_modes = old_running = -1;
+
   trap_exit_value = function_code = 0;
   trap_saved_exit_value = last_command_exit_value;
   /* Run the trap only if SIG is trapped and not ignored, and we are not
@@ -991,6 +996,9 @@ _run_trap_internal (sig, tag)
 #endif
     {
       old_trap = trap_list[sig];
+      old_modes = sigmodes[sig];
+      old_running = running_trap;
+
       sigmodes[sig] |= SIG_INPROGRESS;
       sigmodes[sig] &= ~SIG_CHANGED;   /* just to be sure */
       trap_command =  savestring (old_trap);
@@ -1050,8 +1058,10 @@ _run_trap_internal (sig, tag)

       temporary_env = save_tempenv;

+      if ((old_modes & SIG_INPROGRESS) == 0)
  sigmodes[sig] &= ~SIG_INPROGRESS;
-      running_trap = 0;
+
+      running_trap = old_running;
       interrupt_state = old_int;

       if (sigmodes[sig] & SIG_CHANGED)
----------------------------------------------------------------------

In particular, the last hank made "false" to "true" in your test case.
I guess the change has been made after the report at

https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00014.html

Hmm, I agree the newer behavior is more reasonable, so there is no way
to get the currently executed command in the trap handlers.

--
Koichi