Xref: utzoo comp.sys.ibm.pc:14474 comp.unix.questions:6576
Path: utzoo!mnetor!uunet!mcvax!ukc!mupsy!mucs!paulo
From: paulo@mucs.UX.CS.MAN.AC.UK (Paulo L de Geus)
Newsgroups: comp.sys.ibm.pc,comp.unix.questions
Subject: Re: kermit
Message-ID: <3589@mucs.UX.CS.MAN.AC.UK>
Date: 12 Apr 88 14:35:41 GMT
Organization: Dept. of Computer Science, University of Manchester, UK.
Lines: 30
In-reply-to: dwm@ihlpf.ATT.COM's message of 11 Apr 88 16:38:32 GM


I'm not sure if my problem was similar to the original question, but I
think some people could benefit from my experience.  Incredibly none of our
systems has a manual page for kermit.

After reading the replies on this issue I managed to transfer binary files
from a Sun server and an Atari back and forth.

I used to transfer uuencoded files using kermit under UniTerm.  When I
tried to transfer a binary file to a Sun and back to the ST (by setting
"binary" in the UniTerm's menu) not a single program worked.  Using a
diskdoctor utility revealed there was no problems concerning the 8th bit.
All bytes above 0x7F were OK, but whenever either a single 0x0D (CR) or 0x0A
(LF) were transmitted along the binary data an extra LF or CR was inserted
on the stream at that point.

I used to invoke C-Kermit on the Sun by typing "kermit -x", which prompted
it already in the server state.

The solution was to call "kermit -i" and then call the server function
(this can also be done by putting a line with "server" in the .kermrc
file).  I think "kermit -i" puts the server in a state to accept binary
transactions (sorry no docs handy to check).

It now works OK.

--
Paulo L de Geus			JANET: paulo@uk.ac.man.cs.ux
Dept of Computer Science	Internet: paulo%ux.cs.man.ac.uk@nss.cs.ucl.ac.uk
Univ of Manchester              USENET:...!mcvax!ukc!man.cs.ux!paulo
Manchester M13 9PL  U.K.