On Fri, May 10, 2024 at 12:46 PM Jeff King <peff@xxxxxxxx> wrote:
>
> On Fri, May 10, 2024 at 12:34:07PM -0700, Emily Shaffer wrote:
>
> > Yes, it is because test_must_fail expects "natural" death. You can
> > tell test_must_fail which signal you'd expect to receive, in theory,
> > but I didn't get it to work (and it will be tricky to provide the
> > correct signal in shell - I had originally hardcoded signal ints in
> > sh, but then moved the signal enum->int resolution into
> > helper/test-trace2.c because the alternative is doing some nasty
> > grepping on other shell utility outputs, since the signal codes aren't
> > platform/arch consistent).
>
> We have test_match_signal(). Unfortunately it's not integrated with
> test_expect_code(), so you have to do:
>
> { thing_which_fails; OUT=$?; } &&
> test_match_signal 15 "$OUT"
Right, what I meant above is that `15` isn't portable, I'd have to get
the correct int value of SIGINT/SIGSEGV from some other shell utility
at test time.
>
> See 5263e22cba (t7006: simplify exit-code checks for sigpipe tests,
> 2021-11-21) for an example.
>
> > I also wonder - do we want to capture SIGKILL as well? Some people may
> > have muscle memory for `kill -9` (I do, for better or worse) instead
> > of gentler `kill`. My intent was to notice any indication of user
> > frustration resulting in manual termination, which would include `kill
> > -9` too...
>
> You can't catch SIGKILL; its whole purpose is to be un-catchable.
Duh :') Thanks.
>
> -Peff
