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

[Peng Yu]

OK. If there is no way to show BASH_COMMAND as the actual commands run
in trap, then I want to know it is in trap so that I can just ignore
BASH_COMMAND. Is there a way to test whether it is in trap or not?
Thanks.

On 6/13/21, Koichi Murase <myoga.murase@gmail.com> wrote:
> 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
>


-- 
Regards,
Peng