Path: utzoo!attcan!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: trap causes longjmp botch (Was: Command line argument in Cshell script
Keywords: command line argument, Cshell, trap, longjmp
Message-ID: <502@philmds.UUCP>
Date: 12 Jun 88 10:26:51 GMT
References: <497@slb-sdr.UUCP> <534@unh.UUCP> <11820@mimsy.UUCP>
Reply-To: leo@philmds.UUCP (L.J.M. de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 30
Xref: utzoo comp.unix.questions:7534 comp.unix.wizards:9262

In article <11820@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
 [stuff deleted]
>Here is how I might write it:
>
>	case $# in
>	0)	echo "usage: $0 file [arguments to plot3d]" 1>&2; exit 1;;
>	esac
>
>	TEMP=/tmp/z$$			# make a unique temporary file name
>	/bin/rm -f $TEMP		# remove it if it exists
>	trap '/bin/rm -f $TEMP; exit' 0 1 2 3 15 # and again at exit or signal

    Used to write it myself that way too ... until one day the sh (/bin/sh;
the Bourne shell on an Ultrix machine) complained about a 'longjmp botch'; 
I don't remember if there was a core dump.
    What is the problem with this trap? The normal signals, as 1 2 3 and 15 are
handled with interrupt routines in the shell, using signal() or sigvec() or
whatever. The 0 signal isn't really a signal, just used by the shell to
perform certain actions at closing time (putting chairs on tables, removing
any drunks left 8-). It could well have been implemented using setjmp and
longjmp (I dunno, don't have the source); that could explain the 'longjmp
botch'. The last command in the trap is 'exit'. But when the shell exits,
it has to perform the trap! So another reason for the 'longjmp botch' message
could be the shell trying to recursively trap and exit, each calling the
other and finally finding out it's running out of stack space.
    Perhaps it is safer to add another trap:
    trap '/bin/rm -f $TEMP; trap 0; exit' 0 1 2 3 15
In this case the 'exit'-trap is reset when the trap is executed.

    Leo.