Just added correction:
On Mon, Mar 3, 2014 at 8:47 PM, konsolebox <konsole...@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 <konsole...@gmail.com> wrote:
> On Wed, Feb 19, 2014 at 11:01 PM, Chet Ramey <chet.ra...@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.
>
>
