Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsh!wcs
From: wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
Newsgroups: comp.unix.shell
Subject: Re: trap 0 in /bin/sh
Keywords: Hemiptera in shells
Message-ID: <1991Apr1.022042.24560@cbnewsh.att.com>
Date: 1 Apr 91 02:20:42 GMT
References: <1991Mar27.153352.4421@robobar.co.uk> <893@mecky.UUCP>
Organization: AT&T Bell Labs Special Services Division
Lines: 24

In article <893@mecky.UUCP> walter@mecky.UUCP (Walter Mecky) writes:
] 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
] Looks like a bug in sh, ksh executes echo with both commands.
Actually, true is also a ksh builtin, but ksh DOES do the right thing with
	$ ( trap ' echo foo' 0 ; ls>/dev/null )
	foo
] I suppose, the subshell for the commands in ( ... ) looks to 
] the last command bevor ) and, if it's not a builtin, does only exec(2),
] instead of the usual fork(2)/exec(2). So sh cannot execute the trap commands.
	Sounds believable, and it's interesting to see another
	difference between sh and ksh.  Other than the efficiency gain
	by skipping the fork(), is there any useful program you
	could write in /bin/sh that would break by moving to ksh,
	which depends on the presence of this bug?  Or is it pure bug?
-- 
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
(Little Girl:) When I grow up, I want to be a nurse      } From this week's UFT
(Little Boy:)  When I grow up, I want to be an engineer  } radio commercial
.... guess the Political Correctness Police don't run NYC's teachers' union yet