[net.micro.pc] UNIX <--> PC Kermit

cc.fdc@COLUMBIA-20.ARPA@sri-unix.UUCP (09/07/83)

From:  Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA>

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