Date: Mon, 15 Apr 2019 15:05:50 +0200
From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
Message-ID: <5cb481ae.vxg6yxdgkfin1rkv%joerg.schill...@fokus.fraunhofer.de>
| Wow, this is a long text and I would need more time.
Yes, it was...
| Let me give some comments:
I'd prefer comments on the issues that matter to posix.
Various bugs one place or another are just things to get
fixed ... bugs that are discovered in off the wall type
testing for esoteric issues like this aren't even urgent ones.
| Thank you for the hint. I would need to investigate in the reason for that
| behavior and fix it.
It will be a process group (for the terminal) alteration that's
getting missed or performed incorrectly. Or at least that is what
it looks like (from the outside.)
| "SIGFAIL" is what the shell uses to exit when it is killed itself
| by a signal.
Oh. What we do when we catch a signal, and then exit, is reset the
signal to SIG_DFL (and disable core dumps, but that's not important)
and then send the signal to ourselves (again). Then our parent gets
a "killed by signal X" status, instead of "exited".
| But if you did have a POSIX compliant OS, you should be able to detect that
| exit code > 127 if you use waitid().
Yes, I could, but as long as posix keeps saying the the shell exit
code is 0..255 (that is, $?) there doesn't seem to be much point.
| This is indeed something that has been left over from 1977 when SIGSEGV was
| used to extend the heap of the shell.
Personally, I think that's fine (not extending the heap that way, but
catching any signal a shell desired) - this is another example of a shell
resetting an ignored signal to default (or internally trapped, which
means the same to a script) because it needs the signal for internal
uses. And then "ignored at startup" is interpreted where "startup"
means "after initialisation".
kre
