paul@athertn.Atherton.COM (Paul Sander) (02/18/89)
How can a running program tell what shell spawned it?
Here is my problem. I have a Curses-based application that must work
properly when its input, output, or both are redirected. This program
must not coredump, even if the user does strange things like invoke it
interactively in the background. But the Curses implementation I am
using likes to coredump under certain situations like this when running
under csh.
My workaround is to not permit the application to run at all when invoked
in the background under csh when either stdin or stdout is not redirected.
To determine which shell is running at the time, I am using a horrible
kludge: Check the line discipline the tty driver is using; if its the new
discipline then assume csh, otherwise assume sh. To determine background-
ness, I compare the tty's process group with my process id, and assume
background if they're different.
My system is a Sun 3, running SunOS 4.2 Release 3.2. Has anyone else had
the problems I'm having, and is there a better way to determine which shell
is running? And is there a better way to determine whether or not I'm
running in the background?
Many thanks in advance.
--
Paul Sander (408) 734-9822 | Do YOU get nervous when a
paul@Atherton.COM | sys{op,adm,prg,engr} says
{decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?guy@auspex.UUCP (Guy Harris) (02/19/89)
>How can a running program tell what shell spawned it? With great difficulty, at best. >Here is my problem. I have a Curses-based application that must work >properly when its input, output, or both are redirected. This program >must not coredump, even if the user does strange things like invoke it >interactively in the background. But the Curses implementation I am >using likes to coredump under certain situations like this when running >under csh. Well, step 1 is to report that as a bug; if a library supplied with your system dumps core in situations like that, it's not a feature, it's a bug. >My workaround is to not permit the application to run at all when invoked >in the background under csh when either stdin or stdout is not redirected. >To determine which shell is running at the time, I am using a horrible >kludge: Check the line discipline the tty driver is using; if its the new >discipline then assume csh, otherwise assume sh. Sorry, wrong answer. That won't work in SunOS 4.0, for example; there *is* no (moral equivalent of) the "old" line discipline in 4.0. The same will probably be true of POSIX-style tty drivers, such as the one Berkeley's working on. It also won't 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). However, I'm not sure whether your problems are caused by anything specific to "csh"; they may be caused by job-control shells in general. >To determine background-ness, I compare the tty's process group with >my process id, and assume background if they're different. This determines "job control shell"-style background-ness; if you're not running under a job control shell, this test will probably not say that you're in the background, even if you are. As such, it may just be sufficient to have your application test whether it's in the background; if it is, it's running under "csh" or some other job control shell, and if it isn't, it's either running in the foreground or running in the background under a non-job-control shell (such as "sh"). The test may differ on systems with POSIX job control.
scs@adam.pika.mit.edu (Steve Summit) (02/23/89)
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