Re: subshell, interactive, login, etc

[Matthew Farwell <dylan@ibmpcug.co.uk>]

In article <9206260141.AA07285@carson.u.washington.edu> you write:
>| 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.

; ls -l /bin/rc /bin/-rc
-rwxr-xr-x   3 bin      bin         63660 Feb 19 13:17 /bin/-rc*
-rwxr-xr-x   3 bin      bin         63660 Feb 19 13:17 /bin/rc*
; fn rc { mode=subshell -rc $* }

Then put something like

if (! $mode ~ subshell) {
	test -f $MAIL && echo You have mail.
} else {
	prompt=('subshell; ' '>')
}

in your .rcrc.  Well, that will work when you do it interactively
anyway.

Dylan.

-- 
It is no coincidence that in no known language does the phrase 'As
pretty as an Airport' appear -- Douglas Adams