Re: subshell, interactive, login, etc

Re: subshell, interactive, login, etc

[Matthew Farwell]

In article <9206261033.AA05577@dahlie.techfak.uni-bielefeld.de> you write:
>drazen@vlsi.cs.caltech.edu (D. Borkovic) writes:
>
>	Every rc sources .rcrc, but before doing this defines
>	certain variable (say $mode) to have certain values
>	depending on the mode. 
>
>If this is seriously considered to be incorporated, the recent rc version will
>be the last I use. There has never been an uglier, more resource waisting or
>more problem causing mechanism than that. I fought serious wars to convince
>csh users to switch to rc and now this !

Now that you come to mention it, I think it'd be the same for me too.

Dylan.

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

Re: subshell, interactive, login, etc

[malte]

drazen@vlsi.cs.caltech.edu (D. Borkovic) writes:

	Every rc sources .rcrc, but before doing this defines
	certain variable (say $mode) to have certain values
	depending on the mode. 

If this is seriously considered to be incorporated, the recent rc version will
be the last I use. There has never been an uglier, more resource waisting or
more problem causing mechanism than that. I fought serious wars to convince
csh users to switch to rc and now this !

NEVER!

Malte.

Re: subshell, interactive, login, etc

[Alan Watson]

I have a work-around for the problems with rsh; my `login shell' is
actually this rc script (called, unsurprisingly, rc-login):

#! /usr/users/alan/bin/rc
path = ( /usr/users/alan/bin $path )
exec rc -l $*

Re: subshell, interactive, login, etc

[Donn Cave]

| 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

Re: subshell, interactive, login, etc

[Scott Schwartz]

| 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.

I've been using this lately.  It seems like an adequate workaround.

#!/bin/rc -p
# usage: rrc [-n] host cmd
bg=(); quietly=(); sanely='>[3=] >[4=] >[5=] >[6=] >[7=]';
host=$1; shift
if (~ -n $host) {
    bg='&'
    quietly='>[0]/dev/null >[1=0] >[2=0]' 
    host=$1; shift
}
{ whatis PATH DISPLAY TERM TERMCAP TERMINFO >[2]/dev/null
  echo exec $sanely
  echo . .rcrc
  echo '{' $* '}' $quietly $bg 
  exit
} | rsh $host exec /bin/rc

Re: subshell, interactive, login, etc

[Matthew Farwell]

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

subshell, interactive, login, etc

[D. Borkovic]

What do people out there think about this:

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;
  }

Well, I did not think much about the values (inter_login looks
ugly), but I hope you get the idea.

Drazen

Re: subshell, interactive, login, etc

[Scott Schwartz]

| What do people out there think about this:
| 
| Every rc sources .rcrc, but before doing this defines
| certain variable (say $mode) to have certain values
| depending on the mode. 

How about this instead:  every rc evaluates a function, rc_init, if
defined, when it starts up.  (Before or after .rcrc, if a login shell?)
This would preserve a nice property of the current scheme, that you
don't need to read .rcrc just to start a shell.

My dream fix: user defined read-eval-print loops.  Scheme-shell anyone?

Re: subshell, interactive, login, etc

[Chris Siebenmann]

 The only problem not currently addressable in rc as it stands is
rsh, and I think rsh is its own problem and rc need not try to
solve that particular mess.

	- cks