Subject: Re: NetBSD sh and ksh trap and signal handling incompatibilities with ATT ksh93 and Bash
To: None <tech-userlevel@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-userlevel
Date: 09/28/2007 21:32:55
In article <m1IbLqi-000kmyC@most.weird.com>,
Greg A. Woods <tech-userlevel@NetBSD.org> wrote:
>-=-=-=-=-=-
>
>The following example script uses commonly found idioms for handling
>signals and exit cleanup, but when run with NetBSD sh or ksh it fails to
>work in a way that is compatible with the real AT&T ksh93, or with GNU
>Bash:
>
> trap 'echo exit handler for $$: $? 1>&2' 0
> trap 'trap 1; echo pid $$: got HUP 1>&2; kill -1 $$' 1
> trap 'trap 2; echo pid $$: got INT 1>&2; kill -2 $$' 2
> trap 'trap 3; echo pid $$: got QUIT 1>&2; kill -3 $$' 3
> trap 'trap 13; echo pid $$: got PIPE 1>&2; kill -13 $$' 13
> trap 'trap 15; echo pid $$: got TERM 1>&2; kill -15 $$' 15
>
> cat
> rc=$?
>
> echo "normal exit: $rc"
> exit $rc
>
>The expected behaviour is that the exit handler (trap 0) will run after
>any other interrupt handler:
>
> $ ksh93 src/tsigtrap.sh
> aslkjf
> aslkjf
> ^?pid 13774: got INT
> exit handler for 13774: 258
>
> $ bash src/tsigtrap.sh
> asdf
> asdf
> ^?pid 13794: got INT
> exit handler for 13794: 0
>
>(bash doesn't set the exit code soon enough to see it in the handler)
>
>However /bin/sh and /bin/ksh only run the interrupt handler:
>
> $ /bin/sh src/tsigtrap.sh
> asdf
> asdf
> ^?pid 13775: got INT
>
> $ /bin/ksh src/tsigtrap.sh
> asdf
> asdf
> ^?pid 13778: got INT
>
>
>I'm not sure what POSIX says should happen, though I'm more concerned
>with ksh93 compatibility in this particular case anyway.
>
>Fixing this right now appears to be way more work than I have time for.
>
>Is this worth fixing? Should I send-pr so that someone interested and
>with time might eventually pick it up and work on it?
>
>
>It also seems that in ksh93 trap handlers in functions are transient
>whereas in /bin/ksh they get set and left there when the function is
>executed. This is probably even harder to fix given the current
>implementation.
If POSIX mandates this behavior, please send-pr.
christos