rcp failure due to echo

Larry Parmelee parmelee at wayback.cs.cornell.edu
Fri May 13 22:36:09 AEST 1988


In article <511 at edsews.EDS.COM> roberts at edsews.EDS.COM (Ted Roberts) writes:
> 				..... I was using rcp from an HP 319 (one of
> the 9000 series) and the command was failing miserably.  I should note that
> when I run my .cshrc I echo out a "This is the .cshrc executing message" 

Speaking from a 4.3 BSD background,
Your .cshrc shouldn't print anything.  (Another thing your .cshrc shouldn't
do is commands like stty, tset, mesg, biff..... but that's another subject).

Commands like rcp (rdist is another, programs using a remote mag-tape drive
are yet another) do their thing by using rsh to start a server running
on the remote system.  For example, early in the rcp code, it'll effectively
do an "rsh remotehost rcp -special_rcp_options" in order to create a server
copy of rcp running on the remote system as you.  The "special_rcp_options"
are what tell the remote rcp to run as a server for the rcp on the local
system.  This method simplifies things for rcp by allowing rsh to do the
hard work of user validation and generally establishing the network
connection.

But your .cshrc causes a problem for your local rcp, because the first 
thing the local rcp expects to see from the remote end is either a one
line message from rsh ("Permission denied.", for example, if user
validation fails) or an initial handshake message from the remote server
rcp.  When rsh on the remote end starts up a shell to run the given
command, the first thing the shell does is to run your .cshrc, which
produces a message which your local rcp recognizes as being not the
handshake it expected, so it assumes it must be a failure message from
rsh, so the local rcp prints the message and exits.  And that's all(!)
there is to it.

-Larry Parmelee
parmelee at cs.cornell.edu		parmelee at cornell.uucp



More information about the Comp.unix.wizards mailing list