rtsi.com/2014.01.www.rtsi.com.tar/www.rtsi.com/OS9/OSK/EFFO/pd1.lzh/SYS/HELP/kermit.hlp

Text File | 1989-09-06 | 18KB | 342 lines

@H
@T0
NAME            kermit - file transfer, virtual terminal over tty link

SYNOPSIS        kermit cl[e] line [esc]                   (connect)
                kermit r[ddifl] [line]                    (receive)
                kermit s[ddifl] [line] file ...           (send)
                kermit gl[ddif] line file ...             (get)
                kermit ql[ddif] line                      (quit)
                kermit h[ddifl] [line]                    (server)

DESCRIPTION     Kermit provides reliable file transfer  and  primitive  virtual
                terminal   communication   between   machines.    It  has  been
                implemented   on   many    different    computers,    including
                microprocessors  (see  below).    The  files transferred may be
                arbitrary ASCII data (7-bit  characters)  and  may  be  of  any
                length.    The file transfer protocol uses small (96 character)
                check summed packets, with  ACK/NACK  responses  and  timeouts.
                Os9 Kermit by defaults (changeable by compilation options) uses
                a fifteen "second" timeout and ten retries.

                The arguments to kermit are a set of flags (no  spaces  between
                the flags), three optional args (which, if included, must be in
                the same order as the flags  which  indicate  their  presence),
                and,  if  this is a Send or Get operation a list of one or more
                files.

                Kermit has six modes, Connect, Send, Receive,  Get,  Quit,  and
                Host.    Connect is for a virtual terminal connection, Send and
                Receive may be used to transfer files  in  a  non-server  mode,
                Send,  Get,  and Quit are used with a remote kermit server, and
                Host is used to make the Os9 system a  server  itself.    These
                modes are specified by the first flag, which should be c, s, r,
                g, q, or h respectively.  Exactly one mode must be specified.

                The file arguments are only meaningful to a Send or Get kermit.
                The  Receiving  kermit  will attempt to store the file with the
                same name that was used to  send  it.    Os9  kermits  normally
                convert  outgoing  file names to uppercase and incoming ones to
                lower case (see the f flag).  If a filename  contains  a  slash
                (/) all outgoing kermits will strip off the leading part of the
                name through the last slash.  In  the  Get  command,  filenames
                will  be  sent  to the remote host as is and the filenames sent
                back will  be  converted  as  usual  for  a  receiving  kermit.
                (Wildcard characters may be expanded on the remote end.)
@D1
About... : 2
Distribution_Rules : 7
Notes : 5
Diagnostics : 6
Example : 3
Options : 8
@T8
OPTIONS         The d flag (debug) makes kermit a bit more verbose.  The states
                kermit  goes through are printed along with other traces of its
                operation.  A second, third, and even fourth d flag will  cause
                kermit to give an even more detailed trace.

                The i flag (image) allows slightly more efficient file transfer
                between Os9 machines.  Normally (on Kermits defined to  run  on
                Os9  systems)  return  is  mapped  to  CRLF on output, LF's are
                discarded on input, and bytes are masked to 7 bits.  If this is
                set,  no mapping is done on returns, and all eight bits of each
                byte are sent or received.

                The l flag (line) specifies the tty line that kermit should use
                to  communicate with the other machine.  This is specified as a
                regular filename, like "/t2".  If no  l  option  is  specified,
                standard  input is used and kermit assumes it is running on the
                remote host (i.e.. NOT the machine to which  your  terminal  is
                attached).

                The  e flag (escape) allows the user to set the first character
                of the two character escape sequence for Connect  mode.    When
                the escape character is typed, kermit will hold it and wait for
                the next character.  If the next character is c  or  C,  kermit
                will  close the connection with the remote host.  If the second
                character is the same  as  the  escape  character,  the  escape
                character  itself  is passed.  An exclamation mark ('!') as the
                second character will cause shell to be forked.  (Use your  EOF
                character to return to the kermit connect mode.)  Any character
                other than these two results in a bell being sent to the user's
                terminal  and  no  characters  passed  to the remote host.  All
                other typed characters  are  passed  through  unchanged.    The
                default  escape  character  is  tilde ('~').  (Control-3 on the
                standard Coco keyboard.)
@T2
Authors:    Bill Catchings, Bob Cattani, Chris Maio, Columbia University
            Modified  from UNIX Kermit to Os9 Kermit By Glean Seaton and Robert
            A. Larson
            with fixes and contributions from many others.
Documentation:
            Walter Underwood, Ford Aerospace (Palo Alto, CA)
            Changed for Os9 Kermit by Robert A. Larson
            Slightly reordered form a help file by Lukas Zeller (89-09-06)
Version:    1.5
Date:       July 1985

