roberts@edsews.EDS.COM (Ted Roberts) (05/13/88)
Recently I came across a curious problem and though we determined the cause, I still don't know WHY it happened. 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" (probably lights are already going on over somebody's head out there 8-). Anyway, when I did an rcp, all I got was the first echo line of my .cshrc sent to stdout (even if I had two echo lines in the file, I only got one as output). There was no error message and no file copied. When the echoes were removed from the file, everything worked fine. Since I don't know quite how the rcp command is written, I'm still unsure as to what actually caused my downfall. Anybody have any ideas? Please email since I don't read this category very often. -- Ted Roberts | My opinions are not necessarily those EDS Technical Services Division | of my employer. Does that mean I'm UUCP: roberts@edsews.EDS.COM | wrong?
parmelee@wayback.cs.cornell.edu (Larry Parmelee) (05/13/88)
In article <511@edsews.EDS.COM> roberts@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@cs.cornell.edu parmelee@cornell.uucp
daniel@unicom.UUCP (Dan Smith, not your average Lithuanian...) (05/16/88)
In article <17181@cornell.UUCP> parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes: >In article <511@edsews.EDS.COM> roberts@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). > Almost. If your .cshrc has these few lines up at the top *before* you have lines that echo anything, you should be alright. I ran into this problem on Suns, and this fixed it. It just asks the question: "hey! is this an interactive shell?" if (! $?prompt) then exit (0) endif * another subject, related to rcp * I have a problem with rcp/NFS. It involves 3 Suns: island, jamaica, and ceylon. island and ceylon are servers, and jamaica is my 3/50 mounted on ceylon. I tried copying a 5 meg tar file island->jamaica, and the file got corrupted. (ceylon was pretty loaded at the time)...so, I rlogin'ed to ceylon and rcp'ed the same file island->ceylon (and ceylon was just as loaded, if not more so), and everything was fine. My theory is that a message saying "NFS server ceylon not responding" issued from jamaica during the first copy in some way interfered with rcp. Any comments? Oh yes... island is running 1.2 (!), and jamaica and ceylon are running 3.5. dan dan smith, island graphics, marin co, ca, good natured infonaut, hoopy frood 4000 civic center dr., san rafael 94903 | dis: they're My thoughts, Buckwheat! uucp: {ucbvax!ucbcad,sun}!island!daniel | ph: +1 (415) 491 1000 (W), 332 FAST, uucp: {pacbell,pixar}!unicom!daniel | 332 EASY (H)| unix/films/rock/feasts
dwm@ihlpf.ATT.COM (Meeks) (05/20/88)
> 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" > (probably lights are already going on over somebody's head out there 8-). > Anyway, when I did an rcp, all I got was the first echo line of my .cshrc > sent to stdout (even if I had two echo lines in the file, I only got one > as output). There was no error message and no file copied. When the echoes ----------------- RemoteCoPy sorta ( technical term, sorry ) logs you into the remote machine. Remember that .xxxrc files are executed with each new shell. Thus, your rcp is executing your remote .xxxrc before it makes any copies. Because of the way rcp works, echos and stty stuff ( another technical term ) should not be included in your .xxxrc. I have found this generally true of most implementations. I have created a .xxxrc which uses a case statement to determine if I have come in remotely or not. Dan Meeks, AT&T Bell Laboratories * + ___----------^---------- dwm @ ...ihnp4!ihlpf!iecp1!dwm * ___________ / >-------------------/ ( 312 ) 416 - 5379 (_========#_D_----/ . * `engage! . 200 Park Plaza, Naperville, Il 60566 `--`==_______/ + . *