help-bash
[Top][All Lists]
Advanced

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

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


From: Alex fxmbsw7 Ratchev
Subject: Re: How to print the actual command for BASH_COMMAND in trap?
Date: Sun, 13 Jun 2021 12:09:17 +0200

also maybe check the 'return' trap

On Sun, Jun 13, 2021, 12:08 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:

> you can, by setting myvar=$B*ASH_COMMAND in PS0*
>
> On Sun, Jun 13, 2021, 12:01 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
>>
>>


reply via email to

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