A  sample,  working  implementation of the Kermit "kernel" was written in the C
language, and widely distributed in the Kermit Protocol Manual.    This  kernel
was  intended  merely  to  illustrate the protocol, and did not include a "user
interface", nor some of the fancy features like server support, 8-bit  quoting,
file  warning, timeouts, etc.  Several sites have added the necessary trappings
to make this a production version of Kermit, usually under the  UNIX  operating
system.  Limited server functions have also been added to the Os9 version.

The  keyword style of user/program interaction favored by Kermit (program types
prompt, user types command followed by operands, program types another  prompt,
etc)  is  contrary to the UNIX style, so UNIX implementations have a style more
familiar to UNIX users.  The Os9 version has retained  this  style  of  command
interface.    C  versions  of Kermit are running successfully on VAX and PDP-11
UNIX systems, IBM 370-compatible mainframes  under  Amdahl  UTS,  and  the  SUN
Microsystems MC68000-based and other workstations.

There  is  a  new version of Kermit written in C called C-Kermit.  (The current
version as of July 1985 is 4c.)  It is recommended for  Unix  and  adapting  to
other  operating  systems  if  memory  is  adiquate.    (It is being adapted to
Os9/68000, but is probably to large for Os9/6809.)

Os9 filespecs are of the form

    dir1/dir2/dir3/ ... /filename

where the tokens delimited by slashes form a path name, and are each limited to
29  characters  in  length.  The final token in a path is the actual file name.
By convention, it is of the form name.type, but there is nothing special  about
the dot separating name and type; to Os9 it's just another character, and there
may be many dots in a filename.
@T3
EXAMPLE         For  this  example  we  will  assume  two Os9 machines.  We are
                logged onto "Os9a" (the local machine), and want to communicate
                with "Os9b" (the remote machine).  There is a modem on "/t2".

                We  want  to  connect  to "Os9b", then transfer "file1" to that
                machine.

                We type:

                    kermit cl /t2

                Kermit answers:

                    Kermit: connected...

                Now we dial the remote machine and connect the modem.  Anything
                typed  on  the  terminal will be sent to the remote machine and
                any output from that machine will be displayed on our terminal.
                We hit RETURN, get a "login:" prompt and login.

                Now  we need to start a kermit on the remote machine so that we
                can send the file over.  First we start up the remote, (in this
                case   receiving)   kermit,  then  the  local,  (sending)  one.
                Remember that we are talking to Os9b right now.

                We type:

                    kermit r

                (there is now a Receive kermit on Os9b)

                We type ~ (the escape character) and then the letter c to  kill
                the local (Connecting) kermit:  ~c

                Kermit answers:

                    Kermit: disconnected.

                We type:

                    kermit sl /t2 file1

                Kermit answers:

                    Sending file1 as FILE1

                When  the  transmission  is  finished,  kermit will type either
                "Send complete", or "Send failed.", depending on the success of
                the  transfer.    If we now wanted to transfer a file from os9b
                (remote) to os9a (local), we would use these commands:

                    kermit cl /t2
                      (connected to Os9b)
                    kermit s file9
                      ~c (talking to Os9a again)
                    kermit rl /t2

                After all the transfers were done, we should connect again, log
                off of Os9b, kill the Connect kermit and hang up the phone.
