Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!math.fu-berlin.de!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.shell
Subject: Re: Bash, tar, and broken pipe
Message-ID: <1147@mwtech.UUCP>
Date: 23 May 91 22:28:37 GMT
References: <16345@helios.TAMU.EDU> <heinz.674916703@cc.univie.ac.at> <1991May22.192914.22142@usenet.ins.cwru.edu>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 27

In article <1991May22.192914.22142@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes:
>The process must exit due to the SIGPIPE, by the way -- no message will be
>printed if it catches the SIGPIPE and calls exit(), unless the fatal signal
>handler is coded like this:
>
>fatal(sig)
>int	sig;
>{
>	cleanup();
>	_exit(128+sig);
	^^^^^^^^^^^^^^  rather: kill(getpid(), sig); ????

>}

Hmm, I know that the shell encodes the information that some program
was terminated by a signal this way in $? - but the other way round
should also be true? On which system and for which shell?

I've just run a quick test, started a child sub-shell from the shell
prompt and terminated that with exit N (for several N close above 128).
I saw no message from the parent shell though the exit status was
transferred correctly according to $?.

(In case it should matter: It ran the test for the Bourne Shell on
ISC's UNIX/386 2.2.)
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83