Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 exptools; site ihu1h.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ihu1h!takao
From: takao@ihu1h.UUCP (John Takao Collier)
Newsgroups: net.unix
Subject: Re: Can a trap survive the exec of a shell?
Message-ID: <672@ihu1h.UUCP>
Date: Fri, 20-Sep-85 15:23:50 EDT
Article-I.D.: ihu1h.672
Posted: Fri Sep 20 15:23:50 1985
Date-Received: Sat, 21-Sep-85 04:42:57 EDT
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 50

First of all, thanks to all the nice folks who sent responses to my
query.  Now, here are the results:

If you are execing /bin/sh, there appears to be no good way of
communicating the fact that a trap was set in the pre-exec shell.
It is the nature of the beast (refer to exec(2) and signal(2)),
i.e., the information is lost.

A number of respondents pointed out that if ksh(1) is exec'ed, then
the user could place the trap in the file specified by $ENV, which
is read by ksh(1) upon exec of ksh(1).  This works very well; in fact,
I currently use this little trick, but it is only valid for ksh(1) and
it is not valid for sh(1).  Why would I want to exec /bin/sh in the first
place, for crying out loud?  I'll get to that in a moment.

A few other respondents pointed out that the shell could be exec'ed
as "dash shell" (-sh).  The dash in front of "sh" tells
login(1) to read /etc/profile and $HOME/.profile.  This scheme
could be used to reset the trap, but it has the nasty habit of
reading /etc/profile twice (once for the original login, and once
for the exec) which can be very annoying, especially if your machine
contains time consuming /etc/profiles, or contains lengthy messages-
of-the-day (/ect/motd).

Now, the reason why I may want to exec /bin/sh:

Assume that my login shell is something other than /bin/sh, for example,
/usr/lbin/ksh.  This can be specified in /etc/passwd.  Now assume, that
for some reason, I must login using /bin/sh (the reason could be that a
bug was found in /usr/lbin/ksh).  My $HOME/.profile is set up such that
I can tell it at login time which shell I would like (see System V, login(1)).
I tell it that I want to use /bin/sh.  Unfortunately, since I exec
/bin/sh, any trap that I may have set has now gone bye-bye.

I guess the more appropriate question should be:

"How can I exec /bin/sh, have it read commands that have been previously
stored away in some fashion (for example, in a file), execute the commands,
and not terminate the shell upon detection of end-of-file (EOF)?"

Once again, this is easy with ksh(1) using the $ENV file.  It is not
obvious (and is probably impossible) with /bin/sh.

So, in a nut/shell (har de har har), there appears to be no good, clean
method of having a trap survive the exec of /bin/sh.
-- 

---
John Takao Collier   ..ihnp4!ihu1h!takao   1-312-979-3278
AT&T Bell Laboratories,  Naperville-Wheaton Road,  Naperville,  IL   60566


Brought to you by Super Global Mega Corp .com