takao@ihu1h.UUCP (John Takao Collier) (09/20/85)
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