Re: "wait" loses signals
On 2/21/20 4:07 PM, Chet Ramey wrote:
On 2/21/20 9:44 AM, Denys Vlasenko wrote:
Yes, and here we are "after command", specifically after "{...} &" command.
Since we got a trapped signal, we must run its trap.
Did you look at the scenario in my message?
What scenario?
The scenario in the message you replied to.
As I said, there are just two possibilities:
signal is received before the point when shell checks for received
signals after "{...} &" command;
or signal is received after that point, and thus signal is
considered to be received "inside wait builtin".
That's just not reasonable.
Yes it is.
You're saying signals that are received before
the wait builtin begins executing (say, while the command is being parsed,
or the shell is doing some other bookkeeping task) should be considered
to have arrived while the wait builtin is executing.
OF COURSE! How else do you think this can possibly be seen?
I'm pretty sure that's
not consistent with the letter or the spirit of the standard.
IOW, you think that between "command 1 finished executing"
and "command 2 starts executing" there can be sort of signal black hole
time period, where signals can be simply ignored.
Now *this* is just not reasonable, since this would make traps
unreliable.
Re: "wait" loses signals
On 2/21/20 9:44 AM, Denys Vlasenko wrote:
>>> Yes, and here we are "after command", specifically after "{...} &" command.
>>> Since we got a trapped signal, we must run its trap.
>>
>> Did you look at the scenario in my message?
>
> What scenario?
The scenario in the message you replied to.
> As I said, there are just two possibilities:
> signal is received before the point when shell checks for received
> signals after "{...} &" command;
> or signal is received after that point, and thus signal is
> considered to be received "inside wait builtin".
That's just not reasonable. You're saying signals that are received before
the wait builtin begins executing (say, while the command is being parsed,
or the shell is doing some other bookkeeping task) should be considered
to have arrived while the wait builtin is executing. I'm pretty sure that's
not consistent with the letter or the spirit of the standard.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: "wait" loses signals
On 2/20/20 4:27 PM, Chet Ramey wrote:
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is delivered before "wait",
then TERM trap will kill the child, and exit.
This strikes me as a shaky assumption, dependent on when the shell receives
the SIGTERM and when it runs traps.
The undisputable fact is that after shell forks a child
to run the "{...} &" subshell, it will receive the SIGTERM signal.
And since it has a trap for it, it should be run.
(There's nothing in POSIX that says
when pending traps are processed. Bash runs them after commands.)
Yes, and here we are "after command", specifically after "{...} &" command.
Since we got a trapped signal, we must run its trap.
Did you look at the scenario in my message?
What scenario?
As I said, there are just two possibilities:
signal is received before the point when shell checks for received
signals after "{...} &" command;
or signal is received after that point, and thus signal is
considered to be received "inside wait builtin".
In both cases, trap should be run.
Keep in mind that you can't run the trap out of the signal handler.
Yes, running anything remotely complex out of signal handlers is
a bad idea: signals can arrive somewhere in the middle of stdio, or memory
allocation,
or something similarly critical. Reentering one of those can deadlock.
Properly-written programs are careful to record
signal reception in a flag variable, or a pipe, etc,
then return from signal handler, and act on it later, not in a signal handler.
Re: ${!variable@operator} does not work for variables without values; inconsistencies between present and absent [@] for @A and @a
On 2/20/20 6:54 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Chet Ramey 2020-02-20 21:22 UTC:
>> On 2/19/20 7:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> But I am not interested in any ${!varname[@]}, but instead in applying
>>> @operator transformations.
>>
>> OK, let's see how these work.
>>
>> Given the following
>>
>> VAR2=(aaa bbb)
>> varname=VAR2
>>
>> What does
>>
>> echo ${!varname[@]@Q}
>>
>> output?
>>
>> You first have to expand `varname[@]' as an indirect reference. Since
>> varname is a scalar variable, varname[@] expands to the same thing as
>> varname, which is VAR2. Now you expand VAR2, which, since VAR2 is an
>> array variable, is the same as VAR2[0]. That gives you "aaa", so the
>> output is 'aaa'.
>
> Your explanation is convincing for varname=VAR2 but now I would expect
> different results for varname=VAR2[@].
>
> Current actual results:
> $ VAR2=(aaa bbb)
> $ varname="VAR2[@]"
> $ echo "${VAR2@Q}"
> 'aaa'
> $ echo "${VAR2[@]@Q}"
> 'aaa' 'bbb'
> $ echo "${!varname@Q}"
>
> $ echo "${!varname[@]@Q}"
>
> $
>
> Expected results for last 2 commands:
>
> $ echo "${!varname@Q}"
> 'aaa' 'bbb'
This is correct output, and there's a bug here.
> $ echo "${!varname[@]@Q}"
> bash: ${VAR2[@][@]@Q}: bad substitution# This is example from
> direct usage of [@][@]
This is not; it should echo the same as the previous case, for the same
reason as I stated above (expand varname[@]; it expands to the same thing
as varname since varname is not an array variable; use the expansion to
VAR2[@]).
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ${!variable@operator} does not work for variables without values; inconsistencies between present and absent [@] for @A and @a
On 2/20/20 6:23 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Even more strangely, quoting apparently matters...
Yes, this is a bug:
> $ echo "${VAR1[@]@A}"
> declare -rl VAR1=''
>> The question is whether the unset variables should display commands to
>> set the attributes (@A) or display any attributes (@a).
>
> I think that it would be expected that @A prints the same as 'declare
> -p' for given variable.
That's not unreasonable, but it takes some consideration. You have to be
careful separating out these cases from the usual case, where a variable
name in a brace expansion is expanded to nothing if it's unset.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: test -v for array does not work as documented
On 21/02/2020 02.37, Chet Ramey wrote: > It's unset because it doesn't have a value, but it retains the `local' > attribute so it stays local if subsequently assigned one. Is there any reason the local attribute cannot be unset? If it would be possible then the "declare/typeset -p" would return 1 when the variable doesn't exist. By the way, it seems that `local -p var` doesn't work like 'declare -p var` even though `help local` suggests it should. Peter
