C-KERMIT (Part 4 of 10)
gregg at okstate.UUCP
gregg at okstate.UUCP
Fri Mar 8 17:45:00 AEST 1985
echo x - ckermi.doc part 2
sed '1,$s/^X//' <<\!FUNKY!STUFF! >> ckermi.doc
Xescape-character cc
X For use during 'connect' to get C-Kermit's attention. The escape character
X acts as a prefix to an 'escape command', for instance to close the connec-
X tion and return to C-Kermit or Unix command level. The normal escape
X character is Control-Backslash (28). The escape character is also used in
X System III/V implementations, to prefix interrupt commands during file
X transfers.
X
Xfile {display, names, type, warning}
X Establish various file-related parameters:
X
X display {on, off}
X Normally 'on'; when in local mode, display progress of file transfers
X on the screen (stdout), and listen to the keyboard (stdin) for inter-
X ruptions. If off (-q on command line) none of this is done, and the
X file transfer may proceed in the background oblivious to any other work
X concurrently done at the console terminal.
X
X names {converted, literal}
X Normally converted, which mean that outbound filenames have path
X specifications stripped, lowercase letters raised to upper, tildes and
X extra periods changed to X's, and an X inserted in front of any name
X that starts with period. Incoming files have uppercase letters
X lowered. Literal means that none of these conversions are done; there-
X fore, any directory path appearing in a received file specification
X must exist and be write-accessible. When literal naming is being used,
X the sender should not use path names in the file specification unless
X the same path exists on the target system and is writable.
X
X type {binary, text}
X Normally text, which means that conversion is done between Unix newline
X characters and the carriage-return/linefeed sequences required by the
X canonical Kermit file transmission format, and in common use on non-
X Unix systems. Binary means to transmit file contents without conver-
X sion. Binary ('-i' in command line notation) is necessary for binary
X files, and desirable in all Unix-to-Unix transactions to cut down on
X overhead.
X
X warning {on, off}
X Normally off, which means that incoming files will silently overwrite
X existing files of the same name. When on ('-w' on command line) Kermit
X will check if an arriving file would overwrite an existing file; if so,
X it will construct a new name for the arriving file, of the form foo~n,
X where foo is the name they share and n is a "generation number"; if foo
X exists, then the new file will be called foo~1. If foo and foo~1 ex-
X ist, the new file will be foo~2, and so on.
X
Xflow-control {none, xon/xoff}
X Normally xon/xoff for full duplex flow control. Should be set to 'none' if
X the other system cannot do xon/xoff flow control.
X
Xhandshake {xon, xoff, cr, lf, bell, esc, none}
X Normally none. Otherwise, half-duplex communication line turnaround hand-
X shaking is done, which means Unix Kermit will not reply to a packet until
X it has received the indicated handshake character or has timed out waiting
X for it.
X
Xline [device-name]
X The device name for the communication line to be used for file transfer and
X terminal connection, e.g. /dev/ttyi3. If you specify a device name, Kermit
X will be in local mode, and you should remember to issue any other necessary
X 'set' commands, such as 'set speed'. If you omit the device name, Kermit
X will revert to its default mode of operation.
X
Xmodem-dialer {direct, hayes, ventel}
X The type of modem dialer on the communication line. "Direct" indicates ei-
X ther there is no dialout modem, or that if the line requires carrier detec-
X tion to open, then 'set line' will hang waiting for an incoming call.
X "Hayes" and "Ventel" indicate that the subsequent 'set line' (or the -l
X argument) will prepare for a subsequent 'dial' command for Hayes and Ventel
X dialers, respectively.
X
Xpacket-length n
X Specify the maximum packet length to use. Normally 90. Shorter packet
X lengths can be useful on noisy lines, or with systems or front ends or net-
X works that have small buffers. The shorter the packet, the higher the
X overhead, but the lower the chance of a packet being corrupted by noise,
X and the less time to retransmit corrupted packets.
X
Xpad-character cc
X C-Kermit normally does not need to have incoming packets preceded with pad
X characters. This command allows C-Kermit to request the other Kermit to
X use cc as a pad character. Default cc is NUL, ASCII 0.
X
Xpadding n
X How many pad characters to ask for, normally 0.
X
Xparity {even, odd, mark, space, none}
X Specify character parity for use in packets and terminal connection, nor-
X mally none. If other than none, C-Kermit will seek to use the 8th-bit
X prefixing mechanism for transferring 8-bit binary data, which can be used
X successfully only if the other Kermit agrees; if not, 8-bit binary data
X cannot be successfully transferred.
X
Xprompt [string]
X The given string will be substituted for "C-Kermit>" as this program's
X prompt. If the string is omitted, the prompt will revert to "C-Kermit>".
X
Xspeed {0, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600}
X The baud rate for the external communication line. This command cannot be
X used to change the speed of your own console terminal. Many Unix systems
X are set up in such a way that you must give this command after a 'set line'
X command before you can use the line.
X
Xstart-of-packet cc
X The Kermit packet prefix is Control-A (1). The only reasons it should ever
X be changed would be: Some piece of equipment somewhere between the two Ker-
X mit programs will not pass through a Control-A; or, some piece of of equi-
X pment similarly placed is echoing its input. In the latter case, the
X recipient of such an echo can change the packet prefix for outbound packets
X to be different from that of arriving packets, so that the echoed packets
X will be ignored. The opposite Kermit must also be told to change the
X prefix for its inbound packets. Unix Kermit presently can be told to
X change only its outbound packet prefix.
X
Xtimeout n
X Normally, each Kermit partner sets its packet timeout interval based on
X what the opposite Kermit requests. This command allows you to override the
X normal procedure and specify a timeout interval. If you specify 0, then no
X timeouts will occur, and Unix Kermit will wait forever for expected packets
X to arrive.
X
X
X THE 'SHOW' COMMAND:
X
XSyntax: show {parameters, versions}
X
XThe show command displays the values of all the 'set' parameters described
Xabove. If you type 'show versions', then C-Kermit will display the version
Xnumbers and dates of all its internal modules. You should use the 'show
Xversions' command to ascertain the vintage of your Kermit program before
Xreporting problems to Kermit maintainers.
X
X
X THE 'STATISTICS' COMMAND:
X
XThe statistics command displays information about the most recent Kermit
Xprotocol transaction, including file and communication line i/o, as well as
Xwhat encoding options were in effect (such as 8th-bit prefixing, repeat-count
Xcompression).
X
X
X THE 'TAKE' AND 'ECHO' COMMANDS:
X
XSyntax: take fn1
X
XThe 'take' command instructs C-Kermit to execute commands from the named file.
XThe file may contain any interactive C-Kermit commands, including 'take'; com-
Xmand files may be nested to any reasonable depth. The 'echo' command may be
Xused within command files to issue greetings, announce progress, etc.
X
XCommand files are in exactly the same syntax as interactive commands. Note
Xthat this implies that if you want to include special characters like question
Xmark or backslash that you would have to quote with backslash when typing in-
Xteractive commands, you must quote these characters the same way in command
Xfiles.
X
XCommand files may be used in lieu of command macros, which have not been imple-
Xmented in this version of C-Kermit. For instance, if you commonly connect to a
Xsystem called 'B' that is connected to ttyh7 at 4800 baud, you could create a
Xfile called b containing the commands
X
X set line /dev/ttyh7
X set speed 4800
X echo Connecting to System B...
X connect
X
Xand then simply type 'take b' (or 't b' since no other commands begin with the
Xletter 't') whenever you wished to connect to system B.
X
XFor connecting to IBM mainframes, a number of 'set' commands are required;
Xthese, too, are conveniently collected into a 'take' file like this one:
X
X set speed 1200
X set parity mark
X set handshake xon
X set flow-control none
X set duplex half
X
XAn implicit 'take' command is executed upon your .kermrc file upon C-Kermit's
Xinitial entry into interactive dialog. The .kermrc file should contain 'set'
Xor other commands you want to be in effect at all times. For instance, you
Xmight want override the default action when incoming files have the same names
Xas existing files -- in that case, put the command
X
X set file warning on
X
Xin your .kermrc file.
X
XCommands executed from take files are not echoed at the terminal. If you want
Xto see the commands as well as their output, you could feed the command file to
XC-Kermit via redirected stdin, as in
X
X 'kermit < cmdfile'
XErrors encountered during execution of take files (such as failure to complete
Xdial or script operations) cause termination of the current take file, popping
Xto the take file that invoked it, or to interactive level. When kermit is ex-
Xecuted in the background, errors during execution of a take file are fatal.
X
X
X THE 'CONNECT' COMMAND:
X
XThe connect command links your terminal to another computer as if it were a lo-
Xcal terminal to that computer, through the device specified in the most recent
X'set line' command, or through the default device if your system is a PC or
Xworkstation. All characters you type at your keyboard are sent out the com-
Xmunication line, all characters arriving at the communication port are dis-
Xplayed on your screen. Current settings of speed, parity, duplex, and flow-
Xcontrol are honored. If you have issued a 'log session' command, everything
Xyou see on your screen will also be recorded to your session log. This
Xprovides a way to "capture" files from systems that don't have Kermit programs
Xavailable.
X
XTo get back to your own system, you must type the escape character, which is
XControl-Backslash (^\) unless you have changed it with the 'set escape' com-
Xmand, followed by a single-character command, such as 'c' for "close
Xconnection". Single-character commands include:
X
X c Close the connection
X b Send a BREAK signal
X 0 (zero) send a null
X s Give a status report about the connection
X ^\ Send Control-Backslash itself (whatever you have defined the escape
X character to be, typed twice in a row sends one copy of it).
X
XLowercase and control equivalents for these letters are also accepted. A space
Xtyped after the escape character is ignored. Any other character will produce
Xa beep.
X
XThe connect command simply displays incoming characters on the screen. It is
Xassumed any screen control sequences sent by the host will be handled by the
Xfirmware in your terminal or PC. If terminal emulation is desired, then the
Xconnect command can invoked from the Unix command line (-c or -n), piped
Xthrough a terminal emulation filter, e.g.
X
X kermit -l /dev/acu -b 1200 -c | tek
X
X'c' is an acceptable non-unique abbreviation for 'connect'.
X
X
X THE 'DIAL' COMMAND:
X
XSyntax: dial telephone-number-string
X
XThis command controls dialout modems. The telephone-number-string may contain
Xmodem-dialer commands, such as comma for Hayes pause, or '&' for Ventel dial-
Xtone wait and '%' for Ventel pause.
X
XBecause modem dialers have strict requirements to override the carrier-detect
Xsignal most Unix implementations expect, the sequence for dialing is more rigid
Xthan with the rest of kermit's features.
X
XExample one:
X
X kermit -l /dev/cul0 -b 1200
X C-Kermit>set modem-dialer hayes hint: abbreviate set m h
X C-Kermit>dial 9,5551212
X Connected!
X C-Kermit>connect hint: abbreviate c
X logon, request remote server, etc.
X C-Kermit> ...
X C-Kermit>quit hint: abbreviate q
X
Xthis disconnects modem, and unlocks line.
X
XExample two:
X
X kermit
X C-Kermit>set modem-dialer ventel
X C-Kermit>set line /dev/cul0
X C-Kermit>dial 9&5551212%
X Connected!
X C-Kermit> ...
X
XExample three:
X
X kermit
X C-Kermit>take my-dial-procedure
X Connected!
X
X file my-dial-procedure:
X set modem hayes
X set line /dev/tty99
X dial 5551212
X connect
X
XFor Hayes dialers, two important switch settings are #1 and #6. #1 should be
Xup so that the DTR is only asserted when the line is 'open'. #6 should be up
Xso carrier-detect functions properly. Switches #2 (English versus digit result
Xcodes) and #4 (Hayes echoes modem commands) may be in either position.
X
X
X THE 'SCRIPT' COMMAND:
X
XSyntax: script expect send [expect send] . . .
X
X"expect" has the syntax: expect[-send-expect[-send-expect[...]]]
X
XThis command facilitates logging into a remote system and/or invoking programs
Xor other facilities after login on a remote system.
X
XThis login script facility operates in a manner similar to that commonly used
Xby the Unix uucp System's "L.sys" file entries. A login script is a sequence
Xof the form:
X
X expect send [expect send] . . .
X
Xwhere expect is a prompt or message to be issued by the remote site, and send
Xis the string (names, numbers, etc) to return. The send may also be the
Xkeyword EOT, to send Control-D, or BREAK, to send a break signal. Letters in
Xsend may be prefixed by '~' to send special characters. These are:
X
X ~b backspace
X ~s space
X ~q '?'(trapped by Kermit's command interpreter)
X ~n linefeed
X ~r carriage return
X ~t tab
X ~' single quote
X ~~ tilde
X ~" double quote
X ~c don't append a carriage return
X ~o[o[o]]
X an octal character
X
XAs with some uucp systems, sent strings are followed by ~r unless they have a
X~c.
X
XOnly the last 7 characters in each expect are matched. A null expect, e.g. ~0
Xor two adjacent dashes, causes a short delay before proceeding to the next send
Xsequence. A null expect always succeeds.
X
XAs with uucp, if the expect string does not arrive, the script attempt fails.
XIf you expect that a sequence might not arrive, as with uucp, conditional se-
Xquences may be expressed in the form:
X
X -send-expect[-send-expect[...]]
X
Xwhere dashed sequences are followed as long as previous expects fail.
X
XExpect/send transactions can be easily be debugged by logging transactions.
XThis records all exchanges, both expected and actual.
X
XNote that '\' characters in login scripts, as in any other C-Kermit interactive
Xcommands, must be doubled up.
X
XExample one:
X
XUsing a modem, dial a unix host site. Expect "login" (...gin), and if it
Xdoesn't come, simply send a null string with a ~r. (Some Unixes require either
Xan EOT or a BREAK instead of the null sequence, depending on the particular
Xsite's "logger" program.) After providing user id and password, respond "x" to
Xa question-mark prompt, expect the Bourne shell "$" prompt (and send return if
Xit doesn't arrive). Then cd to directory kermit, and run the program called
X"wermit", entering the interactive connect state after wermit is loaded.
X
X set modem-dialer ventel
X set line /dev/tty77
X set baud 1200
X dial 9&5551212
X script gin:--gin:--gin: smith ssword: mysecret ~q x $--$
X cd~skermit $ wermit
X connect
X
XExample two:
X
XUsing a modem, dial the Telenet network. This network expects three returns
Xwith slight delays between them. These are sent following null expects. The
Xsingle return is here sent as a null string, with a return appended by default.
XFour returns are sent to be safe before looking for the prompt. Then the
Xtelenet id and password are entered. Then telenet is instructed to connect to
Xa host site (c 12345). The host has a data switch, and to "which system" it
Xresponds "myhost". This is followed by a TOPS-20 logon, and a request to load
XKermit, set even parity, and enter the server mode. Files are then exchanged.
XThe commands are in a take file. The login command is split onto two lines for
Xreadability, though it is a single long line in the take file.
X
X set modem-dialer hayes
X set line /dev/cul0
X set baud 1200
X dial 9,5551212
X set parity even
X script ~0 ~0 ~0 ~0 ~0 ~0 ~0 ~0 @-- at --@ id~saa001122 = 002211 @
X c~s12345 ystem-c~s12345-ystem myhost @ joe~ssecret @ kermit
X > set~sparity~seven > server
X send some.stuff
X get some.otherstuff
X bye
X quit
X
XSince these commands may be executed totally in the background, they can also
Xbe scheduled. A typical shell script, which might be scheduled by cron, would
Xbe as follows (csh used for this example):
X #
X #keep trying to dial and log onto remote host and exchange files
X #wait 10 minutes before retrying if dial or script fail.
X #
X while ( 1 )
X kermit < tonight.cmd &
X if ( ! $status ) break
X sleep 600
X end
X
XFile tonight.cmd might have two takes in it, for example, one to take a file
Xwith the set modem, set line, set baud, dial, and script, and a second take of
Xa file with send/get commands for the remote server. The last lines of
Xtonight.cmd should be a bye and a quit.
X
X
X THE 'HELP' COMMAND:
X
XSyntax: help
X or: help keyword
X or: help {set, remote} keyword
X
XBrief help messages or menus are always available at interactive command level
Xby typing a question mark at any point. A slightly more verbose form of help
Xis available through the 'help' command. The 'help' command with no arguments
Xprints a brief summary of how to enter commands and how to get further help.
X'help' may be followed by one of the top-level C-Kermit command keywords, such
Xas 'send', to request information about a command. Commands such as 'set' and
X'remote' have a further level of help. Thus you may type 'help', 'help set',
Xor 'help set parity'; each will provide a successively more detailed level of
Xhelp.
X
X
X THE 'EXIT' AND 'QUIT' COMMANDS:
X
XThese two commands are identical. Both of them do the following:
X
X - Attempt to insure that the terminal is returned to normal.
X - Relinquish access to any communication line assigned via 'set line'.
X - Close any open log files.
X - Relinquish any uucp and multiuser locks on the communications line.
X - Hang up the modem, if the communications line supports data terminal
X ready.
X
XAfter exit from C-Kermit, your default directory will be the same as when you
Xstarted the program. The 'exit' command is issued implicitly whenever C-Kermit
Xhalts normally, e.g. after a command line invocation, or after certain kinds of
Xinterruptions.
X
X
X1.4. C-Kermit under Berkeley or System III/V Unix:
X
XC-Kermit may be interrupted at command level or during file transfer by typing
XControl-C. The program will perform its normal exit function, restoring the
Xterminal. If a protocol transaction was in progress, an error packet will be
Xsent to the opposite Kermit so that it can terminate cleanly.
X
XC-Kermit may be invoked in the background ("&" on shell commmand line). If a
Xbackground process is "killed", the user will have to manually remove any lock
Xfile and may need to restore the modem. This is because the kill signal
X(kill(x,9)) cannot be trapped by Kermit.
X
XDuring execution of a system command, C-Kermit can often be returned to command
Xlevel by typing a single Control-C. (With System III/V, the usual interrupt
Xfunction (often the DEL key) is replaced by Control-C.) On detecting
XControl-C, C-Kermit takes its normal exit, removing lock files and restoring
Xthe communication line, modem, and/or console terminal.
X
XUnder Berkeley Unix only:
X C-Kermit may also be interrupted by ^Z to put the process in the back-
X ground. In this case the terminal is not restored. You will have to type
X Control-J followed by "reset" followed by another Control-J to get your
X terminal back to normal. C-Kermit can be halted in a similar manner by
X typing Control-
X Backslash, except that instead of moving it to the background, a core dump
X is produced.
X
XUnder System III/V Unix:
X The Control-\ character (or whatever control character has been selected
X via "set escape") at the C-Kermit command level is ignored; it is trapped
X and will not core-dump or interrupt Kermit.
X
XControl-C, Control-Z, and Control-\ lose their normal functions during terminal
Xconnection and also during file transfer when the controlling tty line is being
Xused for packet i/o.
X
XThe BSD implementation of C-Kermit has code to take advantage of a special non-
Xstandard kernel-mode line driver, which boosts the speed of packet i/o sig-
Xnificantly. The problem is that "raw" mode, needed for packet i/o, also im-
Xplies "cbreak" (character wakeup) mode, which is very expensive. The new line
Xdriver is a modification of the "berknet" driver, which allowed raw mode i/o to
Xtake place with process wakeup only upon receipt of a linefeed. The Berknet
Xdriver, unfortunately, strips off the high order bit of each character and does
Xnot allow the line terminator to be specified. The modification allows all 8
Xbits to pass through unmolested, allows the wakeup character to be specified,
Xand allows the buffer to be tested or cleared.
X
XThe System III/V implementation uses regular kernel drivers, but "gulps" raw-
Xmode input in large blocks, thus overcomming the usual system call overheads.
X
XIf you are running C-Kermit in "quiet mode" in the foreground, then interrupt-
Xing the program with a console interrupt like Control-C will not restore the
Xterminal to normal conversational operation. This is because the system call
Xto enable console interrupt traps will cause the program to block if it's run-
Xning in the background, and the primary reason for quiet mode is to allow the
Xprogram to run in the background without blocking, so that you can do other
Xwork in the foreground.
X
XIf C-Kermit is run in the background ("&" on shell commmand line), then the in-
Xterrupt signal (Control-C) (and System III/V quit signal) are ignored. This
Xprevents an interrupt signal intended for a foreground job (say a compilation)
Xfrom being trapped by a background Kermit session.
X
X
X1.5. C-Kermit on the DEC Pro-3xx with Venix 1.0
X
XThe DEC Professional 300 series are PDP-11/23 based personal computers. Venix
X1.0 is a Unix v7 derivative. It should not be confused with Venix 2.0, which
Xresembles ATT System V. C-Kermit runs in local mode on the Pro-3xx when invoked
Xfrom the console; the default device is /dev/com1. When connected to a remote
Xsystem (using C-Kermit's 'connect' command), Pro/Venix itself (not Kermit)
Xprovides VT52 terminal emulation.
X
XDuring file transfer, the interruption and status commands (Control-A,
XControl-F, etc) are not available.
X
X
X1.6. C-Kermit Restrictions and Known Bugs
X
X 1. File renaming: When filename collision avoidance ("warning") is
X selected, C-Kermit constructs unique names by appending a generation
X number to the end of the file name. Currently, no checking is done
X to ensure that the result is still within the maximum length for a
X file name.
X
X 2. UUCP line locking: C-Kermit locks lines, to prevent UUCP and mul-
X tiuser conflicts, when it first opens a communications line. This
X occurs either when 'set line' is issued, or if the '-l' argument is
X used, when the first 'dial', 'connect', or protocol operation oc-
X curs. The lock is released if another 'set line' is issued, or if
X the program quits, exits, or is terminated by Control-C. If a user
X connects and returns to the shell command level, for example to in-
X itiate kermit by piped commands, on a communications line, the line
X lock is released when returning to the shell. Locking is not
X needed, or used, if communications occur over the local terminal
X line (e.g. /dev/tty). In that case, there is no difficultly with
X "piped" operations releasing locks and lines.
X
X 3. Removing stale lock files: For various reasons, lock files some-
X times get left about after uucp or C-Kermit activities. (The most
X common reason is that the uucp or C-Kermit activity was "killed" by
X a shell command.) If the lock file is owned by yourself, clearly
X you may remove it (presuming you are not running C-Kermit or uucp in
X the background when you discovered it).
X
X Uucp supports a function, called uuclean, which is customarily used
X to remove these files after a predetermined age. If in doubt about
X a lock file on the dial-out line you need, contact your system's
X operator.
X
X 4. Modem controls: If connection is made over a communication line
X (rather than on the controlling terminal line), and that line has
X modem controls, (e.g. data terminal ready and carrier detection
X implementation), returning to the shell level will disconnect the
X conversation. In that case, one should use interactive mode com-
X mands, and avoid use of piped shell-level operation (also see 'set
X modem-dialer' and 'dial' commands.)
X
X 5. Login Scripts: The present login scripts implementation follows the
X Unix conventions of uucp's "L.sys" file, rather than the normal Ker-
X mit "INPUT/OUTPUT" style. Volunteers have indicated an intent to
X implement the Kermit standard for login scripts, and indeed even
X others may be implemented in the future as needed.
X
X 6. Dial-out vs dial-in communications lines C-Kermit requires a
X dial-out line for the "set line" or "-l" options. Most systems have
X some lines dedicated to dial-in, which they enable "loggers" on, and
X some lines available for dial-out. Where a line must be shared be-
X tween dial-in and dial-out, several options are available (though
X they are, strictly speaking, outside the pervue of C-Kermit).
X
X A simple shell program can be used to change directionality of the
X line if your Unix has the enable(8) and disable(8) commands. In
X that case, the shell program could "grep" a "who" to see if anybody
X is logged onto the desired line; if not, it could "disable" the
X line. The shell program will need to be set-uID'ed to root. The
X shell program can be called from kermit prior to a dial command,
X e.g., "! mydisable.shellprog". Prior to the final "quit" from
X C-Kermit, another shell program could be executed to "enable" the
X line again. This program also needs to be set-uID'ed to root.
X
X If your Unix lacks the enable(8) and disable(8) commands, another
X common technique works if your system supports the /etc/ttys file.
X A shell program could call up an awk program to find the line in the
X file and set the enable byte to 0 (to directly disable the line).
X Likewise, it can be reenabled by a counterpart at the end. It may
X be necessary to pause for 60 seconds after modifying that file be-
X fore the logger sees it and actually disables the line.
X
X 7. Using C-Kermit on Local Area Networks: C-Kermit can successfully
X operate at speeds up to 9600 baud over LANs. Testing has, however,
X shown that most processors, whether PC/XTs with PC/IX, or Vaxes,
X need flow control at these rates. A command, "set flow x" should be
X issued to each end of this form of connection.
X
X If the LAN is the sort with an interface card (or box, like the
X Sytek), then the interface card/box must be programmed to handle the
X flow control characters (xon and xoff) at the card/box level (rather
X than forwarding these characters to the remote site). This is be-
X cause packetizing LANs will not deliver the xoff character to the
X other end, after packetization, until long after the receive buffer
X has been overrun.
X
X 8. Resetting terminal after abnormal termination or kill: When C-Kermit
X terminates abnormally (say, for example, by a kill command issued by
X the operator) the user may need to reset the terminal state. If
X commands do not seem to be accepted at the shell prompt, try
X Control-J "stty sane" Control-J (use "reset" on Berkeley Unix).
X That should take the terminal out of "raw mode" if it was stuck
X there.
X
X 9. Remote host commands may time-out on lengthy activity: Using
X "remote host" to instruct the C-Kermit server to invoke Unix func-
X tions (like "make") that might take a long time to produce output
X can cause timeout conditions.
X
X 10. PC/IX Login Scripts -- Unfound Bug: Though login scripts appear to
X work properly on most processors, in the case of the PC/XT with
X PC/IX, it appears that longer scripts need to be broken up into
X shorter scripts (invoked sequentially from the take file). This is
X because the portion of the script handler which checks if an opera-
X tion timed out seems to leave the processor in a strange state (i.e.
X hung).
X
X
X1.7. How to Build C-Kermit for a Unix System
X
XThe C-Kermit files, as distributed from Columbia, all begin with the prefix
X"ck". You should make a directory for these files and then cd to it. A
Xmakefile is provided to build C-Kermit for various Unix systems. As dis-
Xtributed, the makefile has the name "ckermi.mak". You should rename it to
X"makefile" and then type "make xxx", where xxx is the symbol for your system,
Xfor instance "make bsd" to make C-Kermit for 4.2 BSD Unix. The result will be
Xa program called "wermit". You should test this to make sure it works; if it
Xdoes, then you can rename it to "kermit" and install it for general use. See
Xthe makefile for a list of the systems supported and the corresponding "make"
Xarguments.
X
X
X1.8. Adapting C-Kermit to Other Systems
X
XC-Kermit is designed for portability. The level of portability is indicated in
Xparentheses after the module name: "C" means any system that has a C compiler
Xthat conforms to the description in "The C Programming Language" by Kernighan &
XRitchie (Prentice-Hall, 1978). "Cf" is like "C", but also requires "standard"
Xfeatures like printf and fprintf, argument passing via argv/argc, and so on, as
Xdescribed in Kernighan & Ritchie. "Unix" means the module should be useful un-
Xder any Unix implementation; it requires features such as fork() and pipes.
XAnything else means that the module is particular to the indicated system. The
Xmodules are:
X
Xckmain.c, ckermi.h, ckdebu.h (Cf):
X This is the main program. It contains declarations for global variables
X and a small amount of code to initialize some variables and invoke the com-
X mand parser. In its distributed form, it assumes that command line ar-
X guments are passed to it via argc and argv. Since this portion of code is
X only several lines long, it should be easy to replace for systems that have
X different styles of user interaction. The header files define symbols and
X macros used by the various modules of C-Kermit. ckdebu.h is the only
X header file that is included by all the C-Kermit modules, so it contains
X not only the debug format definitions, but also any system-dependent
X typedefs.
X
Xwart.c (Cf), ckprot.w (C):
X The ckprot module embodies the Kermit protocol state table and the code to
X accomplish state switching. It is written in "wart", a language which may
X be regarded as a subset of the Unix "lex" lexical analyzer generator. Wart
X implements enough of lex to allow the ckprot module to function. Lex it-
X self was not used because it is proprietary (but lex may be used in place
X of wart with minor reformatting of ckprot.w -- removal of #includes and
X comments, which must be reinserted into lex's output C program). The
X protocol module ckprot.w is read by wart, and a system-independent C
X program is produced. The syntax of a Wart program is illustrated by
X ckprot.w, and is described in ckwart.doc.
X
Xckfns.c (C):
X The module contains all the Kermit protocol support functions -- packet
X formation, encoding, decoding, block check calculation, filename and data
X conversion, protocol parameter negotiation, and high-level interaction with
X the communication line and file system. To accommodate small systems, this
X module has been split into two -- ckfns.c and ckfns2.c.
X
Xckx???.c (specific to system ???):
X For instance, ckxunx.c (Berkeley, Venix, ATT System III/V, and other Unix
X systems) -- The ckx module contains the system-dependent primitives for
X communication line i/o, timers, and interrupts. Certain important vari-
X ables are defined in this module, which determine whether C-Kermit is by
X default remote or local, what the default communication device is, and so
X forth. The ckx module maintains its own private database of file descrip-
X tors and modes for the console terminal and the file transfer communication
X line so that other modules (like ckfns or the terminal connect module) need
X not be concerned with them. This module will vary significantly among Unix
X implementations since the sgtty/ioctl/termio functions and their arguments
X are among the least compatible areas of Unix. The ckxunx.c file has con-
X ditional compilation for the variations of Unix.
X
Xckz???.c (specific to system ???):
X For instance, ckzunx.c (Berkeley, Venix, System III/V Unix) -- The ckz
X module contains system-dependent primitives for file i/o, wildcard (meta
X character) expansion, file existence and access checking, and system com-
X mand execution. It maintains an internal database of i/o "channels" (file
X pointers in the case of Unix) for the files C-Kermit cares about -- the in-
X put file (the file which is being sent), the output file (the file being
X received), the various logs, the screen, and so forth. This module will
X vary little among Unix implementations except for the wildcard expansion
X code, which requires detailed knowledge of the directory structure. The
X ckz module also defines variables containing the system command strings
X used to perform certain functions like directory listing, file deletion,
X etc. The ckzunx.c file has conditional compilation for the variations of
X Unix.
X
Xckuser.h, ckuser.c, ckusr2.c, ckusr3.c (Unix):
X This is the "user interface" for C-Kermit. It includes the command parser,
X the screen output functions, and console input functions. The command par-
X ser comes in two pieces -- the traditional Unix command line decoder (which
X is quite small and compact), and the interactive keyword parser (which is
X rather large). This module is fully replacable; its interface to the other
X modules is very simple, and is explained at the beginning of the source
X file. The ckuser module also includes code to execute any commands
X directly which don't require the Kermit protocol -- local file management,
X etc. The module is rated "Unix" because it makes occasional use of the
X system() function.
X
X Note that while ckuser is logically one module, it has been split up into
X three C source files, plus a header file for the symbols they share in com-
X mon. This is to accommodate small systems that cannot handle big modules.
X ckuser.c has the command line and top-level interactive command parser;
X ckusr2.c has the help command and strings; ckusr3 has the set and remote
X commands along with the logging, screen, and "interrupt" functions.
X
Xckcmd.c, ckcmd.h (Cf):
X This is an interactive command parsing package developed for C-Kermit. It
X is written portably enough to be usable on any system that has a C compiler
X that supports functions like printf. The file name parsing functions
X depend upon primitives defined in the ckz module; if these primitives can-
X not be supplied for a certain system, then the filename parsing functions
X can be deleted, and the package will still be useful for parsing keywords,
X numbers, arbitrary text strings, and so forth. The style of interaction is
X the same as that found on the DECSYSTEM-20.
X
Xckconu.c (Unix):
X This is the connect module. As supplied, it should operate in any Unix en-
X vironment, or any C-based environment that provides the fork() function.
X The module requires access to global variables that specify line speed,
X parity, duplex, flow control, etc, but invokes functions from the ckx
X module to accomplish the desired settings and input/output, and functions
X from the ckz module to perform session logging. There is no code for con-
X trolling modem signals. No terminal emulation is performed, but since
X standard i/o is used for the console, this may be piped through a terminal
X emulation filter. The ckconu function may be entirely replaced, so long as
X the global settings are honored by its replacement. PC implementations of
X C-Kermit may require the ckcon module to do screen control, escape sequence
X interpretation, etc, and may also wish to write special code to get the
X best possible performance.
X
Xckdial.c (Unix):
X This is the dialer module. As supplied, it handles hayes and ventel
X modems.
X
Xcklogi.c (Unix):
X This is the login script module. As supplied, it handles uucp-style
X logins.
X
XMoving C-Kermit to a new system entails:
X
X 1. Creating a new ckx module in C, assembler, or whatever language is
X most appropriate for system programming on the new system.
X
X 2. Creating a new ckz module, as above.
X
X 3. If the system is not Unix-like, then a new ckuser module may be re-
X quired, as well as a different invocation of it from ckmain.
X
X 4. If the distributed connect module doesn't work or performs poorly,
X then it may be replaced. For instance, interrupt-driven i/o may be
X required, especially if the system doesn't have forks.
X
XThose who favor a different style of user/program interaction from that
Xprovided in ckuser.c may replace the entire module, for instance with one that
Xprovides a mouse/window/icon environment, a menu/function-key environment, etc.
X
XA few guidelines should be followed to maintain portability:
X
X - Keep variable and function names to 6 characters or less.
X
X - Keep modules small. For instance, on a PDP-11 it is necessary to
X keep the code segment of each module below 8K in order to allow the
X segment mapping to occur which is necessary to run programs larger
X than 64K on a non-I-&-D-space machine.
X
X - Keep strings short; many compilers have restrictive maximum lengths.
X
X - Keep (f,s)printf arguments short. If these exceed some compiler de-
X pendent maximum (perhaps as short as 128, after expansion) memory
X will be overwritten and the program will probably core dump.
X
X - Do not introduce system dependencies into ckprot.w or ckfns*.c.
X
XIn general, remember that this program will have to be compilable by old com-
Xpilers and runnable on small systems.
X
X
X
XIndex
X
X
X C-Kermit 1
X
X TELENET 6
X
X Unix Kermit 1
X
X
X
X Table of Contents
X
X1. UNIX KERMIT 1
X
X 1.1. The Unix File System 1
X 1.2. Command Line Operation 1
X 1.3. Interactive Operation 3
X 1.4. C-Kermit under Berkeley or System III/V Unix: 7
X 1.5. C-Kermit on the DEC Pro-3xx with Venix 1.0 7
X 1.6. C-Kermit Restrictions and Known Bugs 7
X 1.7. How to Build C-Kermit for a Unix System 8
X 1.8. Adapting C-Kermit to Other Systems 8
X
XIndex i
!FUNKY!STUFF!
More information about the Comp.sources.unix
mailing list