Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!rutgers!bellcore!faline!thumper!tr From: tr@thumper.bellcore.com (tom reingold) Newsgroups: comp.sys.ibm.pc Subject: Enclosed is MS-Kermit document (part 1 of 7) Message-ID: <893@thumper.bellcore.com> Date: 31 Dec 87 13:15:43 GMT Organization: Bellcore, Morristown, Noo Joizy Lines: 706 @@@@@@@@@@@@@@@@@@@@ Cut and concatenate here. @@@@@@@@@@@@@@@@@@@@ MS-DOS KERMIT USER GUIDE FOR THE IBM PC FAMILY, COMPATIBLES, AND OTHER MS-DOS SYSTEMS C. Gianone, F. da Cruz Columbia University Center for Computing Activities New York, New York 10027 J.R. Doupnik CASS and EE, Utah State University, Logan, UT 84322 Copyright (C) 1981,1987 Trustees of Columbia University in the City of New York Permission is granted to any individual or institution to use, copy, or redistribute this document so long as it is not sold for profit, and provided this copyright notice is retained. 1. MS-DOS KERMIT -------- This document is formatted as an ordinary, plain text ASCII disk file, from SCRIBE text formatter source. Typeset copies are available from Columbia University. -------- *DRAFT OF 15 DEC 1987, ALSO APPLIES TO VERSION 2.29C WITH MINOR DIFFERENCES* Program: Joe R. Doupnik (Utah State University), with contributions by James Harvey (Indiana/Purdue University), James Sturdevant (A.C. Nielson Company), and many others. Originally by Daphne Tzoar and Jeff Damens (Columbia University). See History. Language: Microsoft Macro Assembler (MASM) Version: 2.30 Released: December xx, 1987 Documentation: Christine Gianone, Frank da Cruz (Columbia University), Joe R. Doupnik (Utah State University) Dedicated To: Peppi Kermit-MS Capabilities At A Glance: Local operation: Yes Remote operation: Yes Transfers text files: Yes Transfers binary files: Yes Wildcard send: Yes File transfer interruption: Yes Filename collision avoidance: Yes Can time out: Yes 8th-bit prefixing: Yes Repeat count compression: Yes Alternate block check types: Yes Terminal emulation: VT102, H19, VT52, Tektronix 4010 Communication settings: Yes Transmit BREAK: Yes IBM mainframe communication: Yes Transaction logging: No Session logging (raw download): Yes Raw upload: Yes Act as server: Yes Talk to server: Yes Advanced server functions: Yes Advanced commands for servers: Yes Local file management: Yes Command/init files: Yes Command macros: Yes Extended-length packets: Yes Local area networks: Yes Attribute packets: No Sliding windows: No MS-DOS Kermit, or Kermit-MS (or MS-Kermit), is a program that implements the Kermit file transfer protocol for the entire IBM PC family, including the PS/2 series, IBM compatibles, and several other machines based on the Intel 8086 processor series (8088, 80286, etc) and the DOS operating system family (PC-DOS or MS-DOS, henceforth referred to collectively as MS-DOS or simply DOS). It is assumed you are already familiar with the general ideas of data com- munication and Kermit file transfer. A very brief overview is given here, but for details consult the early chapters of the Kermit User Guide (of which this document is a chapter), or the book Kermit, A File Transfer Protocol, by Frank da Cruz, Digital Press (1987), order number EY-6705E-DP (phone 1-800-343-8321), which also includes background tutorials on computers, file systems, and data communication (including modems, cabling, etc.) For further information about Kermit documentation, updates, lists of current available versions, etc, write to: Kermit Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, NY 10025 (USA) 1.1. History Over the years, MS-Kermit has grown from a Kermit file transfer program that embodied a simple terminal emulator into a complex and powerful communication program that includes the Kermit file transfer protocol. As a result, the bulk of this manual is devoted to the communication features, rather than Kermit protocol operation. Skip ahead to the next section if you're not interested in the history of MS-Kermit. MS-DOS Kermit (like the Kermit file transfer protocol itself) is a product of the Systems Integration Group of the Columbia University Center for Computing Activities, managed by Frank da Cruz, and it was one of the four original Ker- mit programs (with the CP/M, DEC-20, and IBM mainframe versions). It was in- itially written for the IBM PC with DOS 1.1 by Daphne Tzoar in 1981-1982, based largely on Bill Catchings's original CP/M 8080 assembler version. PC-Kermit (as it was called then) provided basic Kermit file transfer and VT52 emulation. Joellen Windsor of the University of Arizona added conditional assembly support for the Heath/Zenith-100 shortly thereafter, and soon after that Dave King of Carnegie-Mellon University added Heath-19 terminal emulation, and some patches to let the program run under the new DOS version, 2.0. During this era, the program version numbers went from 1.0 to 1.20. With the appearance in the marketplace of many new MS-DOS machines that were not compatible with the IBM PC, it became apparent that conditionally assembled code supporting each of these machines within a single monolithic source file was not the best way to organize the program. Therefore Daphne, along with Jeff Damens of Columbia, undertook to reorganize the program in a modular way, isolating system dependencies into separate files. The result was version 2.26, released in July 1984. It included support for the DEC Rainbow, the HP-150, the Wang PC, and generic MS-DOS, as well as for the IBM PC family and the H/Z-100. It also included many new features, like 8th-bit prefixing (code contributed by The Source Telecomputing), alternate block check selection, byte-count compression, server/client operation, access to local file and DOS operations, command macros, initialization and command files, screen rollback, key redefinition, and more. For the 2.26 release, the executable Kermit programs were encoded printably as ".BOO" files, designed by Bill Catchings as part of this effort. Release 2.27 was produced by Daphne and Jeff in December 1984. Unlike 2.26, it ran correctly on the new PC/AT under DOS 3.0, and included support for the NEC APC from Ron Blanford of Seattle, WA, and Ian Gibbons of the University of Hawaii, and for the TI Professional from Joe Smith of the Colorado School of Mines, plus some bug fixes and reorganization. 2.27 was the last version able to run under pre-2.0 versions of DOS. Version 2.28 (Daphne, Jeff, June 1985) added dynamic memory allocation to reduce disk storage for the .EXE file, and to allow the program to adjust it- self to the PC's memory size, plus the inevitable bug fixes (many of them con- tributed by Edgar Butt of the University of Maryland and Gregg Small of the University of California at Berkeley). During this period, support for ad- ditional MS-DOS systems was added by various people. In December 1985, a tape showed up at Columbia sent by Prof. Joe R. Doupnik of the Center for Atmospheric and Space Studies and EE Department at Utah State University. This tape contained version 2.28 modified to fully support the DOS 2.0 file system, and to which many new features had been added, notably the ability of the MS-DOS Kermit server to process various REMOTE commands (DIR, CWD, SPACE, etc). And at about the same time, a tape arrived from James Harvey of Indiana/Purdue University, who had changed Kermit's CONNECT command to emu- late the popular DEC VT100 terminal. This material was sent to Joe, who then laboriously fitted James's work into his own code, keeping the VT52 and H19 emulation alive as options, and upgrading the VT100 emulation to VT102 by ad- ding features such as line and character insertion and deletion. The result was version 2.29, released in May 1986. Soon after the release of 2.29, some disks were sent in by James Sturdevant of the A.C. Nielson Company, containing a full implementation of the Kermit script facility, as described in the Kermit book. This material was sent to Joe, who had by now become keeper of MS-DOS Kermit and had already begun work on version 2.30 by adding support for extended-length packets. Joe had been carrying on voluminous network correspondence (Thanks, BITNET!) with Columbia and with MS-DOS Kermit users and testers all over the world, giving birth to many new features, including support for 8-bit ASCII terminal connections and inter- national character sets, ANSI printer control, support for operation over local area networks, and a redesigned, more powerful, more portable key redefinition mechanism. Version 2.30 was released in December 1987. Among the many contributors to this version are: Robert Goeke for the NEC AP3, Brian Peterson and Andreas Stumpf for the Victor 9000, Bob Babcock and Joe White for the Sanyos, Christopher Lent for the Wang PC, Jack Bryans for an In- tel iRMX version, Jim Noble for the Grid Compass, Geoff Mulligan and others for the Zenith 100, and David Knoell for the special Rainbow edition. And thanks to Gisbert Selke, Jack Bryans, and others for proofreading drafts of this manual. And apologies to anyone we neglected to mention. 1.2. System Requirements Kermit-MS version 2.30 runs in as little as 70K of memory (about 55K contiguous), but will occupy up to 120K, if it can be found, for extra screen rollback memory. Versions not using screen rollback memory will not require the additional space. It will also try to leave 24 Kbytes free for a second copy of COMMAND.COM which is needed for execution of certain commands. On the IBM PC family, Kermit-MS 2.30 performs almost complete emulation of the DEC VT-102 and Heath/Zenith-19 terminals at speeds up to 19,200 baud or greater, lacking only the VT102's smooth scrolling and, on some display boards, 132 column features. Much of the speed is accomplished via direct writes to screen memory, but this is done in a "TopView-aware" manner to allow successful operation in windowing environments like MS-Windows, DesqView, and TopView it- self. Speed is also due to direct access of the serial port 8250 UART (Universal Asynchronous Receiver/Transmitter) chip, with buffered, interrupt- driven receipt of characters and selectable XON/XOFF flow control. Full speed 9600 baud operation is possible on 4.77Mhz systems without flow control, but flow control is required on these systems for 19,200 baud or higher rates. The IBM PC version will also run on near-clones like the DG/1 that differ from true PCs only in their choice of UART; non-8250 UARTs are detected automati- cally, and slower non-interrupt driven Bios serial port i/o is used, in which case the top speed is in the 1200 baud range. As of version 2.30, Kermit-MS performs Tektronix 4010 graphics terminal emula- tion on IBM PC family systems equipped with CGA, EGA, and Hercules graphics adapters, with either color or monochrome monitors. Kermit-MS 2.30 runs on the entire IBM PC family (the PC, XT, AT, PCjr, Portable PC, PC Convertible, PS/2) and compatibles (Compaq, Z150, etc), and there are also specially tailored versions for non-IBM-compatibles like the DEC Rainbow, NEC APC, Sanyo MBC, Victor 9000, HP-110, HP-150, HP Portable Plus, and others, plus a "generic DOS" version that should run (slowly) on any 8086-based MS-DOS machine. This document concentrates on the IBM version; some of the system-de- pendent capabilities described here may be lacking in the non-IBM versions. See section 1.9 for features of different systems. 1.3. Using MS-Kermit MS-DOS Kermit performs two major functions, terminal emulation and file trans- fer. Before you can transfer files with another system you must first connect to it as a terminal, login if necessary, and start up a Kermit program there. The following example shows this process; the other computer is a Unix system, but the method is the same with most others. The parts you type are underlined (if this document was printed on a printer that can underline), and when you type a command, you terminate it with a carriage return, which you can't see in the example. The cryptic "^]c" is MS-Kermit's "escape sequence", which you enter by holding down the Control (Ctrl) key and pressing "]" (right square bracket), and then typing the letter C. The MS-Kermit program is stored on disk as KERMIT.EXE. Program Dialog Explanation A>kermit IBM PC Kermit-MS V2.30 Program's greeting. Type ? for help Kermit-MS>set speed 1200 Set the right baud rate. Kermit-MS>connect Connect as a terminal. (Connecting to host, type ^]C to return to PC.) ATDT7654321 Dial the modem if necessary. CONNECT 1200 The modem tells you you're connected. Now you're talking to the Unix system. Type a carriage return to get its attention. Login: christin Login to the host. password: % kermit Run Kermit on the host. C-Kermit>receive Tell it to receive a file. ^]c Escape back to the PC. Kermit-MS>send autoexec.bat Send a file. (The file is transferred...) Kermit-MS> Transfer complete, prompt reappears. In this example, the user types "kermit", and sees the program's herald and its prompt, "Kermit-MS>". Then she sets the appropriate communication speed ("baud rate"), connects as a terminal, issues a dialing command to a Hayes-like modem (you would skip this step if you had a direct connection), logs in to her ID on the Unix system which she has dialed, starts "C-Kermit" on the Unix system, tells it to receive a file, escapes back to the PC, and tells MS-Kermit to send a file. After the file is transferred, the user would normally connect back to the Unix system, exit from the Kermit program there, and log out: Kermit-MS>connect Connect again. (Connecting to host, type ^]C to return.) C-Kermit>exit % ^D Logout from Unix by typing Ctrl-D. ^]c Escape back to PC. Kermit-MS>exit Return to DOS. To transfer a file in the other direction, simply exchange the "send" and "receive" commands above. That's the easiest and quickest way to use Kermit. If this simple scenario does not work for you, issue the MS-Kermit STATUS com- mand and look for any obvious incorrect settings (speed, parity), fix them with SET commands, and try again. (IBM mainframes have so many "different" set- tings, there's a special command for them, "do ibm", which you would type as the first Kermit-MS command above.) If that doesn't help, read on. Many problems can crop up when you attempt to connect two unlike systems over a pos- sibly hostile communication medium. And if you intend to be a frequent user of Kermit, there are many options you can take advantage of to adapt MS-Kermit to different systems, improve its performance, and automate common tasks. 1.4. The MS-DOS File System The features of the MS-DOS file system of greatest interest to Kermit users are the form of the file specifications, and the formats of the files themselves. 1.4.1. File Specifications MS-DOS file specifications (in version 2.0 or later of DOS) are of the form DEVICE:\PATHNAME\NAME.TYPE where the DEVICE is a single character identifier (for instance, A for the first floppy disk, C for the first fixed disk, D for a RAM disk emulator) fol- lowed by a colon (":"), PATHNAME is up to 63 characters of identifier(s) (up to 8 characters each) surrounded by backslashes ("\"), NAME is an identifier of up to 8 characters, and TYPE is an identifier of up to 3 characters in length. Device and pathname may be omitted. The first backslash in the pathname may be omitted if the specified path is relative to the current directory. In the path field, "." means the current directory, ".." means the parent directory. Some DOS implementations (like Wang) may use slash ("/") rather than backslash as a directory separator. Pathname is normally omitted, but can be specified in all Kermit-MS commands (as of version 2.29). Device and directory pathnames, when omitted, default to either the user's current disk and directory, or to the current directory search path as specified in the DOS PATH environment variable, depending on the context in which the file name appears. When this document says that a file is searched for "in the current path," it means that Kermit-MS looks on the current disk and directory first, and if the file is not found, then the directories listed in the PATH environment variable are searched. If the PATH environment vari- able is empty, Kermit looks only at the current disk and directory. NAME.TYPE is sufficient to specify a file on the current disk and directory, and only this information is sent along by Kermit-MS with an outgoing file. The device, path, name, and type fields may contain uppercase letters, digits, and the special characters "-" (dash), "_" (underscore), "$" (dollar sign), "&" (ampersand), "#" (number sign), "@" (at sign), "!" (exclamation mark), "'" (single quote), "()" (parentheses), "{}" (curly braces), "^" (caret or circumflex), "~" (tilde), and "`" (accent grave). Normally, you should confine your filenames to letters and digits for maximum transportability to non-DOS systems. When you type lowercase letters in filenames, they are converted automatically to uppercase. There are no imbedded or trailing spaces. Other characters may not be included; there is no mechanism for "quoting" otherwise illegal characters in filenames. The fields of the file specification are set off from one another by the punctuation indicated above. The name field is the primary identifier for the file. The type, also called the extension or suffix, is an indicator which, by convention, tells what kind of file we have. For instance FOO.BAS is the source of a BASIC program named FOO; FOO.OBJ might be the relocatable object module produced by compiling FOO.BAS; FOO.EXE could be an executable program produced by loading FOO.OBJ, and so forth. .EXE and .COM are the normal suffixes for executable programs. MS-DOS allows a group of files to be specified in a single file specification by including the special "wildcard" characters, "*" and "?". A "*" matches any string of characters from the current position to the end of the field, includ- ing no characters at all; a "?" matches any single character. Here are some examples: *.BAS All files of type BAS (BASIC source files) in the current directory. FOO.* Files of all types with name FOO. F*.* All files whose names start with F. *.? All files whose types are exactly one character long, or have no type at all. Wildcard notation is used on many computer systems in similar ways, and it is the mechanism most commonly used to instruct Kermit to send a group of files. Users of Kermit-MS should bear in mind that other (non-MS-DOS) systems may use different wildcard characters. For instance VMS and the DEC-20 use "%" instead of "?" as the single character wildcard; when using Kermit-MS to request a wildcard file group from a Kermit-20 server, the DOS "?" must be replaced by the DEC-20 "%". 1.4.2. File Formats MS-DOS systems store files as bulk collections of 8-bit bytes, with no par- ticular distinction among text, program code, and binary files. ASCII text files consist of lines separated by carriage-return-linefeed sequences (CRLFs), and this conforms exactly to the way Kermit represents text files during trans- mission. Since a non-MS-DOS receiving system might need to make distinctions as to file type, you may need to use various SET functions on the remote system to inform it that the incoming file is of some particular (non-default) type, such as binary. In transmitting files between Kermit-MS programs, regardless of file contents, the receiving MS-DOS system is equally capable of processing text, code, and data, and in fact requires no knowledge of how the bytes in the file are to be used. Unlike most other Kermit programs, MS-DOS Kermit does not require a command like SET FILE TYPE BINARY to switch from text to binary file transfer. But the Kermit on the other end of the connection probably does! MS-DOS (unlike CP/M) is capable of pinpointing the end of file with precision by keeping a byte count in the directory, so one would expect no particular confusion in this regard. However, certain MS-DOS programs continue to use the CP/M convention of terminating a text file with a Control-Z character, and won't operate correctly unless this terminating byte is present. Therefore, you should be aware of a special SET EOF option for both incoming and outbound files, described later. Non-MS-DOS systems may be confused by nonstandard ASCII files sent by Kermit-MS: - Files containing any of the 8-bit "extended ASCII" characters will probably need conversion (or translation) to 7-bit ASCII. - Files produced by word processing programs like Word Perfect or Word Star may contain special binary formatting codes, and could need con- version to conventional 7-bit ASCII format prior to transmission, using commonly available "exporter" programs. - Files created by word processors that store formatting data at the end of the file, after the Control-Z and before physical end, may re- quire special processing via SET EOF to strip the formatting data, lest it confuse non-MS-DOS recipients. - Spreadsheet or database files usually need special formatting to be meaningful to non-MS-DOS recipients (though they can be transmitted between MS-DOS systems with Kermit-MS). - BASIC programs are normally saved in a binary "tokenized" form. Use BASIC's ",a" SAVE option to save them as regular ASCII text, as in save"foofa",a 1.5. Program Invocation Kermit-MS can be run interactively, from a batch file, or as an "external" DOS command. Commands consist of one or more fields, separated by "whitespace" -- one or more spaces or tabs. Kermit-MS also returns the errorlevel parameter for batch file tests. Upon initial startup, the program executes any commands found in the file MSKERMIT.INI in the current path. This initialization file may contain command macro definitions, communications settings for one or more ports, or any other Kermit-MS commands. Here is a sample MSKERMIT.INI file: comment -- MSKERMIT.INI, MS-DOS Kermit initialization file comment -- Don't overwrite my files! set warning on comment -- Define macros for the systems I use... define unix set local-echo off,set par non,set flow xon,set timer off def ibm set par odd,set loc on,set hands xon,set flo none,set tim on def modem set port 2, set baud 1200 comment -- Define a macro for quickly adapting to noisy connections... def noisy set block-check 3, set send packet-length 40, set retry 20 comment -- I always start out by connecting to my UNIX system... set port 1 set baud 4800 do unix connect The meanings of these commands will emerge below. For now, just note how you can use command files (and "macro definitions") to easily adapt MS-Kermit to widely differing communication environments. A more advanced initialization file is shown below in section 1.8. Interactive Operation: To run Kermit-MS interactively, invoke the program from DOS command level by typing its name, normally "kermit" (this means the program should be stored in your path with the name KERMIT.EXE). When you see the program's prompt, Kermit-MS> you may type Kermit commands repeatedly until you are ready to exit the program, as in the following example (which assumes there's already a Kermit "server" set up on the other end): A> A>kermit IBM PC Kermit-MS V2.30 Type ? for help Kermit-MS>set speed 19200 Kermit-MS>send foo.* The files are sent. Kermit-MS>get bar.* The requested files are received. Kermit-MS>exit A> A command keyword, such as SEND, RECEIVE, HELP, etc, may be abbreviated, so long as you have typed enough letters to distinguish it from other keywords that are valid in that position. For instance, you can type CLE for CLEAR and CLO for CLOSE. Several common commands even have special non-unique abbrevia- tions, like C for CONNECT, S for SEND, and R for RECEIVE. During interactive operation, you may edit the command you're currently typing using BACKSPACE to erase the character most recently typed, Ctrl-W to delete the most recent field, or Ctrl-U to delete the entire command. The editing characters may be used in any combination until the command is finally entered by typing RETURN (Carriage Return, Enter) or Ctrl-L. You may use the help ("?") and keyword completion (ESC) features freely while typing Kermit-MS commands. A question mark typed at almost any point in a com- mand produces a brief description, or "menu", of what is expected or possible at that point. ESC typed at any point, except in a local filename, will cause the current field to be filled out if what you have typed so far is sufficient to identify it, and will leave you in position to type the next field (or to type a "?" to find out what the next field is); otherwise, the program will beep at you and wait for you to type more characters. Kermit-MS recognizes only 7-bit ASCII characters when examining a Kermit com- mand line. Therefore, you can't normally enter special characters like car- riage return, backspace, ESC, question mark, or Ctrl-U as part of the command's text, nor can you enter 8-bit codes. To get around this restriction, a special notation is provided for including these characters in commands, called "backslash numeric form". The character is entered as a backslash ("\") fol- lowed by a number corresponding to the ASCII code for the character: \123 a decimal number (decimal is the default number base) \d249 a decimal number (also \D) \o177 an octal number (also \O) \x0d a hexadecimal number (also \X) Table 1-1 shows all of the 7-bit ASCII codes. Most Kermit commands understand these codes, both imbedded within character strings, and alone, as when a single character or number is to be specified. ------------------------------------------------------------------------------- Dec Name Ctrl Dec Char Dec Char Dec Char 0 NUL ^@ | 32 SP | 64 @ | 96 ` 1 SOH ^A | 33 ! | 65 A | 97 a 2 STX ^B | 34 " | 66 B | 98 b 3 ETX ^C | 35 # | 67 C | 99 c 4 EOT ^D | 36 $ | 68 D | 100 d 5 ENQ ^E | 37 % | 69 E | 101 e 6 ACK ^F | 38 & | 70 F | 102 f 7 BEL ^G beep | 39 ' | 71 G | 103 g 8 BS ^H backspace | 40 ( | 72 H | 104 h 9 HT ^I tab | 41 ) | 73 I | 105 i 10 LF ^J linefeed | 42 * | 74 J | 106 j 11 VT ^K | 43 + | 75 K | 107 k 12 FF ^L formfeed | 44 , | 76 L | 108 l 13 CR ^M return | 45 - | 77 M | 109 m 14 SO ^N shift out | 46 . | 78 N | 110 n 15 SI ^O shift in | 47 / | 79 O | 111 o 16 DLE ^P | 48 0 | 80 P | 112 p 17 DC1 ^Q XON | 49 1 | 81 Q | 113 q 18 DC2 ^R | 50 2 | 82 R | 114 r 19 DC3 ^S XOFF | 51 3 | 83 S | 115 s 20 DC4 ^T | 52 4 | 84 T | 116 t 21 NAK ^U | 53 5 | 85 U | 117 u 23 ETB ^W | 54 6 | 86 V | 118 v 22 SYN ^V | 55 7 | 87 W | 119 w 24 CAN ^X | 56 8 | 88 X | 120 x 25 EM ^Y | 57 9 | 89 Y | 121 y 26 SUB ^Z | 58 : | 90 Z | 122 z 27 ESC ^[ escape | 59 ; | 91 [ | 123 { 28 FS ^\ | 60 < | 92 \ | 124 | 29 GS ^] | 61 = | 93 ] | 125 } 30 RS ^^ | 62 > | 94 ^ | 126 ~ 31 US ^_ | 63 ? | 95 _ | 127 RUBOUT,DELETE Table 1-1: The US ASCII Character Set (ANSI X3.4-1977) ------------------------------------------------------------------------------- Some Kermit-MS commands like GET, SHOW KEY, and SET KEY, may prompt for ad- ditional information on subsequent lines. If you have reached one of these prompts and then wish to cancel the command, you may type Control-C. Summary of Kermit-MS command editing characters: SPACE Separates fields within the command. TAB Same as Space, and echoes as Space. You may also use Ctrl-I for Tab. BACKSPACE Deletes the character most recently typed. May be typed repeatedly to delete all the way back to the prompt. You may also use DELETE, RUBOUT, Ctrl-H, or equivalent keys. Ctrl-W Deletes the most recent "word", or field, on the command line. May be typed repeatedly. Ctrl-U Deletes the entire command line, back to the prompt. Ctrl-C Cancels the current command and returns to the "Kermit-MS>" prompt. Also, terminates execution of a TAKE command file. ESC If enough characters have been supplied in the current keyword to identify it uniquely the remainder of the field is supplied and the cursor is positioned to the next field of the command. Otherwise, a beep is sounded. ESC does not provide filename completion in version 2.30. ? Displays a brief message describing what may be typed in the cur- rent command field. Also, wildcard character for matching any single character in all but the first position of a filename. # Wildcard character for matching single characters in filenames. Equivalent to MS-DOS "?", but used in the first position of a filename only, so that "?" may be used to get help at the beginning of a filename field. RETURN Enters the command. On most keyboards, you may also use ENTER or Ctrl-M. Ctrl-L Clears the screen and enters the command. Liberal use of "?" allows you to feel your way through the commands and their fields. This feature is sometimes called "menu on demand" or "context sen- sitive help" -- unlike systems that force you to negotiate menus at every turn, menu-on-demand provides help only when it is needed. Command parsing is done through DOS calls. Kermit key redefinition does not apply at MS-Kermit command level. But ANSI.SYS or other external console drivers can be used for this purpose, for instance to assign ESC to the PC's backquote key (ANSI.SYS is the IBM-supplied extended screen and keyboard device driver, described in the IBM DOS Technical Reference Manual). Other console drivers available include ProKey, SuperKey, NANSI.SYS (a public-domain replace- ment for ANSI.SYS), and FANSICONSOLE. Command Line Invocation: Kermit-MS may also be invoked with command line arguments from DOS command level, for instance: A>kermit send foo.bar or A>kermit set port 1, set baud 9600, connect In this case, help and completion are not available (because the program that provides them won't start running until after you type the entire command line), and Kermit-MS will exit back to DOS after completing the specified com- mand or commands. Therefore, when invoked with command line arguments, Kermit-MS will behave as if it were an external DOS command, like MODE. Note that several commands may be given on the command line, separated by commas. This can't be done interactively or from TAKE command files. Batch Operation: Like other MS-DOS programs, Kermit-MS may be operated under batch with command line arguments. If you invoke it without command line arguments, it will run interactively, reading commands from the keyboard and not the batch file. When it exits, batch processing will continue to the end of the batch file. Kermit-MS returns the "errorlevel" parameter used as program exit status. Present values are in the range 0 to 7 with three areas yielding success or failure reports for the entire Kermit session. The errorlevel values are: errorlevel Kermit session status 0 entirely successful operation 1 a Send command completed unsuccessfully 2 a Receive or GET command completed unsuccessfully 4 a REMOTE command completed unsuccessfully 3,5,6,7 combinations (addition) of the above conditions Note that failures are remembered for the whole session and are not canceled by a following successful operation of the same type. Thus, sending several files individually yields an errorlevel of 0 only if all the files were sent success- fully. Remote Operation: The MS-DOS CTTY command allows an MS-DOS system to be used from a terminal con- nected to its communication port. Such sessions must be conducted with great care, since many programs assume that they are running on the real console, and explicitly reference screen memory or keyboard scan codes. Kermit can be used in this manner too, but before you give it any file transfer commands, you must inform it that it is running in "remote mode" rather than its normal "local mode." Use the SET REMOTE ON command for this purpose, to prevent the file transfer display from being sent out the port. @@@@@@@@@@@@@@@@@@@@ Cut and concatenate here. @@@@@@@@@@@@@@@@@@@@ -- Tom Reingold INTERNET: tr@bellcore.bellcore.com Bell Communications Research UUCP: rutgers!bellcore!tr 435 South St room 2L350 SOUNDNET: (201) 829-4622 [work] Morristown, NJ 07960 (201) 287-2345 [home]