Xref: utzoo comp.unix.shell:1763 comp.unix.sysv386:6431
Newsgroups: comp.unix.shell,comp.unix.sysv386
Path: utzoo!utgpu!watserv1!maytag!mks.com!mks!eric
From: eric@mks.mks.com (Eric Gisin)
Subject: Re: trap 0 in /bin/sh
Sender: eric@mks.com (Eric Gisin)
Summary: shell bug
References: <1991Mar27.153352.4421@robobar.co.uk>
In-Reply-To: ronald@robobar.co.uk's message of 27 Mar 91 15:33:52 GMT
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Date: 28 Mar 91 16:52:57
Message-ID: <ERIC.91Mar28165257@mks.mks.com>

In article <1991Mar27.153352.4421@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:

   Can someone explain why these two commands give different output ?
   Is there some subtlety about the "trap" command that I don't understand ?

	   $ ( trap 'echo foo' 0 ; true )
	   $ ( trap 'echo foo' 0 ; : )
	   foo

There is a bug in the shell.
When the last command in the list is executable (true is, : is not),
the shell tries to be clever and just does exec instead of fork/exec.
Since the shell exec()s instead of exit()s, the EXIT trap is not run.
You can work around it by putting an extra : at the end of the list:
	   $ ( trap 'echo foo' 0 ; true; : )
	   foo

   I tried this using /bin/sh on SCO Xenix, SCO Unix (orig release) and
   GEC UX/63 (SVR2, I think) and SunOS 4.1.  Yes, I know they're all System V
   /bin/sh, but I don't have a BSD handy to try.