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