Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Roger <rogerx.oss@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Protect Loop Execution with Traps
Date: Tue, 28 Jan 2020 16:25:51 -0500
Lines: 61
Approved: bug-bash@gnu.org
Message-ID: <mailman.265.1580246757.2185.bug-bash@gnu.org>
References: <20200128020322.GA31704@localhost4.local> <20200128134935.GM1350@eeg.ccf.org> <20200128204932.GB12574@localhost4.local> <20200128210721.GU1350@eeg.ccf.org> <20200128212551.GD12574@localhost4.local>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Greg Wooledge <wooledg@eeg.ccf.org>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <20200128210721.GU1350@eeg.ccf.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: list
Xref: csiph.com gnu.bash.bug:15831

>Here's a simple fix, that involves setting up ONE trap within the
>shell script, to override the shell's default SIGINT handling heuristic.
>
>
>#!/bin/bash
>trap exit INT
>while true; do
>  ping -c 3 8.8.8.8
>done
>
>
>There.  Now, when I hit Ctrl-C, the whole script exits, not just one
>instance of ping.
>
>(Switching from -c 1 to -c 3 made it a *lot* less spammy, and also much
>harder to kill using the "press Ctrl-C twice really fast" approach.
>The INT trap works around it beautifully for me, though.)
>
>Whether this same stuff applies to ffmpeg, I have no idea.  I also
>don't know why you're Ctrl-C'ing out of an ffmpeg loop often enough
>that this has become a concern.
>
>But, the "simple fix" that I used here has the same issue that ping
>itself has -- we're catching SIGINT and handling it and exiting,
>instead of letting SIGINT kill us.  If something runs *us* in a loop,
>it'll have the same problem that *we* had when we tried to run ping
>in a loop.

Yes. That's not desirable then, as sweet and short as it is.

>So, in the interest of not causing problems for other programs, here's
>the more correct fix:
>
>
>#!/bin/bash
>trap 'trap INT; kill -INT $$' INT
>while true; do
>  ping -c 3 8.8.8.8
>done

Wow, " trap 'trap INT; kill -INT $$' INT "  not easily readable for me.

A trap calling kill inside of a trap.

I'm thinking, put "trap INT; kill -INT $$" inside of it's own function, named 
something like exit_recurs_loop, so the first line reads "trap exit_recurs_loop 
INT"

I'll put these additional trap ideas into practice here whenever I'm doing 
loops and see what happens.

This trap stuff has me pulling out my hair, as I likely do not know the details 
of how programs use signals and how Bash interacts with such activity.

Thanks for your time!


--
Roger
http://rogerx.sdf.org/