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: $ cat trap.sh trap 'echo int' INT; sleep 10; exit 0 $ if dash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint FAIL: 130 $ if mksh -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint OK: 0 $ if bash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint OK: 0 dash, which is our default shell, always exits with the interrrupt signal. This means that regardless what apt-listbugs exits with, the dash shell it was invoked by will always exit with the SIGINT signal. -- 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.
