Path: utzoo!attcan!uunet!husc6!mailrus!ames!vsi1!daver!carpet!bill
From: bill@carpet.WLK.COM (Bill Kennedy)
Newsgroups: comp.mail.uucp
Subject: Re: uucp via a rlogin session
Message-ID: <166@carpet.WLK.COM>
Date: 2 Oct 88 00:19:24 GMT
References: <531@comdesign.CDI.COM> <317@magnus.UUCP> <13797@mimsy.UUCP>
Reply-To: bill@ssbn.WLK.COM (Bill Kennedy)
Distribution: na
Organization: W.L. Kennedy Jr & Associates, Pipe Creek, TX
Lines: 53

|>In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes:
|>>I've heard that someone out there has managed to get UUCP to work over
|>>rlogin sessions. ...
|
|In article <317@magnus.UUCP> mml@magnus.UUCP (Mike Levin) writes:
|>	Sorry, Paul.  Unless I'm *very* much mistaken, rlogin only supports
|>an ASCII (7 bit) data stream.  UUCP requires full 8-bits.  This *may* not
|>be true on your machine, but I'm sure it is on mine.  :-(
|
In article <13797@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
|The g-protocol requires an 8-bit path; UUCP itself does not care, but
|if you only have the g protocol inside it, you are stuck.  But rlogin
|*does* support an 8 bit data path (`rlogin -8').  The problem is that
|rlogin, as it is delivered by Berkeley (and thus presuably DEC and Sun)
|will not allow you to disable escapes.  `rlogin -e\255' (as Paul tried)
|sets the escape character to \.  Since the escape character is in fact
|a `char' variable, and holds only 8 bits, there is no input that will
|set it to something UUCP will never use.
|
|If you have source, you can fix this; if not, you will have to plead
|with your vendor.
|-- 
|In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)

I'm sorry to duplicate so much of this but I'm genuinely confused and don't
want to omit something that might be vital to my (and others') understanding.

I did some work for Sun Microsystems a while back and the only reasonable
way to get the data from where it was (an IBM PC-XT) to where it needed to
be (a Sun 3/140) was to use uucp with the XT running UULINK.  This was well
and good until someone pulled out the serial line we had been using and left
us with only one line to a terminal that was on another system.

Not knowing that you couldn't rlogin to uucico I changed the chat script
so that the first thing to do was rlogin to the target system and execute
uucico as the default shell just like we did when we were connected
directly and logged in via getty.

It was perhaps not the most elegant approach to the problem but it did work
and continues to work that way (as recently as yesterday).  Should we not
have been able to do this?  We are transferring 8 bit binary .COM files
into the Sun to be downloaded into an intelligent conveyor controller.  That
leaves me more puzzled than ever since we send them straight in, no uuencode
or anything like that and they work.  We don't have any sttys or anything,
we just unplug the terminal that's connected to another system, log in and
then rlogin to the target.

I'm not really asking if it should work or not, I'm more concerned about
whether it's likely to break.  Should we be unable to do this?  If so,
should we be alert for it to stop working when someone "fixes" it?
-- 
Bill Kennedy  Internet:  bill@ssbn.WLK.COM
                Usenet:  { killer | att | rutgers | uunet!bigtex }!ssbn!bill