bug-bash
[Top][All Lists]
Advanced

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

Re: Bash 4.3 no longer handles traps when reading input with read


From: konsolebox
Subject: Re: Bash 4.3 no longer handles traps when reading input with read
Date: Mon, 3 Mar 2014 21:00:26 +0800

Just added correction:

On Mon, Mar 3, 2014 at 8:47 PM, konsolebox <konsolebox@gmail.com> wrote:

> echo "Interacting."
>
> until read -t 1; do
>     continue
> done
>

I actually modified that part as well. Results are similar even if not in a
loop:

echo "Interacting."
>
> read
>

Cheers, konsolebox



On Mon, Mar 3, 2014 at 8:47 PM, konsolebox <konsolebox@gmail.com> wrote:

> On Wed, Feb 19, 2014 at 11:01 PM, Chet Ramey <chet.ramey@case.edu> wrote:
>
>> On 2/19/14 1:51 AM, konsolebox wrote:
>>
>> >     Bash-4.3 handles signals and traps when a read run by the read
>> builtin is
>> >     interrupted by a  signal.  I'm not  sure that's the best thing to
>> do,
>> >     since traps should really be run when commands finish, but we're
>> going to
>> >     try it.
>> >
>> >     Since bash-4.2, bash has installed its SIGCHLD signal handler with
>> >     SA_RESTART, so a child death does not unexpectedly interrupt system
>> calls.
>> >     There were several bug reports concerning this.  So yes, SIGCHLD is
>> >     special.
>> >
>> >
>> > I'm not really able to comprehend the significance of SA_RESTART to
>> SIGCHLD
>> > that it could affect the signal and make it behave differently from the
>> > other signals i.e. it can't be a good idea to allow interruption from it
>> > when in a read builtin context, but could it be possible that we allow
>> it
>> > when not in posix mode? Probably it's about the variable
>> posixly_correct.
>> > If we can allow at least just one interruption to happen maybe with the
>> > help of the variable running_trap it would really be good enough.
>>
>> SIGCHLD is different from other signals in that it can arrive at any time
>> without user intervention. Say you run a background process that exits
>> during a call to the read builtin.  Should it interrupt the read?  What
>> would be gained by having system calls return errors because bash reaps a
>> child?  Should it interrupt the read only if there is a trap set?
>>
>> There's a way to do what you want, but the question is whether or not the
>> demand is sufficient to make SIGCHLD traps run when other traps would not.
>>
>
> I tried to use my script again with the new release of bash (4.3). Almost
> every signal was allowed besides SIGCHLD (17). SIGALRM (19) seems
> reasonable not to be included since it's used by read. SIGKILL (9) and
> SIGCONT (19) which I excluded from it I doubt are reasonable to be caught.
>
> #!/bin/bash
>
> catcher() {
>     echo "Interruption allowed."
>
> }
>
> for (( I = 1; I <= 31; ++I )); do
>     [[ I -ne 9 && I -ne 19 ]] && trap catcher "$I"
>
> done
>
> (
>     for (( I = 1; I <= 31; ++I )); do
>         [[ I -ne 9 && I -ne 19 ]] || continue
>         sleep 1s
>         echo "Sending $I."
>         kill -s "$I" "$$"
>     done
> ) &
>
> echo "Interacting."
>
> until read -t 1; do
>     continue
> done
>
> --------------------
>
> # bash-4.3 temp.sh &>log.txt
> Interacting.
> Sending 1.
> Interruption allowed.
> Sending 2.
> Interruption allowed.
> Sending 3.
> Interruption allowed.
> Sending 4.
> Interruption allowed.
> Sending 5.
> Interruption allowed.
> Sending 6.
> Interruption allowed.
> Sending 7.
> Interruption allowed.
> Sending 8.
> Interruption allowed.
> Sending 10.
> Interruption allowed.
> Sending 11.
> Interruption allowed.
> Sending 12.
> Interruption allowed.
> Sending 13.
> Interruption allowed.
> Sending 14.
> Sending 15.
> Interruption allowed.
> Sending 16.
> Interruption allowed.
> Sending 17.
> Sending 18.
> Interruption allowed.
> Sending 20.
> Interruption allowed.
> Sending 21.
> Interruption allowed.
> Sending 22.
> Interruption allowed.
> Sending 23.
> Interruption allowed.
> Sending 24.
> Interruption allowed.
> Sending 25.
> Interruption allowed.
> Sending 26.
> Interruption allowed.
> Sending 27.
> Interruption allowed.
> Sending 28.
> Interruption allowed.
> Sending 29.
> Interruption allowed.
> Sending 30.
> Interruption allowed.
> Sending 31.
> Interruption allowed.
>
> --------------------
>
> I'm not sure about demand for the use of the signal. Some might find
> making use of it really useful I hope but certainly it would have been
> useful for my part. I have had this free project which started in 2004
> which I use most of the time to play audio files. Since bash would no
> longer entertain handling traps when a SIGCHLD signal is caught in a
> context of a read session playing another file after the player ends would
> wait until the read timeout is reached. Using a loop would still give a 1
> second gap between plays and would consume much CPU time and even much more
> if I shorten the interval. Once I had tried to patch it and I found my
> laptop heating up more quickly because of it. This becomes the very reason
> why I no longer find continuing the project to be practical. I actually
> already lost the urge to continue developing it the time I knew about out
> the changes in 4.3.
>
> Just in case the project I refer to is named PlayShell [
> http://sourceforge.net/projects/playshell/]. Its last form has been
> working really well already in bash 4.2, besides the crashing which I
> thought would be fixed and not changed in 4.3. Despite the crashing it
> already has a way to uninterruptingly restart itself when it happens.
>
>


reply via email to

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