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 15:49:32 -0500
Lines: 81
Approved: bug-bash@gnu.org
Message-ID: <mailman.262.1580244577.2185.bug-bash@gnu.org>
References: <20200128020322.GA31704@localhost4.local> <20200128134935.GM1350@eeg.ccf.org> <20200128204932.GB12574@localhost4.local>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
To: Greg Wooledge <wooledg@eeg.ccf.org>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <20200128134935.GM1350@eeg.ccf.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: list
Xref: csiph.com gnu.bash.bug:15828


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>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 trappi=
ng=20
CTRL-C as you just explained.

The programs I'm using within a loop were ffmpeg && mv (rename) after verif=
ying=20
ffmpeg created a file >0 bytes.  As I speculated, I was likely doing too mu=
ch=20
within one loop and should likely isolate each task to it's own specific lo=
op,=20
mitigating such behaviour.  (The check should have also likely checked for =
a=20
ffmpeg created file >=3D 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=20
integrate a trap within each loop?=20


>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. Whe=
n=20
you execute a Bash loop, you'll likely be sure to find yourself pounding=20
"CTRL-C" on your keyboard!

As far as the design/intigration of the trap within a loop, I'm guessing my=
=20
initial post contained the most simplistic, readable, proper form of a trap=
 for=20
creating a safe quick exiting loop?


--
Roger
http://rogerx.sdf.org/

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE9RWsHyMf/E7wvN52Bs6g7OKIfHUFAl4wnlYACgkQBs6g7OKI
fHXV8gf/duYVZ136EruYihnDYnxs2rErdx1IrKGcXVMjrYO0sDrafgHoQPcjeS9G
cBVZFJAn+b2ktXXPyuH4VnC08bNfyrzZTWQI9nl2thQ+X/tXq8aLCkWYy/u/OggE
QocBo4756LmqXqw1FxLeIqAxC3J7/SMQQXNilI0Gk47xIh0Uz/LrTpLK++YndP7T
JmuCTMfbS//31oO7F8qZfY22nRijyqENAOeTp3zreelM6LCPCvrcZbJ2mBm+kQ/A
VzZfzVccgX3xBRQ9ayt1Bmd8BEGIVRGUVoGp8CGnUYN24zUTPr5l6L4NgHXTAA9z
iKMdoxcngMlN+8dASoDgKQBKn2v/jw==
=Osk+
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--