Re: subshell, interactive, login, etc

[Donn Cave <donn@u.washington.edu>]

| Every rc sources .rcrc, but before doing this defines
| certain variable (say $mode) to have certain values
| depending on the mode. 
|
| Then you can do in .rcrc:
|
|   switch ($mode){
|     case login;  . $home/rc/login;
|     case inter;  . $home/rc/inter;
|     case inter_login; . $home/rc/inter; . $home/rc/login;
|   }

I think something like this is needed, recognizing that as we find more
alternatives to the console login, properly initializing a new shell process
becomes more complex.

I think I recall that the original inspiration for this was an stty(1)
needed for a new xterm-invoked rc; this process will inherit environment
variables, so you wouldn't want to set "path" and so forth as if it were
a login, but you wouldn't want to have every interactive rc process run
stty(1).

The easiest and most general way to handle this one might be to use the
ENV concept from ksh.  Window managers and the like could set
ENV = $home/newtty.rc, and that script would be responsible for clearing
ENV so that further rc's aren't plagued by it.  ENV would normally not
be set, so rc scripts wouldn't source anything at all, but it would probably
be good to insure that by having non-interactive shells ignore ENV.

I've complained in the past that rshd invokes one's shell without the
leading minus sign that would make it a login shell, so .rcrc (or .profile,
or whatever) doesn't get run.  This makes it hard to invoke something
that's not in a system standard execution path, via rsh.

There may be no good way to fix that problem, but the best of the bad ways
might be to have rc expect a certain environment variable, and run .rcrc
if it's not there.

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu