[comp.unix.shell] rsh guru req'd!

yeates@motcid.UUCP (Tony J Yeates) (04/19/91)

The rsh man page includes the following line:-
"The current local environment is not passed  to  the  remote shell."

Does anybody know a good way to get around this (ie export
your current environment to rsh).  This seems to be a
severe restriction.

[The problem I have is that when I rsh scripts (which I do not own)
they fail, because some of the commands that they use cannot
be found (doing "rsh silicon echo '$PATH'" reveals my path is
severely truncated...":/usr/ucb:/bin:/usr/bin").]

[Please email replies if pos.]

dkeisen@leland.Stanford.EDU (Dave Eisen) (04/23/91)

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"




-- 
Dave Eisen                           dkeisen@leland.Stanford.EDU
1101 San Antonio Raod, Suite 102     (Gang-of-Four is being taken off the net)
Mountain View, CA 94043
(415) 967-5644

wls@garden-brau.csd.uwm.edu (Bill Stapleton) (04/23/91)

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

brister@decwrl.dec.com (James Brister) (04/25/91)

On 23 Apr 91 15:50:30 GMT, wls@garden-brau.csd.uwm.edu (Bill Stapleton) said:

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

I gave up using .login about a year ago, and now have .cshrc do everything.
Judicious use of if..then's helps. Haven't looked back since.

James
--
James Brister                                           brister@decwrl.dec.com
DEC WSL., Palo Alto, CA                 {uunet,pacbell,pyramid}!decwrl!brister
"Old mathematicians never die; they just lose some of their functions."

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/25/91)

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."
| 
| Does anybody know a good way to get around this (ie export
| your current environment to rsh).  This seems to be a
| severe restriction.
| 
| [The problem I have is that when I rsh scripts (which I do not own)
| they fail, because some of the commands that they use cannot
| be found (doing "rsh silicon echo '$PATH'" reveals my path is
| severely truncated...":/usr/ucb:/bin:/usr/bin").]

  I guess this is of general interest... first you save the environment
via:
    set > my.env
on some really old copies of shell you must
    (set) 2>my.env

Then put the command(s) on the end of the environment and send to the
rsh:

    echo "pwd;ping pong;who" | cat my.env - | rsh elsewhere /bin/sh

Of course about the 2nd time you do it:
    ersh()
    {
      echo "$2" | cat my.env - | rsh $1 /bin/sh
    }

then you can say:
    ersh othermach.far.away "who;ping pong"
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (04/25/91)

In article <1991Apr23.003518.4442@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:

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

  Not needed. When a variable is defined on a command line *not*
separated by a colon it is exported to that command only. If you were
were doing more than one command you would do it as you have shown, and
forgive me if you simplified and knew this, but for the case you show,
the simplified form:

    rsh silicon "VARIABLE=$VARIABLE command-line"

works just fine. I avoid typing at every chance because I do it so
rapidly but inaccurately.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

michaelp@amadeus.WR.TEK.COM (Michael Prusynski) (04/30/91)

In article <6226@iron6.UUCP> yeates@motcid.UUCP (Tony J Yeates) writes:
>[The problem I have is that when I rsh scripts (which I do not own)
>they fail, because some of the commands that they use cannot
>be found (doing "rsh silicon echo '$PATH'" reveals my path is
>severely truncated...":/usr/ucb:/bin:/usr/bin").]

I've made an executable shell script in my HOME directory on the remote 
machine(s) called:  do
which contains:

PATH=/u/michaelp/bin:/usr/local:/usr/ens/bin:/usr/tek:/usr/ucb:/bin:/usr/bin
exec $@

Then you can type:
rsh silicon do echo '$PATH'

to check the PATH, or something more useful like:
rsh silicon do some-command-in-a-non-standard-path


It works for me!
-----
Michael Prusynski (michaelp@amadeus.WR.TEK.COM)   Phone: (503) 629-3062
USMail:  Tektronix Inc., MS 92-304, PO Box 4600, Beaverton, OR 97076    __o
  UUCP:  ...!uunet!tektronix!amadeus.WR.TEK.COM!michaelp               -\<,
  ARPA:  @RELAY.CS.NET:michaelp@amadeus.WR.TEK.COM                ....O/ O

Dan_Jacobson@ATT.COM (05/01/91)

>>>>> On 29 Apr 91 21:46:48 GMT, michaelp@amadeus.WR.TEK.COM (Michael Prusynski) said:

Michael> I've made an executable shell script in my HOME directory on
Michael> the remote machine(s) called: do

Careful, "do" is a special word in many shells.
$ bla
bla: not found
$ do
syntax error: `do' unexpected

(do is special, bla is not, to this /bin/sh)