@T5
NOTES           Kermit can interact strangely with the tty driver.

                The  KERMIT  Protocol  uses  only  printing  ASCII  characters,
                Ctrl-A, and CRLF.   Ctrl-S/Ctrl-Q  flow  control  can  be  used
                "underneath"   the   Kermit  protocol,  but  is  not  currently
                implemented in Os9 Kermit.

                Since BREAK is not an ASCII character,  kermit  cannot  send  a
                BREAK  to the remote machine.  On some systems, a BREAK will be
                read as a NUL.

                This kermit does have timeouts  when  run  under  Os9,  so  the
                protocol is stable when communicating with "dumb" kermits (that
                don't have timeouts).

                The  Quit  command  will  send a "Generic Finish" packet to the
                remote kermit server.

                The Host command has not been fully implemented and  tested  as
                of this writing.
@T6
DIAGNOSTICS     cannot open device
                The file named in the line argument did not exist  or  had  the
                wrong permissions.

                Could not create file
                A Receive kermit could not create the file being sent to it.

                nothing to connect to
                A Connect kermit was started without a line argument.
@T7
              POLICY ON COMMERCIAL USE AND DISTRIBUTION OF KERMIT

                                 Frank da Cruz

              Columbia University Center for Computing Activities

                                September, 1985


The KERMIT file transfer protocol has always been open, available, and free to
all.  The protocol was developed at the Columbia University Center for
Computing Activities, as were the first several KERMIT programs.  Columbia has
shared these programs freely with the worldwide computing community since 1981,
and as a result many individuals and institutions have contributed their own
improvements or new implementations in the same spirit.  In this manner, the
number of different systems supporting KERMIT implementations has grown from
three to over 100 in less than four years.  If Columbia had elected to keep
the protocol secret, to restrict access to source code, or to license the
software, the protocol would never have spread to cover so many systems, nor
would the programs be in use at so many sites, nor would the quality of many of
the implemementations be so high.

Although KERMIT is free and available to anyone who requests it, it is not in
the "public domain".  The protocol, the manuals, the Columbia implementations,
and many of the contributed implementations bear copyright notices dated 1981
or later, and include a legend like

  Copyright (C) 1985, Trustees of Columbia University in the City of New York.
  Permission is granted to any individual or institution to use, copy, or
  redistribute this software so long as it is not sold for profit, provided
  this copyright notice is retained.

The copyright notice is to protect KERMIT, Columbia University, and the
various contributors from having their work usurped by others and sold as a
product.  In addition, the covering letter which we include with a KERMIT tape
states that KERMIT can be passed along to others; "we ask only that profit not
be your goal, credit be given where it is due, and that new material be sent
back to us so that we can maintain a definitive and comprehensive set of KERMIT
implementations".

Within this framework, it is acceptable to charge a reproduction fee when
supplying KERMIT to others.  The reproduction fee may be designed to recover
costs of media, packaging, printing, shipping, order processing, or any
computer use required for reproduction.  The fee should not reflect any program
or documentation development effort, and it should be independent of how
many implementations of KERMIT appear on the medium or where they came from.
It should not be viewed as a license fee.  For instance, when Columbia ships a
KERMIT tape, there is a $100.00 reproduction fee which includes a 2400' reel of
magnetic tape, two printed manuals, various flyers, a box, and postage; there
is an additional $100.00 order processing charge if an invoice must be sent.
The tape includes all known versions of KERMIT, including sources and
documentation.

Commercial institutions may make unlimited internal use of KERMIT, and
KERMIT may be installed on timesharing systems where customers are charged for
system use, so long as they are not charged more for using KERMIT than for
using any other program.

A question raised with increasing frequency is whether a company may
incorporate KERMIT into its products.  A hardware vendor may wish to include
KERMIT with its standard software.  A software house may wish to incorporate
KERMIT protocol into its communications package, or to distribute it along
with some other product.  A timesharing vendor or dialup database may wish to
provide KERMIT for downloading.  All these uses of KERMIT are permissible,
with the following provisos:

 A KERMIT program may not be sold as a product in and of itself.  In addition
  to violating the prevailing spirit of sharing and cooperation, commercial
  sale of a product called "KERMIT" could violate the trade mark which is held
  on that name by Henson Associates, Inc., creators of THE MUPPET SHOW.

 Existing KERMIT programs and documentation may be included with hardware or
  other software as part of a standard package, provided the price of the
  hardware or software product is not raised significantly beyond costs of
  reproduction of the KERMIT component.

 KERMIT protocol may be included in a multi-protocol communication package as
  one of the communication options, or as a communication feature of some
  other kind of software package, in order to enhance the attractiveness of the
  package.  KERMIT protocol file transfer and management should not be the
  primary purpose of the package.  The price of the package should not be
  raised significantly because KERMIT was included, and the vendor's literature
  should make a statement to this effect.

 Credit for development of the KERMIT protocol should be given to the Columbia
  University Center for Computing Activities, and customers should be advised
  that KERMIT is available for many systems for only a nominal fee from
  Columbia and from various user group organizations, such as DECUS and SHARE.

Columbia University may grant permission to any person or institution to
develop a KERMIT program for any particular system.  A commercial institution
that intends to distribute KERMIT under the conditions listed above should be
aware that other implementations of KERMIT for the same system may appear in
the standard KERMIT distribution at any time.  Columbia University encourages
all developers of KERMIT software and documentation to contribute their work
back to Columbia for further distribution.

Finally, Columbia University does not warrant in any way the KERMIT software
nor the accuracy of any related documentation, and neither the authors of any
KERMIT programs or documentation nor Columbia University nor any other
contributing institutions acknowledge any liability resulting from program or
documentation errors.

These are general guidelines; this is not a legal document to be searched for
loopholes.  To date, KERMIT has been freely shared by all who have taken the
time to do work on it, and no formal legalities have proven necessary.  The
guidelines are designed to allow commercial enterprises to participate in the
promulgation of KERMIT without seriously violating the KERMIT user community's
trust that KERMIT will continue to spread and improve at no significant cost to
themeselves.  The guidelines are subject to change at any time, should more
formal detail prove necessary.

Commercial organizations wishing to provide KERMIT to their customers should
write a letter stating their plans and their agreement to comply with the
guidelines listed above.  The letter should be addressed to:

    KERMIT Distribution
    Columbia University Center for Computing Activities
    612 West 115th Street
    New York, NY  10025