process011 is broken on Debian 10

[bgamari]

It appears that the refactor of process011 performed in 8cd7e043b8b55cca398ce4c3c3880aff3af62975, where process011 is taught to use python3 instead of sh, has broken the test on Debian 10. Specifically, for reasons that I don't yet understand python3 exits with code 1 not code 2 when killing itself with signal 2:

$ (python3 -c 'import os; os.kill(os.getpid(), 2)' || echo $?)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
1

[bgamari]

Cc @blackgnezdo

[bgamari]

To confirm, a trivial C program behaves as expected:

#include <unistd.h>
#include <signal.h>

int main() {
        kill(getpid(), SIGINT);
        sleep(1);
        return 0;
}

Namely,

$ (gcc hi.c; ./a.out; echo $?)
130

[mpickering]

Can we guard this behavior behind CPP or revert the patch? Being broken on debian 10 seems worse than being broken on OpenBSD. (Of course working on both would be beneficial but we are not blocked on OpenBSD issues).

[bgamari]

My sense is that the right approach here is to use neither Python nor sh. Rather, we can just use the C program I gave above.

[blackgnezdo]

I'll take a look but do feel free to revert my change if you want to make a quick release.

[blackgnezdo]

Yes, @bgamari a C program would've been my preferred fix except I didn't understand how to to fit this into the test harness.

[bgamari]

@blackgnezdo no worries. I have put up a plausible fix as #242.