Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!garden-brau.csd.uwm.edu!wls
From: wls@garden-brau.csd.uwm.edu (Bill Stapleton)
Newsgroups: comp.unix.shell
Subject: Re: rsh guru req'd!
Keywords: rsh
Message-ID: <11322@uwm.edu>
Date: 23 Apr 91 15:50:30 GMT
References: <6226@iron6.UUCP> <1991Apr23.003518.4442@leland.Stanford.EDU>
Sender: news@uwm.edu
Reply-To: wls@garden-brau.csd.uwm.edu (Bill Stapleton)
Distribution: comp.unix.shell
Organization: Computing Services, U of Wisc-Milwaukee
Lines: 23

In article <1991Apr23.003518.4442@leland.Stanford.EDU>, dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
> In article <6226@iron6.UUCP> yeates@motcid.UUCP (Tony J Yeates) writes:
> >The rsh man page includes the following line:-
> >"The current local environment is not passed  to  the  remote shell."

> It isn't, and there is no real way to get around this. What I usually
> do when I want to pass something to a remote shell is to explicitly set the 
> environment variable in the command, something like (using /bin/sh as the 
> login shell):

> rsh silicon "VARIABLE=$VARIABLE; export VARIABLE; command-line"

What you might look into is having the ".cshrc" (or equivalent) on the remote
machine set the PATH (original request) and other variables needed by an
rsh-ed process.  For instance, my ".cshrc" checks for a variable, and if
it isn't there, assumes it's starting from scratch and sets the important
things like PATH, PRINTER, etc.  Note that the PATH may be different on the
remote machine, so setting it on the rsh line may not be what's desired.

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls