On Sun, Aug 07, 2016 at 12:22:47AM +0200, Francesco Poli wrote: > Control: reassign -1 apt 1.3~pre2 > Control: affects -1 + apt-listbugs > > > > On Fri, 29 Jul 2016 19:41:28 +0200 Francesco Poli wrote: > > > Hence, I am suspecting that the misbehavior has something to do with > > the way the package manager invokes its hooks... > [...] > > > > I am Cc-ing the APT Development Team: could any of you take a look at > > bug #832593, please? > > Any ideas on why a hook that traps SIGINT runs into troubles, when it > > catches such signal, but does not immediately exit? > > Hello again, APT Development Team. > > I prepared an overly simple script that traps SIGINT, asks the user to > press [Enter] and then goes on with its own business > (simple-trap-sigint.sh, that should be found attached to this message). > > 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.
Fixed in git (but see below), and already tagged pending by the git hook. > 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. 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. -- Debian Developer - deb.li/jak | jak-linux.org - free software dev When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.
