sklower@ucbvax.UUCP (09/11/83)
>From GEOFF5@SRI-CSL Sun Sep 11 02:25:08 1983
In response to several messages about Kermit between the IBM PC and UNIX...
First, there are several bugs in UNIX Kermit that have been identified and
fixed, notably the wildcard send business. The new UNIX Kermit (which also
has support added for various non-Berkeley UNIX systems and some performance
improvements) is being tested and will be announced shortly. It will not be,
however, the last version we'll see. Several improvements still have to be
made in the short term -- standardization of file specifications in the file
header packet (case conversion, removal of directory path, etc), addition of
error packet processing, etc. In the longer term, UNIX Kermit will also have
server mode added.
Somebody suggested that UNIX Kermit should let you say "kermit r foo.bar" to
let the incoming file be stored under a different name than it was sent with.
This is, in fact, a major source of confusion since many Kermits have this
feature. The confusion arises because different Kermits interpret this
command differently: Kermits that talk to servers (e.g. the IBM PC and CP/M
Kermits) pass the given filespec to the server in a request for the server to
send it, whereas some other Kermits (like IBM VM/CMS and DEC-20 Kermits) use
the given filespec to override the one that comes in a file header packet.
Could it be that people who are having trouble transferring files from UNIX to
the PC are giving the command "receive filespec" to the PC, rather than just
"receive"? That would certainly explain the problem, since the former causes
the PC to send a server-mode command to UNIX Kermit, which UNIX Kermit doesn't
understand.
The whole "receive filespec" business was probably a mistake to begin with.
When it's being used to override filenames from incoming file header packets,
it's only effective for a single file (not an entire wildcard batch transfer),
so its usefulness for that purpose is limited. Since it can also be used to
ask a server to send the specified file, the meaning may not be clear. For
consistency it would be better to have all versions of Kermit use the
following conventions:
send filespec send the specified local file
receive receive remote files, storing them under the name from
the file header.
receive filespec receive a single remote file, storing it under the
specified local name.
get filespec Ask the server to send the specified remote file.
Comments? - Frank
-------daemon@ucbvax.UUCP (09/15/83)
>From GEOFF5@SRI-CSL Thu Sep 15 03:10:09 1983
KERMIT is a lot like MODEM, but it has variable length packets rather than
fixed blocks, encodes nonprintable data printably to let it get past various
kinds of unfriendly front ends and into hosts that swallow control characters
or strip parity (notably IBM mainframes), runs (I believe) on a wider variety
of systems, has more thorough documentation, etc. Where MODEM is designed more
for micro-to-micro communication, KERMIT is most at home in micro-to-mainframe
environments, although it will also work micro-to-micro and mainframe-to-
mainframe; it was initially designed & written by people with mainframe rather
than microcomputer backgrounds, and (unfortunately) in total ignorance of
MODEM. We were fortunate, however, in starting with the requirement for a
protocol that worked among DEC-20s, IBM mainframes (VM/CMS), and CP/M micros.
Among those three very different types of systems, all the bases were
covered, and any system that has come along since then has fit easily into the
scheme.
KERMIT is not really 'souped up' with respect to MODEM; in some cases it may be
less efficient, but on the other hand it will work on systems that MODEM
couldn't work on, namely systems that can't accept blocks of 128 arbitrary
8-bit bytes, or over networks (like TELENET) or through front ends (like IBM
3705s) that will not transmit them unmolested.
For further information, take a look at the file KER:00README.TXT at host
COLUMBIA-20 via anonymous FTP, which will point you at thorough documentation,
source files for various implementations, etc.
- Frank
-------