Re: Protect Loop Execution with Traps

[Roger]

>If you run these, and try to kill them with Ctrl-C, you may find that
>the first one behaves perfectly (stops when you ask), and the second
>one does not.  It may take several tries to kill the second one.  You
>might have better luck suspending it with Ctrl-Z first, then killing
>the shell only, then fg'ing the job.
>
>See <https://www.cons.org/cracauer/sigint.html> for details.
>
>In a nutshell, ping(8) is a misbehaving program.  It sets a SIGINT
>trap (so that it can report statistics when you interrupt it), but
>it doesn't exit as a result of the signal.  The shell sees that the
>program didn't exit due to SIGINT, and decides that it (the shell)
>should not exit either.

As I slept on this, I realized the likeliness some programs are also trapping 
CTRL-C as you just explained.

The programs I'm using within a loop were ffmpeg && mv (rename) after verifying 
ffmpeg created a file >0 bytes.  As I speculated, I was likely doing too much 
within one loop and should likely isolate each task to it's own specific loop, 
mitigating such behaviour.  (The check should have also likely checked for a 
ffmpeg created file >= to the original file before renaming/moving.)

In other words, it's safer to

1) Have ffmpeg process all files within it's own loop, then

2) Perform a second loop renaming files using mv.

But as I re-think think this, should be good Bash scripting practice to 
integrate a trap within each loop? 


>Whatever program you're using inside your loop may have the same
>issues.  It's extremely common.

Another thought occurred to me last night, no wonder they call it Bash. When 
you execute a Bash loop, you'll likely be sure to find yourself pounding 
"CTRL-C" on your keyboard!

As far as the design/intigration of the trap within a loop, I'm guessing my 
initial post contained the most simplistic, readable, proper form of a trap for 
creating a safe quick exiting loop?


--
Roger
http://rogerx.sdf.org/

signature.asc
Description: Digital signature