Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: What shell is running?
Keywords: sh csh differences w.r.t. programs
Message-ID: <9401@bloom-beacon.MIT.EDU>
Date: 23 Feb 89 03:28:04 GMT
References: <299@athertn.Atherton.COM> <1049@auspex.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 27

In article <299@athertn.Atherton.COM> paul@athertn.Atherton.COM
(Paul Sander) asks how to determine which shell has invoked an
interactive application, to prevent certain core dumps under
various combinations of input redirection, background invocation,
etc.  He considers making this decision based on the line
discipline in use, but Guy Harris reminds him that this won't
necessarily work

	...on systems with job-control shells other than "csh",
	such as the Korn shell or the BRL Bourne shell (or the S5R4 Bourne
	shell).

Consider, too, that there are twisted reactionaries like me who
use the new line discipline but stick with the Bourne shell.

The first thing to look at is stdin: background processes invoked
by sh have stdin connected to /dev/null, while under csh stdin
remains connected to the terminal, but in a different process
group so that attempted reads result in SIGTTIN.  If the process
group related signals under the new driver don't get you,
attempted ioctl's on a /dev/null stdin under sh probably will.

"Simple" programs don't have these problems, but those that deal
specially with the terminal driver have to be careful.

                                            Steve Summit
                                            scs@adam.pika.mit.edu