>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
