Re: bin/54514: script(1) sometimes swallows last line(s) of output

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/54514; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/54514: script(1) sometimes swallows last line(s) of output
Date: Sat, 31 Aug 2019 08:58:18 +0700

 I don't believe that is the correct fix.   Your first change
 (moving the signal(SIGCHLD, finish) later) opens a possible
 (if unlikely) race if the child exits very quickly (before the
 signal is established) - which would result in the parent
 hanging until it reads EOF from stdin (which for your tests would
 be essentially forever - until manually killed).
 
 The correct way to handle this is to leave the initial signal() call
 catching SIGCHLD where it is currently, and insert
 	(void)signal(SIGCHLD, SIG_DFL);
 in the
 	if (child == 0) {
 case, before the subsequent (second) fork().   (An alternative would be
 to save the result of the initial signal call, and use that instead of
 SIG_DFL in the one to be added - but that should make no real difference.)
 
 Your second change is wrong (setting SIGCHLD to SIG_IGN is almost
 never the right thing to do), and in any case unnecessary, both
 because after your first change (or after the version of it I
 suggest above) when dooutput() is called the state of SIGCHLD will
 be SIG_DFL (which results in what I suspect you wanted to achieve
 by setting it to SIG_IGN) and also because dooutput() is called in the
 grandchild process, which never forks, so never has any children
 and so will never receive a SIGCHLD in any case.   This change can
 simply be deleted.
 
 Please try again with the changes as suggested, and let us know
 if my suggested variation for your patch fixes the problem.
 
 kre
 
 ps: this has most likely never been a problem, as script is almost
 always used interactively, and only exits when the user enters ^D
 to the terminal, which they typically don't do until all the output
 that is expected has been seen.   For the kind of usage in your test.
 the input is already known (it is in the test script) so isn't needed,
 to capture output simple shell redirection is enough.   I am not sure
 why anyone would ever normally run script as it is being run here.