On Fri, Aug 19, 2016 at 02:14:22PM +0200, Julian Andres Klode wrote: > On Sat, Aug 13, 2016 at 12:00:06AM +0200, Francesco Poli wrote: > > On Fri, 12 Aug 2016 00:45:55 +0200 Julian Andres Klode wrote: > > > > > On Fri, Aug 12, 2016 at 12:40:44AM +0200, Francesco Poli wrote: > > [...] > > > > Please reply to my question > > [...] > > > > > > > > In the meanwhile, I am reopening the bug. > > > > > > Yes, sorry, I forgot to take this out of the changelog. > > > > No problem, reopening the bug was easy enough... > > > > > So, basically, > > > AFAICT, what we should do is ignore the interrupt, because if the child > > > process exits with any error, we will error out as well. And if a child > > > exits because of a SIGINT, it's exit code won't be 0. > > > > Well, this sounds reasonable, after all. > > I haven't been able to find a counterargument, although you have to > > take into account that I am no expert of signal handling, so I could be > > wrong... > > > > Please implement the fix soon. > > Thanks for your time and helpfulness! > > I basically fixed this locally in theory, but in practice > this does not seem fixable. We invoke our commands with a shell, > as you might be aware. The signal handling of shells is not portable: > > This means that regardless what apt-listbugs exits with, the dash > shell it was invoked by will always exit with the SIGINT signal.
I now added a build-time option APT_SHELL; defaulting to /bin/bash, and a APT config option Dir::Bin::sh, defaulting to the value of APT_SHELL, that is used instead of /bin/sh. So things should work now: https://github.com/Debian/apt/compare/master...julian-klode:bugfix/sigint?expand=1 -- 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.
