Can a trap survive the exec of a shell?
John Takao Collier
takao at ihu1h.UUCP
Sat Sep 21 05:23:50 AEST 1985
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
More information about the Comp.unix
mailing list