On Sun, 7 Aug 2016 01:02:29 +0200 Julian Andres Klode wrote: > On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote: [...] > > I believe that trapping SIGINT and using this signal for something > > other than an immediate exit is a perfectly legitimate use of SIGINT. > > An already cited document [1] confirms this. > > > > [1] https://www.cons.org/cracauer/sigint.html > > Fixed in git (but see below), and already tagged pending by the git hook. Thanks for your reply! Do I read the git diff output [2] correctly? It seems to me that the modification implements the WUE approach (explained in [1]), rather than the WCE approach. I think that the WCE approach is really the way to go, since the hook could use SIGINT for something very different from an abnormal exit. Maybe, when the hook has finished its job, it exits successfully without killing itself with a SIGINT. In that case, APT should *not* abort the installation/upgrade! [2] https://anonscm.debian.org/cgit/apt/apt.git/diff/?id=b2cfacf In other words, I think that APT should wait for the child process to exit (already implemented), but it should also figure out whether the child process has exited on SIGINT or normally, in order to decide whether it should abort or continue with the installation/upgrade. > > > After pressing [Ctrl+C], the hook (simple-trap-sigint.sh) shows the > > expected "Press [Enter] to continue" message, but immediately goes > > on with its output, without waiting for input from the user. > > The final prompt is obtained after hitting [Enter]. But apt has > > already exited, instead of waiting for the hook to exit and checking > > whether the hook was killed by a SIGINT... > > Well, it obviously continues directly, because APT is feeding it > package names via a pipe. But once all package names are piped > thing should work as expected. Ah, you are right, thanks for explaining this aspect of the behavior I experienced during my tests! > > We could also stop writing package names when interrupted, but I'm > not sure if that makes a difference: Some might be buffered already. > It's also a lot more work. I don't think this is needed... What is needed is the WCE strategy, as explained above. Please implement it. Thanks for your time. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgpOG57wx5s90.pgp
Description: PGP signature