|
The Kermit Project |
Now hosted by
Panix.com
New York City USA •
kermit@kermitproject.org
| ||||||||
|
As of:
C-Kermit 9.0.300, 30 June 2011
This page last updated:
Fri Apr 12 11:21:17 2013
(New York USA Time)
IF YOU ARE READING A PLAIN-TEXT version of this document, it is a plain-text dump of a Web page. You can visit the original (and possibly more up-to-date) Web page here:
http://www.kermitproject.org/ckcbwr.html
This document contains platform-independent C-Kermit hints and tips. Also see the platform-specific C-Kermit hints and tips document for your platform, for example:
http://www.kermitproject.org/ckubwr.html
for Unix. This document also applies to Kermit 95 for Windows, which is based on C-Kermit.
0. PATCHES 1. INCOMPATIBLE CHANGES 2. THE C-KERMIT COMMAND PARSER 3. MULTIPLE SESSIONS 4. NETWORK CONNECTIONS 5. MODEMS AND DIALING 6. DIALING HINTS AND TIPS 7. TERMINAL SERVERS 8. TERMINAL EMULATION 9. KEY MAPPING 10. FILE TRANSFER 11. SCRIPT PROGRAMMING
Source-level patches for C-Kermit 9.0:
(None)
These are not necessarily exhaustive lists.
get remote-name local-name get /as-name:local-name remote-name
If either name contains spaces, enclose it in braces (or, in C-Kermit 8.0 or later, doublequotes).
mget file1 file2 file3 ...
cd \v(dir)data.tmp
to work across platforms that might have different directory notation, such as UNIX, Windows, and VMS.
Since most standard 8-bit character sets have control characters in positions 128-160, it might have made sense to keep 128-160 in the break set, but with the proliferation of Microsoft Windows code pages, there is no telling which 8-bit character is likely to be some kind of text, e.g. “smart quotes” or East European or Turkish accented letters.
Various command-related limits are shown in the following table, in which the sample values are for a "large memory model" build of C-Kermit, typical for modern platforms (Linux, Solaris, AIX, VMS, etc). You can see the values for your version of Kermit by giving the SHOW FEATURES command. The maximum length for a Kermit command (CMDBL) also determines the maximum length for a macro definition, since DEFINE is itself a command. The maximum length for a variable name is between 256 and 4096 characters, depending on the platform; for array declarations and references, that includes the subscript.
Item Symbol Sample
ValueDefinition Number of characters in a command CMDBL 32763 ckucmd.h Number of chars in a field of a command ATMBL 10238 ckucmd.h Nesting level for command files MAXTAKE 54 ckuusr.h Nesting level for macros MACLEVEL 128 ckuusr.h Nesting level for FOR / WHILE loops FORDEPTH 32 ckuusr.h Number of macros MAC_MAX 16384 ckuusr.h Size of INPUT buffer INPBUFSIZ 4096 ckuusr.h Maximum files to match a wildcard MAXWLD 102400 ckcdeb.h Filespecs in MSEND command MSENDMAX 1024 ckuusr.h Length for GOTO target label LBLSIZ 50 ckuusr.h \fexecute() recursion depth limit CMDDEP 64 ckucmd.h
If you need to define a macro that is longer than CMDBL, you can break the macro up into sub-macros or rewrite the macro as a command file. In a pinch you can also redefine CMDBL and recompile C-Kermit. All of these numbers represent tradeoffs: the bigger the number, the more "powerful" Kermit in the corresponding area, but also the bigger the program image and possibly disk footprint, and the longer it takes to load and initialize.
In the interactive command parser:
If you interrupt C-Kermit before it has issued its first prompt, it will exit. This means that you cannot interrupt execution of the initialization file, or of an "application file" (file whose name is given as the first command-line argument), or of an alternative initialization file ("-y filename"), and get to the prompt. There is, however, one exception to this rule: you *can* interrupt commands -- including TAKE commands -- given in the '-C "command list"' command-line argument and -- if there were no action commands among the command-line arguments -- you will be returned to the C-Kermit prompt. So, for example, if you want to start C-Kermit in such a way that it executes a command file before issuing its first prompt, and you also want to be able to interrupt the command file and get to the prompt, include a TAKE command for the desired command in the -C argument, for example:
kermit -C "take dial.scr"
At the command prompt, if you use the backslash (\) prefix to enter a control character, space, or question mark into a command literally, the backslash disappears and is replaced by the quoted character. If it was a control character, it is shown as a circumflex (^). This allows editing (backspace, delete, Ctrl-W) to work correctly even for control characters.
Priot to C-Kermit 8.0, the only way to include a comma literally in a macro definition -- as opposed to having it separate commands within the definition -- is to enter its ASCII value (44) in backslash notation, e.g.:
DEFINE ROWS RUN MODE CO80\{44}\%1
In C-Kermit 8.0 you can use constructions like this:
DEFINE ROWS RUN MODE "CO80,\%1"
If you quote special characters in a filename (e.g. in the SEND command), filename completion may seem to work incorrectly. For example, if you have a file whose name is a*b (the name really contains an asterisk), and you type "send a\\*<ESC>", the "b" does not appear, nor will Ctrl-R redisplay the completed name correctly. But internally the file name is recognized anyway.
Question-mark help does not work during execution of an ASKQ command. The question marks are simply accepted as text.
In OUTPUT commands only, \B sends a BREAK signal, \L sends a Long BREAK signal, and \N sends a NUL (ASCII 0). BREAK and Long BREAK are special signals, not characters, and NUL is a character that normally cannot be included in a C string, since it is the C string terminator. If you really want to output a backslash followed by a B, an L, or an N (as is needed to configure certain modems, etc), double the backslash, e.g. "output \\B". In C-Kermit 7.0 or later, you can disarm and re-arm the special OUTPUT-command escapes (\B, \L, and \N) with SET OUTPUT SPECIAL-ESCAPES { OFF, ON }.
When using the command-line processor ("kermit -l /dev/tty00 -b 19200", etc), note that in some cases the order of the command-line options makes a difference, contrary to the expectation that order of command-line options should not matter. For example, the -b option must be given after the -l option if it is to affect the device specified in the -l option.
C-Kermit 7.0 and earlier do not support multiple sessions. When you SET LINE (or SET PORT, same thing) to a new device, or SET HOST to a new host, the previous SET LINE device or network host connection is closed, resulting in hangup of the modem or termination of the network connection. In windowing environments like HP-VUE, NeXTSTEP, Windows, OS/2, etc, you can run separate copies of Kermit in different windows to achieve multiple sessions.
To achieve multiple sessions through a single serial port (e.g. when dialing up), you can install SLIP or PPP on your computer and then use C-Kermit's TCP/IP support over the SLIP or PPP connection, assuming you also have TCP/IP networking installed on your computer.
C-Kermit 8.0 has the same restriction on SET LINE and SET HOST sessions: only one regular session (dialout, Telnet, etc) can be open at a time. However, version 8.0 adds two new kinds of sessions: FTP and HTTP; one or both of these can be open at the same as a regular session.
These two bugs are fixed in the source code that is included on the CDROM, and also in Kermit 95 2.1.1. You can tell if a C-Kermit 8.0.206 binary has these fixes by typing SHOW VERSION; if it says "FTP Client, 8.0.200, 24 Oct 2002" it has the fixes; if the edit number is less that 200, it doesn't, in which case can build a new binary from the source code (or contact us and we'll try to get get one for you).
If echoing does not work right after connecting to a network host or after dialing through a TCP/IP modem server, it probably means that the TELNET server on the far end of the connection is executing the TELNET protocol incorrectly. After initially connecting and discovering incorrect echoing (characters are echoed twice, or not at all), escape back, give the appropriate SET DUPLEX command (FULL or HALF), and then CONNECT again. For a consistently misbehaving connection, you can automate this process in a macro or TAKE file.
TELNET sessions are treated just like serial communications sessions as far as "terminal bytesize" and "command bytesize" are concerned. If you need to view and/or enter 8-bit characters during a TELNET session, you must tell C-Kermit to SET TERMINAL BYTESIZE 8, SET COMMAND BYTESIZE 8, and SET PARITY NONE.
If you SET TELNET DEBUG ON prior to making a connection, protocol negotiations will be displayed on your screen. You can also capture them in the debug log (along with everything else) and then extract them easily, since all Telnet negotiations lines begin with (uppercase) "TELNET".
If you tell Kermit to make a Telnet connection to a service whose Telnet server does not implement Telnet protocol correctly, the connection might fail as follows:
Negotiations............................... The Telnet server is not sending required responses.
A common case where this occurs is with Telnetable BBSs such Synchronet, which (April 2013 and earlier) in its Telnet features negotiations indicates that it supports the RFC2840 Telnet Kermit Option when it does not. Solution: tell Kermit to:
SET TELOPT KERMIT REFUSE REFUSE
The same applies to any other Telnet option; HELP SET TELOPT for details. You can use SET TELNET DEBUG ON to watch the negotiations.
In the more general case, you can also tell C-Kermit not to wait for any and all unanswered Telnet protocol negotiations before proceeding with the connection as follows:
SET TELNET WAIT OFF
This should be needed only for seriously misconfigured Telnet servers. HELP SET TELNET for further information.
External modems are recommended because:
Modems can be used by C-Kermit only when they are visible as or through a regular serial port device. Certain modems can not be used in this normal way on many kinds of computers: Winmodems, RPI modems, Controllerless modems, the IBM Mwave, etc; all of these require special drivers that perform some, most, or all of the modem's functions in software. Such drivers are generally NOT available in UNIX or other non-Windows (or non-OS/2, in the case of the Mwave) platforms.
In order to dial a modem, C-Kermit must know the modem's repertoire of commands and responses. Each modem make and model is likely to have a different repertoire. Since Kermit has no way of knowing which kind of modem will be dialed, normally you have to tell it with a SET MODEM TYPE command, e.g.:
set modem type usrobotics set line /dev/cua0 set speed 57600 dial 7654321
In the early days, there was a wide variety of modems and command languages. Nowadays, almost every modem uses the Hayes AT command set (but with some differences in the details) and its startup configuration includes error correction, data compression, and hardware (RTS/CTS) flow control. As long as C-Kermit is capable of hardware flow control (as it is on many, but not all, the platforms where it runs, since some operating systems don't support it), the modem can be dialed immediately, without lengthy configuration dialogs, and in fact this is what SET MODEM TYPE GENERIC-HIGH-SPEED does. In C-Kermit 8.0, GENERIC-HIGH-SPEED has become the default modem type, so now it is usually possible to SET LINE, SET SPEED, and DIAL without having to identify your modem. If this doesn't work, of course, then you might have to fall back to the traditional method: Give a SET MODEM TYPE for a specific modem first, then SET LINE, SET SPEED, and DIAL.
An important change in C-Kermit 6.0 is that when you give a SET MODEM TYPE command to tell Kermit what kind of modem you have, Kermit also sets a number of other modem-related parameters automatically from its internal modem database. Thus, the order in which you give modem-related commands is significant, whereas in prior releases they could be given in any order.
In particular, MODEM SPEED-MATCHING is set according to whether the modem is known to be capable of speed buffering. SET MODEM TYPE HAYES-2400 automatically turns SPEED-MATCHING ON, because when the Hayes 2400 reports a particular speed in its CONNECT message, that means its interface speed has changed to that speed, and C-Kermit's must change accordingly if it is to continue communicating. This might cause some confusion if you use "set modem type hayes" for dialing a more advanced type of modem.
The new default for flow control is "auto", meaning "do the right thing for each type of connection". So (for example) if your version of C-Kermit supports SET FLOW RTS/CTS and your modem also supports RTS/CTS, then Kermit automatically sets its flow control to RTS/CTS and set modem's flow control to RTS/CTS too before attempting to use the modem.
For these reasons, don't assume that "set modem type hayes" should be used for all modems that uses the Hayes AT command set. "set modem type hayes" really does mean Hayes 1200 or 2400, which in turn means no hardware flow control, and no speed buffering. This choice will rarely work with a modern high-speed modem.
If you have a high-speed, error-correcting, data-compressing, speed-buffering modem, you should fix the modem's interface speed as high as possible, preferably (at least) four times higher than its maximum connection (modulation) speed to allow compression to work at full advantage. In this type of setup, you must also have an effective means of flow control enabled between C-Kermit and the modem, preferably hardware (RTS/CTS) flow control. On platforms that do not support hardware flow control, it is usually possible to select software flow control (Xon/Xoff), and C-Kermit will do its best to set the modem for local Xon/Xoff flow control too (but then, of course, Ctrl-S and Ctrl-Q characters can not be transmitted on the connection).
If you are having trouble dialing your modem, SET DIAL DISPLAY ON to watch the dialing interactions between C-Kermit and your modem. Consult Chapters 3-4 of Using C-Kermit (2nd Ed) for modem-dialing troubleshooting instructions. The following sections offer some additional hints and tips.
C-Kermit>dial #98765421-1-212-5551212 ; Looks like a comment ?You must specify a number to dial C-Kermit>dial \#98765421-1-212-5551212 ; Works OK C-Kermit>dial =#98765421-1-212-5551212 ; This works too
When using a dialing directory, remember what happens if a name is not found:
C-Kermit>dial xyzcorp Lookup: "xyzcorp" - not found - dialing as given
This normally does no harm, but some modems might behave strangely when given dial strings that contain certain letters. For example, a certain German modem treats any dial string that contains the letter "s" as a command to fetch a number from its internal list, and replies OK to the ATD command, which is normally not a valid response except for partial dialing. To avoid this situation, use:
lookup xyzcorp if success dial
SET CARRIER-WATCH OFF
This is because (in these implementations), the CONNECT command requires the modem's Carrier Detect (CD) signal to be on, but the CD signal doesn't come on until after dialing is complete. This requirement is what allows C-Kermit to pop back to its prompt automatically when the connection is hung up. See the description of SET CARRIER-WATCH in "Using C-Kermit".
Similarly, if your dialed connection drops when CARRIER-WATCH is set to AUTO or ON, you can't CONNECT back to the (now disconnected) screen to see what might have happened unless you first SET CARRIER-WATCH OFF. But sometimes not even SET CARRIER-WATCH OFF will help in this situation: certain platforms (for example Unixware 2.1), once carrier drops, won't let the application do i/o with the device any more. In that case, if you want to use the device again, you have to CLOSE it and OPEN it again. Or you can have Kermit do this for you automatically by telling it to SET CLOSE-ON-DISCONNECT ON.
Most modern modems support RTS/CTS (if they support any hardware flow control at all), but some computers use different RS-232 circuits for the same purposes, e.g. DTR and CD, or DTR and CTS. In such cases, you might be able to make your computer work with your modem by appropriately cross-wiring the circuits in the cable connector, for example the computer's DTR to the modem's RTS, and modem's CD to the computer's CTS. HOWEVER, C-Kermit does not know you have done this. So if you have (say) SET FLOW DTR/CD, C-Kermit will make no attempt to tell the modem to use RTS/CTS. You probably did this yourself when you configured the modem.
+++ATH0
if sent through a TIES modem, for example because you were uploading this file through it, could pop the modem back into command mode and make it hang up the connection. Later versions of the Telebit T1600 and T3000 (version LA3.01E firmware and later), and all WorldBlazers, use TIES.
Although the probability of "+++" appearing in a Kermit packet is markedly lower than with most other protocols (see the File Transfer section below), it can still happen under certain circumstances. It can also happen when using C-Kermit's TRANSMIT command. If you are using a Telebit TIES modem, you can change the modem's escape sequence to an otherwise little-used control character such as Ctrl-_ (Control-Underscore):
AT S2=31
A sequence of three consecutive Ctrl-_ characters will not appear in a Kermit packet unless you go to extraordinary lengths to defeat more than a few of Kermit's built-in safety mechanisms. And if you do this, then you should also turn off the modem's escape-sequence recognition altogether:
AT S48=0 S2=255
But when escape sequence recognition is turned off, "modem hangup" (<pause>+++<pause>ATH0<CR>) will not work, so you should also SET MODEM HANGUP RS232-SIGNAL (rather then MODEM-COMMAND).
SET PBX-OUTSIDE-PREFIX 9W
(replace "9" with whatever your PBX's outside-line prefix is).
The HANGUP command has no effect when C-Kermit is in remote mode. This is on purpose. If C-Kermit could hang up its own controlling terminal, this would (a) most likely leave behind zombie processes, and (b) pose a security risk.
If you DIAL a modem, disconnect, then SET HOST or TELNET, and then HANGUP, Kermit sends the modem's hangup command, such as "+++ATHO". There is no good way to avoid this, because this case can't reliably be distinguished from the case in which the user does SET HOST terminal-server, SET MODEM TYPE name, DIAL. In both cases we have a valid modem type selected and we have a network connection. If you want to DIAL and then later make a regular network connection, you will have to SET MODEM TYPE NONE or SET DIAL HANGUP OFF to avoid this phenomenon.
Watch out for terminal server's escape character -- usually a control character such as Ctrl-Circumflex (Ctrl-^). Don't unprefix it in Kermit!
Ciscos -- must often be told to "terminal download"... Cisco ASM models don't have hardware flow control in both directions.
Many terminal servers only give you a 7-bit connection, so if you can't make it 8-bit, tell Kermit to "set parity space".
The following story, regarding trouble transferring 8-bit files through a reverse terminal server, was contributed by an Annex terminal server user:
Using C-Kermit on an HP 9000 712/80 running the HP-UX 10.00 operating system. The HP was connected to a Xylogics Annex MICRO-ELS-UX R7.1 8 port terminal server via ethernet. On the second port of the terminal server is an AT&T Paradyne 3810 modem, which is connected to a telephone line. There is a program which runs on the HP to establish a Telnet connection between a serial line on the Annex and a character special file on the HP (/dev file). This is an Annex specific program called rtelnet (reverse telnet) and is provided with the terminal server software. The rtelnet utility runs on top of the pseudo-terminal facility provided by UNIX. It creates host-originated connections to devices attached ot Annex serial ports. There are several command line arguments to be specified with this program: the IP address of the terminal server, the number of the port to attach to, and the name of the pseudo-device to create. In addition to these there are options to tell rtelnet how to operate on the connect: -b requests negotiation for Telnet binary mode, -d turns on socket-leve debugging, -f enables "connect on the fly" mode, -r removes the device-name if it already exists, etc. The most important of these to be specified when using 8 data bits and no parity, as we found out, was the -t option. This creates a transparent TCP connection to the terminal server. Again, what we assumed to be happening was that the rtelnet program encountered a character sequence special to itself and then "eating" those kermit packets. I think this is all of the information I can give you on the configuration, short of the values associated with the port on the terminal server.How to DIAL from a TCP/IP reverse terminal server (modem server):
The order is important: SET HOST before SET MODEM TYPE. Since this is a Telnet connection, serial-port related commands such as SET SPEED, SET STOP-BITS, HANGUP (when MODEM HANGUP-METHOD is RS232), etc, have no effect. However, in C-Kermit 8.0, if the modem server supports RFC-2217 Telnet Com-Port Control protocol, these commands do indeed take effect at the server's serial port.
Except for the Windows, OS/2, and Macintosh versions, C-Kermit does not emulate any kind of terminal. Rather, it acts as a "semitransparent pipe", passing the characters you type during a CONNECT session to the remote host, and sending the characters received from the remote host to your screen. Whatever is controlling your keyboard and screen provides the specific terminal emulation: a real terminal, a PC running a terminal emulator, etc, or (in the case of a self-contained workstation) your console driver, a terminal window, xterm, etc.
Kermit is semitransparent rather than fully transparent in the following ways:
You can make C-Kermit fully transparent by starting it with the -0 (dash zero) command-line option.
If you are running C-Kermit under a console driver, or in a terminal window, that emulates the VT100, and use C-Kermit to log in to a VMS system, the console driver or terminal window (not Kermit) is supposed to reply to the "what are you?" query (ESC Z) from the VAX. If it doesn't, and you can't make it do so, then you can (a) live with the "unknown terminal" problem; (b) tell VMS to SET TERMINAL/DEVICE=VT100; (c) program a key using SET KEY to send the appropriate sequence and then punch the key at the right time; or (d) use the VMSLOGIN macro that is defined in CKERMIT.INI to do this for you automatically.
SET SESSION-LOG { TEXT, BINARY }, which is effective in UNIX and AOS/VS but not other C-Kermit versions, removes CR, DEL, NUL, XON, and XOFF characters (Using C-Kermit neglects to mention that XON and XOFF are removed). The TEXT-mode setting is ineffective during SCRIPT command execution, as well as on X.25 connections.
Except in the terminal-emulating versions, C-Kermit's key mapping facilities are limited to normal "ASCII" keys, and cannot be used with function keys, arrow keys, arcane key combinations, etc. Since C-Kermit runs on such a wide variety of hardware platforms (including, for example, more than 360 different UNIX platforms), it is not possible for C-Kermit to support every conceivable keyboard under every release of every UNIX (or VMS, or ...) product on every different kind of computer possibly under all manner of different console drivers, even if it had the means to do so.
In technical terms, C-Kermit uses the read() function to read keystrokes, and read() returns a single byte (value 0 through 255). C-Kermit's SET KEY function applies to these single-byte codes. "Extended function" keys, such as F-keys, arrow keys, etc, usually return either a 2-byte "scan code" or else a character string (such as an escape sequence like "<ESC> O p"). In both cases, C-Kermit has no way to tell the difference between such multibyte key values, and the corresponding series of single-byte key values. This could only be done by accessing the keyboard at a much lower level in a highly platform-dependent manner, probably requiring tens of thousands of lines of code to support even a sampling of the most popular workstation / OS combinations.
However, most workstation console drivers (terminal emulation windows, etc) include their own key-mapping facility. For example in AIX, the AIXterm program (in whose window you would run C-Kermit) allows rebinding of the F1-F12 keys to arbitrary strings. The same is true of Xterm and DECterm windows, etc. Consult the technical documentation for your workstation or emulator. See sample Xterm (Xmodmap) mappings in the Unix C-Kermit Hints and Tips document.
The SET KEY command (except in Kermit 95) does not allow a key definition to be (or contain) the NUL (\0) character.
C-Kermit 7.0 is the first release of C-Kermit to use fast (rather than robust and therefore slow) protocol defaults: long packets, sliding windows, control-character unprefixing, and streaming where possible. This makes most transfers (partner willing) dramatically faster "out of the box" but might break some combinations that worked before. If transfers with C-Kermit 7.0 or later fail where transfers worked with earlier C-Kermit versions, try the following (one at a time, in this order):
Execution of multiple file transfers by C-Kermit from a command file when in remote mode might exhibit long delays between each transfer. To avoid this, just include the command "SET DELAY 0" in your command file before any of the file-transfer commands.
File transfer failures can occur for all sorts of reasons, most of them listed in Chapter 10 of Using C-Kermit. The following sections touch on some that aren't.
The C-Kermit 7.0 Release Notes document SEND /COMMAND as taking an argument, but it doesn't. Instead of SEND /COMMAND:{some command}, use:
SEND /COMMAND [ other switches such as /AS-NAME: ] command [ arguments... ]
SET FILE COLLISION UPDATE depends on the date/time stamp in the attribute packet. However, this is recorded in local time, not Universal Time (GMT), and there is no indication of time zone. The time is expressed to the precision of 1 second, but some file systems do not record with this precision -- for example, MS-DOS records the file date/time only to the nearest 2 seconds. This might cause update operations to send more files than necessary.
(This paragraph does NOT apply to UNIX, where, as of C-Kermit 7.0, C-Kermit pipes incoming mail and print material directly to the mail or print program): When C-Kermit is receiving files from another Kermit program that has been given the MAIL or REMOTE PRINT command, C-Kermit follows the current filename collision action. This can be disconcerting if the action was (for example) BACKUP, because the existing file will be renamed, and the new file will be mailed (or printed) and then deleted. Kermit cannot temporarily change to RENAME because the file collision action occurs when the filename packet is received, and the PRINT or MAIL disposition only comes later, in the Attribute packet.
Watch out for SET FILE COLLISION RENAME, especially when used in conjunction with recovery. Recall that this option (which is NOT the default) renames the incoming file if a file already exists with the same name (the default is to rename the previously existing file, and store the incoming file with its own name). It is strongly recommended that you do not use SET FILE COLLISION RENAME if you ever intend to use the recovery feature:
Also watch out for DISABLE DELETE, since this implicitly sets FILE COLLISION to RENAME. And note tht DELETE is DISABLEd automatically any time you Kermit is in local mode (i.e. it makes a connection). Also note that for purposes of DISABLE and ENABLE, "set host *" connections do not count as local mode even though, strictly speaking, they are.
C-Kermit>get c:\\directory\\foo.txt
This is because backslash is used in C-Kermit commands for introducing special character codes, variables, functions, etc.
If you cancel a transfer that is underway using X or Z, and a lot of window slots are in use, it might take a while for the cancellation to take effect, especially if you do this on the receiving end; that's because a lot of packets might already be on their way to you. In that case, just be patient and let Kermit "drain" them.
If C-Kermit is sending a file, remote-mode packet-mode breakout (three consecutive Ctrl-C's by default) is not effective until after C-Kermit sends its first packet. If C-Kermit is receiving a file or is in server mode, it is effective right away. In the former case, the SET DELAY value determines the earliest time at which you can break out of packet mode.
mapchan -n
to disable character-set conversion by the terminal driver. Similarly for AIX:
setmaps -t NOMAP
When using C-Kermit to transfer files with the HP48SX calculator, you must SET FLOW NONE. The HP48SX does not support flow control, and evidently also becomes confused if you attempt to use it. You might also need to use SET SEND PAUSE 100 (or other number). For greater detail about transferring files the HP-48, see:
http://www.kermitproject.org/hp48.html
Some communication programs have errors in their implementation of Kermit attribute packets. If you get an error message from your communication program like "Attribute error", tell C-Kermit to SET ATTRIBUTES OFF. Better yet, switch to a real Kermit program.
Some communication software claims to implement Kermit sliding windows, but does so incorrectly. If sliding window transfers fail, set C-Kermit's window size to the smallest one that works, for example, SET WINDOW 1.
For lots more detail about how to cope with defective Kermit partners, see:
The UNIX version of C-Kermit discards carriage returns when receiving files in text mode. Thus, "bare" carriage returns (sometimes used to achieve overstriking) are lost.
INPUT 5 ; SCRIPT ~0 #--#--#
must be coded using backslash notation to keep the data from being ignored:
INPUT 5 \59 ; 59 is the decimal ASCII code for ";" SCRIPT ~0 \35--#--# ; 43 is the decimal ASCII code for "#"
or, more simply:
INPUT 5 \; ; Just quote the semicolon SCRIPT ~0 \#--#--# ; Just quote the "#"
echo In these brackets [\0] is a NUL
will echo "In these brackets [". This applies to ECHO, INPUT, OUTPUT, and all other commands (but you can represent NUL by "\N" in an OUTPUT string). This is because C-language strings are terminated internally by the NUL character, and it allows all of C-Kermit's string comparison and manipulation functions to work in the normal "C" way.
To illustrate:
INPUT 5 \0
is equivalent to:
INPUT 5
and:
INPUT 5 ABC\0DEF
is equivalent to:
INPUT 5 ABC
INPUT operations discard and ignore NUL characters that arrive from the communication device, meaning that they do not figure into matching operations (e.g. A<NUL>B matches AB); they are not deposited in the INPUT buffer (\v(input)); and they are not counted in \v(incount), with two exceptions:
Also, the \v(inchar) variable is null (completely empty) if the last INPUT character was NUL. That is, there is no way to tell only by looking at \v(inchar) the difference between a NUL that was INPUT and no INPUT at all. If the INPUT command succeeded but \v(inchar) is empty, then a NUL character was input. Also, \v(incount) will be set to 1.
Here's a sample script fragment to read characters, possibly including NUL, from the communication connection and write them to a file:
while true {
input 1 ; read one byte
if fail break ; timed out or connection closed
fwrite /char \%c \v(inchar) ; record the byte
}
This works because when \v(inchar) is NUL, that's equivalent to FWRITE /CHAR having no text argument at all, in which case it writes a NUL character.
\v(incount) and \v(inchar) are NOT affected by the CLEAR command.
for \%i 1 \ffiles(oofa.*) 1 {
send \fnextfile()
}
did not work as expected in C-Kermit 6.0 and earlier but does work in C-Kermit 7.0 and later.
CASE COUNT and \v(count) INPUT CASE INPUT TIMEOUT MACRO ERROR QUIET TAKE ERROR
This arrangement allows CASE, TIMEOUT, and ERROR settings, which are used to control automatic exit from a command file or macro upon error, to be automatically restored when the command file or macro exits.
The COUNT variable follows this rule too, which permits nested SET COUNT / IF COUNT loops, as in this example in which the inner loop counts down from the current COUNT value of the outer loop (try it):
DEFINE INNER WHILE COUNT { WRITE SCREEN { Inner:}, SHOW COUNT }
SET COUNT 5
WHILE COUNT { WRITE SCREEN Outer:, SHOW COUNT, DO INNER }
Keep in mind that an inferior command level cannot manipulate the COUNT value held by a higher level. For example:
DEFINE OOFA SHOW COUNT, IF COUNT GOTO LOOP SET COUNT 5 :LOOP OOFA ECHO Done
results in an infinite loop; the COUNT value remains at 5 because it is never decremented at the same level at which it was set.
define \%a ab{cd
echo \fsubstring(\%a)
ab{cd
If the string is to start with a leading brace and end with a closing brace, then double braces must appear around the string (which itself is enclosed in braces):
define \%a {{{foo}}}
echo \fsubstring(\%a)
{foo}
This also works for any other kind of string:
define \%a {{ab{cd}}
echo \fsubstring(\%a)
ab{cd
kermit -C "define \\%a foo, define phonenumber 7654321"
In this case we follow UNIX quoting rules by doubling the backslash. Once C-Kermit starts, the \%a and \m(phonenumber) variables are defined as indicated and can be used in the normal way.
In DOS or Windows or OS/2 the command would be:
kermit -C "define \%%a foo, define phonenumber 7654321"
Here we need to double the percent sign rather than the backslash because of DOS shell quoting rules.
SET OUTPUT PACING milliseconds
could be used to take care of this, but the pacing interval is constant and must be set large enough to allow even the slowest echo to finish. If the script is large (an actual example is 14,000 lines long), this can cause it to take hours longer than it needs to.
Here is a macro you can use to OUTPUT a string in an Echoplex environment:
define XOUTPUT {
local \%c \%i
set output pacing 0
for \%i 1 \flen(\%*) 1 {
asg \%c \fsubstr(\%*,\%i,1)
output \%c
input 2 \%c
}
}
C-Kermit 7.0 or later is required.
It sends one character at a time and then waits up to 2 seconds for the character to be echoed back, but continues to the next character as soon as the echo appears, so no time is wasted. You can add an IF FAIL clause after the INPUT in case you want to do something special about failure to detect an echo within the timeout period. Obviously you can also change the 2-second limit, and adjust the script in any other desired way.
The right way to handle this situation is to have your script look for the "What Are You?" sequence and send the response itself, as described in Using C-Kermit, pp.429-431. Or you can work around it by telling the local Kermit to "set input echo off" and/or "set transfer interruption off".
; EVALUATE is a command that evaluates an arithmetic expression. ; See HELP EVALUATE for details. This is just for demonstration. ; Arithmetic expressions can be used in any context where a number ; can be used. Also, the special notation: ; ; .\%a ::= expression ; ; evaluates the expression and assigns the result to the variable. ; .\%a := fffe ; Set variable to hex value set eval old ; See HELP EVAL eval \fhex2n(\%a) ; Show value of variable eval \fhex2n(\%a) + 1 ; Show value of expression eval \fhex2n(\%a) + 2 ; Show value of expression .\%x ::= \fhex2n(\%a) + 1 ; Assign value of expression to variable echo \fn2hex(\%x) ; Display variable's value in hex .\%x ::= \fhex2n(\%a) + 2 : Ditto echo \fn2hex(\%x) .\%x ::= \fhex2n(\%a) | \fhex2n(ffff) ; Similarly for logical OR echo \fn2hex(\%x) .\%x ::= \fhex2n(\%a) & \fhex2n(ffff) ; and logical AND echo \fn2hex(\%x)
By the way, you might be tempted to use Kermit's \xnn notation to plug hex numbers into arithmetic expressions but this doesn't work. That notation is strictly for bytes (hex representation of character values), not for numbers.
[ Top ] [ Contents ] [ C-Kermit Home ] [ C-Kermit 8.0 Overview ] [ Kermit Home ]