通讯/手机编程

开发平台：

Windows_Unix

ckermit2.txt：源码内容

4.6. Starting the Remote Kermit Server Automatically
As noted on pages 275-276 of "Using C-Kermit" 2nd edition, you can have Kermit
send "kermit receive" commands automatically when it is in local mode and you
give a SEND or similar command, to start the remote Kermit receiver in case it
is not already started. The "kermit receive" commands are specified by:
SET PROTOCOL KERMIT <binary-receive-command> <text-receive-command>
As of version 7.0, a Kermit protocol option has been added to send a string
to the host in advance of any Kermit packets when you give a GET-class or
REMOTE command. This will switch the remote C-Kermit into the appropriate
mode or, if the remote system is at a system command (shell) prompt,
execute the string on the remote system. The new syntax of the SET PROTOCOL
KERMIT command is:
SET PROTOCOL KERMIT [ <s1> [ <s2> [ <s3> ] ] ]
where:
Default Meaning
s1 {kermit -ir} Remote "kermit receive in binary mode" command.
s2 {kermit -r} Remote "kermit receive in text mode" command.
s3 {kermit -x} Remote "start kermit server" command.
NOTE: If the remote Kermit is 6.0, the following are recommended for fast
startup and high-performance file transfer (see Appendix I in "Using
C-Kermit", second Edition, for command-line options):
s1 kermit -YQir (Kermit receive binary, skip init file, fast.)
s2 kermit -YQTr (Kermit receive text, skip init file, fast.)
s3 kermit -YQx (Kermit server, skip init file, fast.)
If the remote is C-Kermit 7.0 or later, change the -x option (enter server
mode) to -O (uppercase letter O), which means "enter server mode for One
transaction only); this way, it is not stuck in server after the transfer.
Also note that the Q is redundant in version 7.0, since fast Kermit protocol
settings are now the default.
Note that in case the C-Kermit executable is called "wermit" or "ckermit"
you can change "kermit" in the strings above to "wermit" or "ckermit" and
C-Kermit 7.0 or later will recognize these as synonyms for "kermit", in case
it is at its command prompt when one of these strings is sent to it.
4.7. File-Transfer Command Switches
Over the years, various new methods of transferring a file have accumulated,
until we had, in addition to the SEND command, also MOVE (send and then
delete), MAIL (send as email), REMOTE PRINT (send to be printed), CSEND (send
the output of a command), PSEND (send a part of a file), BSEND (send in binary
mode), RESEND (resume an interrupted SEND), etc etc. Similarly: GET, REGET,
CGET, RETRIEVE, and so on.
Not only is it confusing to have different names for these commands, many of
which are not real words, but this also does not allow all combinations, like
"send a file as mail, then delete it".
In C-Kermit 7.0, the SEND, GET, and RECEIVE commands were restructured to
accept modifier switches (switches are explained in Section 1.5).
4.7.1. SEND Command Switches
Without switches, the SEND command still works exactly as before:
send oofa.txt ; send a single file
send oofa.* ; send multiple files
send oofa.txt x.x ; send oofa.txt as x.x (tell receiver its name is x.x)
send ; send from SEND-LIST
But now the following modifier switches may be included between "send" and the
filename. Zero, one, two, or more switches may be included in any combination
that makes sense. Switch names (such as /BINARY) can be abbreviated, just
like any other keywords. Most of these switches work only when using Kermit
protocol (/TEXT and /BINARY are the exceptions).
/AFTER:date-time
Specifies that only those files modified (or, in VMS, created) after
the given date-time (see section 1.6) are to be sent. Examples:
send /text /after:{2-Feb-1997 10:28:30} *.txt
send /text /after:fdate(oofa.txt) *.txt
Synonym: /SINCE.
/ARRAY:arrayname
Specifies that instead of sending a file, C-Kermit is to send the
contents of the given array. Since an array does not have a filename,
you should include an /AS-NAME switch to specify the name under which
the array is to be sent (if you do not, the name "_array_x_" is used,
where 'x' is replaced by the array designator). See section 7.10 for
array-name syntax. As noted in that section, you can also include a
range to have a segment of the array sent, rather than the whole
thing; for example: "send /array:&a[100:199]". It is strongly
recommended that you accompany the /ARRAY switch with a /TEXT or
/BINARY switch to force the desired transfer mode, since otherwise the
various automatic mechanisms might switch to binary mode when you
really wanted text, or vice versa. In text mode a line terminator is
added to the end of each array element, but not in binary mode. For
details and examples see Section 7.10.11.
/AS-NAME:text
Specifies "text" as the name to send the file under.
You can also still specify the as-name as the second filename on the
SEND command line. The following two commands are equivalent:
send oofa.txt oofa.new
send /as:oofa.new oofa.txt
/BEFORE:date-time
Specifies that only those files modified (or, in VMS, created)
before the given date-time (section 1.6) are to be sent.
/BINARY
Performs this transfer in binary mode without affecting the global
transfer mode, overriding not only the FILE TYPE and TRANSFER MODE
settings, but also the FILE PATTERN setting, but for this SEND command
only. In other words, SEND /BINARY means what it says: send the file
in binary mode, regardless of any other settings. Example:
set file type text ; Set global transfer mode to text
send /binary oofa.zip ; Send a file in binary
send oofa.txt ; This one is sent in text mode
/COMMAND
SEND /COMMAND is equivalent to CSEND (section 4.2.2) -- it says to send
the output from a command, rather than the contents of a file.
The first "filename" on the SEND command line is interpreted as the name
of a command; the second (if any) is the as-name. Examples:
send /command {grep Sunday oofa.txt} sunday.txt
send /as-name:sunday.txt /command {grep Sunday oofa.txt}
send /bin /command {tar cf - . | gzip -c} {!gunzip -c | tar xf -}
/DELETE
Deletes the file (or each file in the group) after it has been sent
successfully (but does not delete it if it was not sent successfully).
SEND /DELETE is equivalent to MOVE. Has no effect when used with
/COMMAND. Example:
send /delete *.log
/DOTFILES
(UNIX and OS-9 only) Normally files whose names begin with "." are
skipped when matching wildcards that do not also beging with ".".
Include /DOTFILES to force these files to be included too.
/RECURSIVE
Descend the through the directory tree when locating files to send.
Automatically sets /PATHNAMES:RELATIVE. Explained in section 4.11.
/EXCEPT:<pattern>
See Section 1.5.4.
/NOBACKUP
This means to skip backup files when sending, even if they match the
SEND file specification. This is equivalent to using SEND /EXCEPT and
including *.~[0-9]*~ in the exception list (or *.~*~ if Kermit was built
without pattern-matching support; see Section 4.9.1). Including this
switch is equivalent to giving SET SEND BACKUP OFF (Section 4.0.6) prior
to SEND, except its effect is local to the SEND command with which it was
given.
/NODOTFILES
The opposite of /DOTFILES (q.v.)
/FILENAMES:{CONVERTED,LITERAL}
Use this switch to override the current global SET FILE NAMES setting
for this transfer only.
/FILTER:<command>
This specifies a filter to pass the file through before sending it.
See the section on file-transfer pipes and filters. The /FILTER switch
applies only to the file-transfer command it is given with; it does not
affect the global SEND FILTER setting, if any.
/IMAGE
VMS: Sends in image mode. Non-VMS: same as /BINARY.
/LABELED
VMS and OS/2 only: Sends in labeled mode.
/LARGER-THAN:number
Specifies that only those files that are longer than the given number
of bytes are to be sent.
/LISTFILE:filename
Specifies that the files to be sent are listed in a file with the given
filename. The file contains one filename per line. These filenames are
not checked in any way; each filename is taken and does not use or
depend on any Kermit-specific syntax. In particular, backslashes are
not treated specially, leading and trailing spaces are not stripped,
etc. However, if a filename contains wildcards, they are expanded.
Example: If a file named files.txt contains the following lines:
blah.txt
oofa*
x.x
(but without leading or trailing spaces), then the C-Kermit command
"send /listfile:files.txt" will send the files blah.txt, x.x, and all
files whose names start with "oofa", assuming the files exist and are
readable. The /LISTFILE switch, can, of course, be used with other
switches when it makes sense, for example, /EXCEPT, /BINARY, /AFTER,
/SMALLER, /MOVE-TO, /DELETE, /AS-NAME with a template, etc.
/MAIL:address
Sends the file as e-mail to the given address or addresses.
"send /mail:address filename" is equivalent to "mail filename address".
You can include multiple addresses separated by commas. Examples:
send /mail:kermit-support@columbia.edu packet.log
send /mail:cmg,fdc,jrd oofa.txt
As with any switch argument, if the address or address list contains any
spaces, you must enclose it in braces. The format of the addresses must
agree with that understood by the mail-sending program on the receiver's
computer.
/MOVE-TO:directory-name
Specifies that after each (or the only) source file is sent successfully,
and ONLY if it is sent successfully, it should be moved to the named
directory. If the directory name contains spaces, enclose it in braces.
If the directory does not exist, it is created if possible; if it can't be
created, the command fails and an error message is printed. Example:
send /text /move-to:/users/olga/backup/ *.txt
/NOT-AFTER:date-time
Specifies that only those files modified at or before the given date and
time are to be sent.
/NOT-BEFORE:date-time
Specifies that only those files modified at or after the given date and
time are to be sent.
/PATHNAMES:{OFF,ABSOLUTE,RELATIVE}
Use this switch to override the current global SET SEND PATHNAMES setting
for this transfer only. /PATHNAMES:ABSOLUTE or RELATIVE also sets
/FILENAMES:LITERAL (also for this transfer only) since pathnames are not
sent otherwise.
/RENAME-TO:text
Specifies that after the (or each) source file is sent successfully, and
ONLY if it is sent successfully, it should be renamed to the name given.
If the name contains spaces, enclose it in braces. If a file group is
being sent, then the "text" must contain a variable reference such as
v(filename) (see section 4.1). Example:
send /rename-to:ok_v(filename) *.*
This sends each file in the current directory and if it was sent
successfully, changes its name to begin with "ok_".
/SMALLER-THAN:number
Specifies that only those files that are smaller than the given number
of bytes are to be sent.
/SUBJECT:text
Subject for email. Actually, this is just a synonym for /AS-NAME. If the
text includes spaces, you must enclose it in braces. If you don't specify
a subject (or as-name), the name of the file is used as the subject.
Example:
send /mail:kermit-support@columbia.edu /subj:{As requested} packet.log
/PRINT:options
Sends the file to be printed, optionally specifying options for the
printer. Equivalent to REMOTE PRINT filename options. Examples:
send /print oofa.txt ; No options.
send /print:/copies=3 oofa.txt ; "/copies=3" is a VMS PRINT switch.
send /print:-#3 oofa.txt ; "-#3" is a UNIX lpr switch.
/PROTOCOL:name
Uses the given protocol to send the file (Kermit, Zmodem, etc) for this
transfer without changing global protocol. Only available in Kermit 95,
UNIX, and OS-9. Example:
set protocol kermit ; Set global protocol
send /proto:zmodem /bin oofa.zip ; Send just this file with Zmodem
send oofa.txt ; This file is sent with Kermit
/QUIET
When sending in local mode, this suppresses the file-transfer display.
/RECOVER
Used to recover from a previously interrupted transfer; SEND /RECOVER is
equivalent to RESEND. Recovery only works in binary mode; SEND /RECOVER
and RESEND include an implied /BINARY switch. Even then, recovery will
successful only if (a) the original (interrupted) transfer was also in
binary mode, or (b) if it was in text mode, the two Kermit programs run on
platforms where text-mode transfers are not length-changing.
/STARTING:number
Starts sending the file from the given byte position.
SEND /STARTING:n filename is equivalent to PSEND filename n.
/TEXT
Performs this transfer in text mode without affecting the global
transfer mode, overriding not only the FILE TYPE and TRANSFER MODE
settings, but also the FILE PATTERN setting, for this SEND command
only. In other words, SEND /TEXT really send the file in text mode,
regardless of any other settings or negotiations.
About mail... Refer to section 4.7.1. The same rules apply as for file
transfer. If you are mailing multiple files, you can't use an as-name (in
this case, a subject) unless it contains replacement variables like
v(filenum). For example, if you:
send /mail:somebody@xyz.com *.txt
Then each file will arrive as a separate email message with its name as the
subject. But if you:
send /mail:somebody@xyz.com /subject:{Here is a file} *.txt
Then each file message will have the same subject, which is probably not what
you want. You can get around this with constructions like:
send /mail:somebody@xyz.com /subject:{Here is v(filename)} *.txt
which embed the filename in the subject.
The MOVE, CSEND, MAIL, and RESEND commands now also accept the same switches.
And the switches are also operative when sending from a SEND-LIST (see "Using
C-Kermit", 2nd Ed, pp.191-192), so, for example, it is now possible to SEND
/PRINT or SEND /MAIL from a SEND-LIST.
The MSEND and MMOVE commands also take switches, but not all of them. With
these commands, which take an arbitrary list of filespecs, you can use
/BINARY, /DELETE, /MAIL, /PRINT, /PROTOCOL, /QUIET, /RECOVER, and /TEXT (and
/IMAGE or /LABELED, depending on the platform). MMOVE is equivalent to MSEND
/DELETE. (If you want to send a group of files, but in mixed transfer modes
with per-file as-names, use ADD SEND-LIST and then SEND.)
The MSEND/MMOVE switches come before the filenames, and apply to all of them:
msend /print /text *.log oofa.txt /etc/motd
If you type any of these commands (SEND, CSEND, MSEND, etc) followed by a
question mark (?), you will see a list of the switches you can use. If you
want to see a list of filenames, you'll need to type something like "send ./?"
(UNIX, OS/2, Windows, etc), or "send []?" (VMS), etc. Of course, you can also
type pieces of a filename (anything that does not start with "/") and then "?"
to get a list of filenames that start that way; e.g. "send x.?" still works
as before.
In UNIX, where "/" is also the directory separator, there is usually no
ambiguity between a fully-specified pathname and a switch, except when a file
in the root directory has the same name as a switch (as noted in section 1.5):
send /etc/motd ; Works as expected
send /command ; ???
The second example interprets "/command" as a switch, not a filename. To
actually send a file called "command" in the root directory, use:
send {/command}
or other system-dependent forms such as //command, /./command, c:/command,
etc, or cd to / and then "send command".
4.7.2. GET Command Switches
Without switches, the GET command still works about the same as before:
get oofa.txt ; GET a single file
get oofa.* ; GET multiple files
However, the mechanism for including an "as-name" has changed. Previously,
in order to include an as-name, you were required to use the "multiline" form
of GET:
get
<remote-filespec>
<local-name>
This was because the remote filespec might contain spaces, and so there would
be no good way of telling where it ended and where the local name began, e.g:
get profile exec a foo
But now since we can use {braces} for grouping, we don't need the multiline
GET form any more, and in fact, support for it has been removed. If you give
a GET command by itself on a line, it fails and an error message is printed.
The new form is:
GET [ switches... ] remote-name [ local-name ]
If the remote-name or local-name contains spaces, they must be enclosed in
braces:
get {profile exec a} foo
get oofa.txt {~/My Files/Oofa text}
If you want to give a list of remote file specifications, use the MGET
command:
MGET [ switches... ] remote-name [ remote-name [ remote-name ... ] ]
Now you can also include modifier switches between "get" or "mget" and the
remote-name; most of the same switches as SEND:
/AS-NAME:text
Specifies "text" as the name to store the incoming file under. (This
switch is not available for MGET.) You can also still specify the
as-name as the second filename on the GET command line. The following
two commands are equivalent:
get oofa.txt oofa.new
get /as:oofa.new oofa.txt
/BINARY
Tells the server to send the given file(s) in binary mode without
affecting the global transfer mode. Example:
set file type text ; Set global transfer mode to text
get /binary oofa.zip ; get a file in binary mode
get oofa.txt ; This one is transferred in text mode
Or, perhaps more to the point:
get /binary foo.txt ; where "*.txt" is a text-pattern
This works only if the server is C-Kermit 7.0 or later or K95 1.1.18
or later.
/COMMAND
GET /COMMAND is equivalent to CGET (section 4.2.2) -- it says to receive
the file into the standard input of a command, rather than saving it on
disk. The /AS-NAME or the second "filename" on the GET command line is
interpreted as the name of a command. Examples:
get /command sunday.txt {grep Sunday oofa.txt}
get /command /as-name:{grep Sunday oofa.txt} sunday.txt
get /bin /command {!gunzip -c | tar xf -} {tar cf - . | gzip -c}
/DELETE
Asks the Kermit server to delete the file (or each file in the group)
after it has been transferred successfully (but not to delete it if it
was not sent successfully). GET /DELETE is equivalent to RETRIEVE.
Example:
get /delete *.log
/EXCEPT:pattern
Specifies that any files whose names match the pattern, which can be a
regular filename, or may contain "*" and/or "?" metacharacters,
are to be refused upon arrival. To specify multiple patterns (up to 8),
use outer braces around the group, and inner braces around each pattern:
/EXCEPT:{{pattern1}{pattern2}...}
See the description of SEND /EXCEPT in Section 4.7.1 for examples, etc.
Refusal is accomplished using the Attribute Rejection mechanism (reason
"name"), which works only when Attribute packets have been successfully
negotiated.
/FILENAMES:{CONVERTED,LITERAL}
Use this switch to override the current global SET FILE NAMES setting
for this transfer only.
/FILTER:<command>
This specifies a filter to pass the incoming file through before writing
to disk. See the section on file-transfer pipes and filters. The /FILTER
switch applies only to the file-transfer command it is given with; it does
not affect the global RECEIVE FILTER setting, if any.
/IMAGE
VMS: Transfer in image mode. Non-VMS: same as /BINARY.
/LABELED
VMS and OS/2 only: Specifies labeled transfer mode.
/MOVE-TO:<directory>
This tells C-Kermit to move each file that is successfully received to
the given directory. Files that are not successfully received are not
moved. By default, files are not moved.
/PATHNAMES:{OFF,ABSOLUTE,RELATIVE,AUTO}
Use this switch to override the current global SET RECEIVE PATHNAMES
setting for this transfer only. /PATHNAMES:ABSOLUTE or RELATIVE also sets
/FILENAMES:LITERAL (also for this transfer only) since incoming pathnames
would not be treated as pathnames otherwise. See Section 4.10.
/QUIET
When sending in local mode, this suppresses the file-transfer display.
/RECOVER
Used to recover from a previously interrupted transfer; GET /RECOVER
is equivalent to REGET. Recovery only works in binary mode; SEND /RECOVER
and RESEND include an implied /BINARY switch. Even then, recovery will
successful only if (a) the original (interrupted) transfer was also in
binary mode, or (b) if it was in text mode, the two Kermit programs run
on platforms where text-mode transfers are not length-changing.
/RECURSIVE
Tells the server that the GET file specification applies recursively.
This switch also automatically sets /PATHNAMES:RELATIVE in both the server
AND the client. When used in conjunction with /DELETE, this "moves" a
directory tree from the server's computer to the client's computer (except
that only regular files are deleted from the server's computer, not
directories; thus the original directories will be left, but will contain
no files). Note that all servers that support /RECURSIVE do not
necessarily do so in combination with other switches, such as /RECOVER.
(Servers that do include C-Kermit 7.0 and later, K95 1.1.18 and later.)
/RENAME-TO:<string>
This tells C-Kermit to rename each file that is successfully received to
the given string. Files that are not successfully received are not
renamed. By default, files are not renamed. The <string> can be a
literal string, which is appropriate when only one file is being received,
or it can contain one or more variables that are to be evaluated at the
time each file is received, such as v(filename), v(filenumber),
v(ntime), v(pid), v(user), etc. WARNING: if you give a literal string
and more than one file arrives, each incoming file will be given the same
name (but SET FILE COLLISION BACKUP or RENAME can be used to keep the
incoming files from overwriting each other).
/TEXT
Tells the server to perform this transfer in text mode without affecting
its global transfer mode. See /BINARY for additional info.
The /MAIL and /PRINT options are not available, but you can use /COMMAND
to achieve the same effect, as in these UNIX examples:
get /command oofa.txt {mail kermit@columbia.edu}
get /command oofa.txt lpr
In OS/2 or Windows, you can GET and print like this:
get oofa.txt prn
The CGET, REGET, RETRIEVE commands also accept the same switches as GET. CGET
automatically sets /COMMAND; REGET automatically sets /RECOVER and /BINARY,
and RETRIEVE automatically sets /DELETE.
4.7.3. RECEIVE Command Switches
Without switches, the RECEIVE command still works as before:
receive ; Receives files under their own names
receive /tmp ; Ditto, but into the /tmp directory
r ; Same as "receive"
receive foo.txt ; Receives a file and renames to foo.txt
Now you can also include modifier switches may be included between "receive"
and the as-name; most of the same switches as GET:
/AS-NAME:text
Specifies "text" as the name to store the incoming file under.
You can also still specify the as-name as a filename on the
command line. The following two commands are equivalent:
r oofa.new
r /as:oofa.new
/BINARY
Performs this transfer in binary mode without affecting the global
transfer mode. NOTE: This does not override the incoming filetype (as
it does with GET), so this switch is useful only if ATTRIBUTE TYPE is
OFF, or if the other Kermit does not send a TYPE (text or binary)
attribute. In any case, it has no affect whatsoever on the file sender.
/COMMAND
RECEIVE /COMMAND is equivalent to CRECEIVE (section 4.2.2) -- it says to
receive the file into the standard input of a command, rather than saving
it on disk. The /AS-NAME or the "filename" on the RECEIVE command line
is interpreted as the name of a command.
r /command {grep Sunday oofa.txt}
r /command /as-name:{grep Sunday oofa.txt}
r /bin /command {tar cf - . | gzip -c}
/EXCEPT:pattern
Specifies that any files whose names match the pattern, which can be a
regular filename, or may contain "*" and/or "?" metacharacters,
are to be refused upon arrival. To specify multiple patterns (up to 8),
use outer braces around the group, and inner braces around each pattern:
/EXCEPT:{{pattern1}{pattern2}...}
See the description of SEND /EXCEPT in Section 4.7.1 for examples, etc.
Refusal is accomplished using the Attribute Rejection mechanism (reason
"name"), which works only when Attribute packets have been successfully
negotiated.
/FILENAMES:{CONVERTED,LITERAL}
Use this switch to override the current global SET FILE NAMES setting
for this transfer only.
/FILENAMES:{CONVERTED,LITERAL}
Use this switch to override the current global SET FILE NAMES setting
for this transfer only.
/FILTER:<command>
This specifies a filter to pass the incoming file through before writing
to disk. See the section on file-transfer pipes and filters. The /FILTER
switch applies only to the file-transfer command it is given with; it does
not affect the global RECEIVE FILTER setting, if any.
/IMAGE
VMS: Transfer in image mode. Non-VMS: same as /BINARY.
See comments under RECEIVE /BINARY.
/LABELED
VMS and OS/2 only: Specifies labeled transfer mode.
See comments under RECEIVE /BINARY.
/MOVE-TO:<directory>
This tells C-Kermit to move each file that is successfully received to
the given directory. Files that are not successfully received are not
moved. By default, files are not moved.
/PATHNAMES:{ABSOLUTE,RELATIVE,OFF,AUTO}
Use this switch to override the current global SET RECEIVE PATHNAMES
setting for this transfer only. See Section 4.10.
/RECURSIVE
When used with the RECEIVE command, /RECURSIVE is simply a synonym
for /PATHNAMES:RELATIVE.
/RENAME-TO:<string>
This tells C-Kermit to rename each file that is successfully received to
the given string. Files that are not successfully received are not
renamed. By default, files are not renamed. The <string> can be a
literal string, which is appropriate when only one file is being received,
or it can contain one or more variables that are to be evaluated at the
time each file is received, such as v(filename), v(filenumber),
v(ntime), v(pid), v(user), etc. WARNING: if you give a literal string
and more than one file arrives, each incoming file will be given the same
name (but SET FILE COLLISION BACKUP or RENAME can be used to keep the
incoming files from overwriting each other).
/QUIET
When receiving in local mode, this suppresses the file-transfer display.
/TEXT
Receives in text mode without affecting the global transfer mode. See
comments under RECEIVE /BINARY.
The /MAIL and /PRINT options are not available, but you can use /COMMAND
to achieve the same effect, as in these UNIX examples:
r /command {mail kermit@columbia.edu}
r /command lpr
In OS/2 or Windows, you can RECEIVE and print like this:
receive prn
The CRECEIVE command now also accepts the same switches.
4.8. Kermit Protocol Improvements
4.8.1. Multiple Attribute Packets
C-Kermit 7.0 now sends more than one Attribute packet if a file's attributes
do not fit into a single packet of the negotiated length. If a particular
attribute (such as file creation date-time) does not fit within the negotiated
length (which will only happen when the negotiated length is around 20 or
less), that attribute is not sent at all.
4.8.2. Very Short Packets
There are certain situations where extremely short packets must be used;
20 or 30 bytes at most. This can happen when one or more devices along the
communication path have very small buffers and lack an effective means of
flow control. Examples are sometimes cited involving radio modems.
When the maximum packet length is shorter than certain packets that would be
sent, those packets are either truncated or else broken up into multiple
packets. Specifically:
1. Parameter negotiation packets (I, S, and their ACKs) are truncated to
the negotiated length. Any parameters that do not fit are reset to
their default values. There is no provision in the Kermit protocol for
fragmentation and reassembly of parameter strings.
2. File header packets (containing the filename) are simply truncated.
There is no provision in the Kermit protocol for fragmentation and
reassembly of filenames.
3. Attribute packets are fragmented and reassembled as described in 4.8.1
without loss of data, except in case a field will not fit at all in
the negotiated length (the longest attribute is usually the date and
time of file creation/modification) because of the rule that attributes
may not be broken across packets.
4. Data packets and other packets are unaffected -- they can be as short
as they need to be, within reason.
4.9. Wildcard / File Group Expansion
"Wildcard" refers to the notation used in filenames to specify a group of
files by pattern matching.
4.9.1. In UNIX C-Kermit
Prior to C-Kermit 7.0, C-Kermit was capable of expanding wildcard strings
containing only the "metacharacters" '*' and '?':
* Matches any sequence of zero or more characters. For example: "ck*.c"
matches all files whose names start with "ck" and end with ".c", including
"ck.c".
? Matches any single character. For example, "ck?.c" matches all files whose
names are exactly 5 characters long and start with "ck" and end with ".c".
When typing commands at the prompt, you must precede any question mark to
be used for matching by a backslash () to override the normal function of
question mark, which is providing menus and file lists.
C-Kermit 7.0 adds the additional features that users of ksh, csh, and bash
are accustomed to:
[abc]
Square brackets enclosing a list of characters matches any single
character in the list. Example: ckuusr.[ch] matches ckuusr.c and ckuusr.h.
[a-z]
Square brackets enclosing a range of characters; the hyphen separates the
low and high elements of the range. For example, [a-z] matches any
character from a to z.
[acdm-z]
Lists and ranges may be combined. This example matches a, c, d, or m
through z.
{string1,string2,...}
Braces enclose a list of strings to be matched. For example:
ck{ufio,vcon,cmai}.c matches ckufio.c, ckvcon.c, or ckcmai.c. The strings
may themselves contain metacharacters, bracket lists, or indeed, other
lists of strings, but (when matching filenames) they may not contain
directory separators.
Thus, the metacharacters in filenames (and in any other field that can be a
pattern, such as the IF MATCH pattern, SEND or GET exception lists, etc) are:
* ? [ {
And within braces only, comma (,) is a metacharacter.
To include a metacharacter in a pattern literally, precede it with a backslash
'' (or two if you are passing the pattern to a macro). Examples:
send a*b ; Send all files whose names start with 'a' and end with 'b'.
send a?b ; Ditto, but the name must be exactly three characters long.
send a[a-z]b ; Ditto, but the second character must be a lowercase letter.
send a[x-z]b ; Ditto, except the second character must be 'x', '-', or 'y'.
send a[ghi]b ; Ditto, except the second character must be 'g', 'h', or 'i'.
send a[?*]b ; Ditto, except the second character must be '?' or '*'.
send a[?*]b ; Same as previous.
send *?[a-z]* ; All files with names containing at least one character
; that is followed by a lowercase letter.
Or, more practically:
send ck[cuw]*.[cwh] ; Send the UNIX C-Kermit source files.
To refer to the C-Kermit sources files and makefile all in one filespec:
{{makefile,ck[cuw]*.[cwh]}}
(NOTE: if the entire pattern is a {stringlist}, you must enclose it it TWO
pairs of braces, since the SEND command strips the outer brace pair, because
of the "enclose in braces if the filename contains spaces" rule).
If the makefile is called ckuker.mak:
ck[cuw]*.{[cwh],mak}
(NOTE: double braces are not needed here since the pattern does not both
begin and end with a brace.)
To add in all the C-Kermit text files:
ck[cuw]*.{[cwh],mak,txt}
All of these features can be used anywhere you would type a filename that
is allowed to contain wildcards.
When you are typing at the command prompt, an extra level of quoting is
required for the '?' character to defeat its regular function of producing a
list of files that match what you have typed so far, for example:
send ck[cu]?
lists all the files whose names start with ckc and cku. If you quote the
question mark, it is used as a pattern-matching character, for example:
send ck?[ft]io.c
sends all the file and communications i/o modules for all the platforms:
ckufio.c, ckutio.c, ckvfio.c, ckvtio.c, etc.
If, however, a filename actually contains a question mark and you need to
refer to it on the command line, you must use three (3) backslashes. For
example, if the file is actually called ck?fio.c, you would use:
send ck\?fio.c
Further notes on quoting:
. A single backslash is sufficient for quoting a special character at the
command prompt or in a command file. However, when passing patterns to
macros you'll need double backslashes, and when referring to these
patterns within the macro, you'll need to use fcontents(%1) (see
Section 1.11.5). You should enclose macro argument references in
braces in case grouped arguments were passed. Example:
define ismatch {
xif match {fcont(%1)} {fcont(%2)} {
end 0 MATCH
} else {
end 1 NO MATCH
}
}
ismatch ab*yz a*\**z ; Backslash must be doubled
ismatch {abc def xyz} *b*e*y* ; Braces must be used for grouping
. Watch out for possible conflicts between {} in filename patterns and
{} used for grouping multiple words into a single field, when the pattern
has outer braces. For example, in:
if match {abc xyz} {a* *z} echo THEY MATCH
braces must be used to group "abc xyz" into a single string. Kermit strips
off the braces before comparing the string with the pattern. Therefore:
if match makefile {makefile,Makefile} echo THEY MATCH
does not work, but:
if match makefile {{makefile,Makefile}} echo THEY MATCH
does.
. If you use a pattern that has outer braces, like {*.txt,*.doc},
in a field that accepts a pattern list (like SEND /EXCEPT:xxx), you'll
need to add two extra sets of outer braces:
send /except:{{{*.txt,*.doc}}} *.*
C-Kermit's new pattern matching capabilities are also used when C-Kermit is
in server mode, so now you can send requests such as:
get ck[cuw]*.[cwh]
to a C-Kermit server without having to tell it to SET WILD SHELL first.
Previously this would have required:
mget ckc*.c ckc*.w ckc*.h cku*.c cku*.w cku*.h ckw*.c ckw*.w ckw*.h
The new pattern matching features make SET WILD SHELL redundant, and barring
any objections, it will eventually be phased out. (One possible reason for
retaining it would be as an escape mechanism when Kermit does not understand
the underlying file system.)
By the way, patterns such as these are sometimes referred to as "regular
expressions", but they are not quite the same. In a true regular expression
(for example), "*" means "zero or more repetitions of the previous item", so
(for example), "([0-9]*)" would match zero or more digits in parentheses. In
Kermit (and in most shells), this matches one digit followed by zero or more
characters, within parentheses. Here are some hints:
. Although you can't match any sequence of digits (or letters, etc), you
can match (say) 1, 2, or 3 of them in row. For example, the following
pattern matches Kermit backup files (with backup numbers from 1 to 999):
*.~{[1-9],[1-9][0-9],[1-9][0-9][0-9]}~
. There is presently no NOT operator, so no way to match any character or
string EXCEPT the one(s) shown.
In other wildcarding news...
. You may now "send xxx" where "xxx" is a directory name, and this will send
all the files from the directory xxx, as if you had typed "send xxx/*".
You can also use the special shorthand "send ." to send all the files from
the current directory.
. To easily skip over backup files (the ones whose names end like .~22~)
when sending, you can use SEND /NOBACKUP (see Section 4.0.6 for details).
. When choosing Kermit to expand wildcards, rather than the shell, you can
choose whether "dot files" -- files whose names begin with ".", which are
normally "invisible" -- should be matched:
SET WILD KERMIT /NO-MATCH-DOT-FILES (this is the default)
SET WILD KERMIT /MATCH-DOT-FILES (this allows matching of "." files)
or include the /DOTFILES or /NODOTFILES switch on the command you are
using, such as SEND or DIRECTORY.
. Commands such as DIRECTORY and SEND allow recursive directory traversal.
There are also new functions for this to use in scripts. See Section
4.11 for details.
When building file lists in UNIX, C-Kermit follows symbolic links. Because of
this, you might encounter any or all of the following phenomena:
. Multiple copies of the same file; e.g. one from its real directory and
others from links to its real directory, if both the real directory and
the links to it are in the wildcard expansion list.
. A command might unexpectedly "hang" for a long time because an NFS link
might not be responding, or the directory you are looking at contains
a link to a huge directory tree (example: "directory /recursive /etc"
when /etc/spool is a symlink to /var/spool, which is a large organization's
incoming email directory, containing tens of thousands of subdirectories).
The size of the file list that Kermit can build is limited in most C-Kermit
implementations. The limit, if any, depends on the implementation. Use the
SHOW FEATURES command and look in the alphabetized options list for MAXWLD to
see the value.
4.9.2. In Kermit 95
Kermit 95 1.1.18 and later uses the same pattern matching syntax as in UNIX,
but (as always) you will encounter numerous difficulties if you use backslash
() as the directory separator. In any command where K95 parses filenames
itself (that is, practically any file-oriented command except RUN), you can
use forward slash (/) as the directory separator to avoid all the nasty
conflicts.
4.9.3. In VMS, AOS/VS, OS-9, VOS, etc.
Platforms other than UNIX, Windows 95/98/NT, and OS/2 have their own
filename matching capabilities that are, in general, different from Kermit's
built-in ones and in any case might conflict with them. For example, []
encloses directory names in VMS.
Nevertheless you can still use all the pattern-matching capabilities described
in Section 4.9.1 by loading a file list into an array (e.g. with
ffiles(*,&a), see Section 4.11.3) and then using IF MATCH on the members.
4.10. Additional Pathname Controls
In version 6.0 and earlier, C-Kermit's SET { SEND, RECEIVE } PATHNAMES command
had only ON and OFF as options. In version 7.0, there are more choices:
SET SEND PATHNAMES OFF
When sending a file, strip all disk/directory information from the name.
Example: "send /usr/olga/letters/oofa.txt" sends the file as "oofa.txt".
This applies to actual filenames, not to any as-name you might specify.
SET SEND PATHNAMES RELATIVE
When sending a file, leave the pathname on as given. For example, if your
current directory is /usr/olga, "send letters/oofa.txt" sends the file as
"letters/oofa.txt", not "/usr/olga/letters/oofa.txt" or "letters.txt".
SET SEND PATHNAMES ABSOLUTE
When sending a file, convert its name to the full, absolute local pathname.
For example, if your current directory is /usr/olga, "send letters/oofa.txt"
sends the file as "/usr/olga/letters/oofa.txt". NOTE: Even with this
setting, device and/or node names are not included. For example, in VMS,
any node or device name is stripped; in Windows or OS/2, any disk letter
is stripped.
SET RECEIVE PATHNAMES OFF
When receiving a file, strip all disk/directory information from the name
before attempting to store it. This applies to incoming filename, not to
any as-name you might specify. Example: If a file arrives under the name
"/usr/olga/letters/oofa.txt" it is stored simply as "oofa.txt" in your
download directory or, if no download directory has been specified, in your
current directory.
SET RECEIVE PATHNAMES RELATIVE
When receiving a file, leave the pathname on as it appears in the incoming
name, but if the incoming name appears to be absolute, make it relative to
your current or download directory. Examples:
"oofa.txt" is stored as "oofa.txt".
"letters/oofa.txt" is stored as "letters/oofa.txt"; the "letters"
subdirectory is created if it does not already exist.
"/usr/olga/letters/oofa.txt" is stored as "usr/olga/letters/oofa.txt"
in your current or download directory, and the "usr", "usr/olga", etc,
directories are created if they do not exist.
SET RECEIVE PATHNAMES ABSOLUTE
The incoming filename is used as given. Thus it cannot be stored unless the
given path (if any) already exists or can be created. In this case, node,
device, or disk designations are NOT stripped, since they most likely
were given explicitly by the user as an as-name, meant to be used as given.
SET RECEIVE PATHNAMES AUTO
This is the default, and means RELATIVE if the sender tells me it is a
recursive transfer, OFF otherwise.
Set FILE NAMES CONVERTED now also affects pathnames too. When PATHNAMES are
RELATIVE or ABSOLUTE and FILE NAMES are CONVERTED, the file sender converts
its native directory-name format to UNIX format, and the file receiver
converts from UNIX format to its native one; thus UNIX format is the common
intermediate representation for directory hierarchies, as it is in the
ZIP/UNZIP programs (which is why ZIP archives are transportable among, UNIX,
DOS, and VMS).
Here's an example in which a file is sent from Windows to UNIX with relative
pathnames and FILE NAMES CONVERTED:
Source name Intermediate name Destination Name
C:K95TMPOOFA.TXT K95/TMP/OOFA.TXT k95/tmp/oofa.txt
In a more complicated example, we send the same file from Windows to VMS:
Source name Intermediate name Destination Name
C:K95TMPOOFA.TXT K95/TMP/OOFA.TXT [.K95.TMP]OOFA.TXT
(Note that disk letters and device designations are always stripped when
pathnames are relative).
As you can imagine, as more and more directory formats are considered, this
approach keeps matters simple: on each platform, Kermit must know only its
own local format and the common intermediate one. In most cases, the receiver
can detect which format is used automatically.
4.11. Recursive SEND and GET: Transferring Directory Trees
C-Kermit 7.0 in selected versions (UNIX, VMS, VOS, AOS/VS, Windows, and OS/2
at this writing) now permits the SEND command to traverse directories
"recursively" if you ask it to; that is, to send files from the current or
specified directory and all of its subdirectories too, and their
subdirectories, etc. (Some other commands can do this too, including
DIRECTORY.)
This feature is new to UNIX, Windows, VOS, and OS/2. VMS and AOS/VS have
always included "wildcard" or "template" characters that allow this, and in
this case, recursive directory traversal could happen behind Kermit's back,
i.e. Kermit does not have to do it itself (in VMS, the notation is "[...]" or
"[directory...]"; in AOS/VS is "#"). In C-Kermit 7.0, however, SEND
/RECURSIVE is supported by C-Kermit itself for VMS.
4.11.1. Command-Line Options
To descend a directory tree when sending files, use the -L command-line option
to indicate that the send operation is to be recursive, and include a name or
pattern to be sent. When giving a pattern, you should enclose it in quotes to
prevent the shell from expanding it. Examples:
$ kermit -Ls "/usr/olga/*" # send all of Olga's files in all her directories
$ kermit -Ls foo.txt # send all foo.txt files in this directory tree
$ kermit -Ls "*.txt" # send all .txt files in this directory tree
$ kermit -Ls "letters/*" # send all files in the letters directory tree
$ kermit -Ls letters # send all files in the letters directory tree
$ kermit -Ls "*" # send all files in this directory tree
$ kermit -Ls . # UNIX only: send all files in this directory tree
$ kermit -s . # UNIX only: a filename of . implies -L
If you let the shell expand wildcards, Kermit only sends files whose names
match files in the current or given directory, because the shell replaces an
unquoted wildcard expression with the list of matching files -- and the shell
does not build recursive lists. Note that the "." notation for the tree
rooted at the current directory is allowed only in UNIX, since in Windows and
OS/2, it means "*.*" (nonrecursive).
4.11.2. The SEND /RECURSIVE Command
If you include the /RECURSIVE switch in a SEND (or MOVE, or similar) command,
it means to descend the current or specified directory tree searching for
files whose names match the given name or pattern. Since this is not terribly
useful unless you also include pathnames with the outbound files, the
/RECURSIVE switch also includes an implicit /PATHNAMES:RELATIVE switch (which
you can undo by including an explicit /PATHNAMES switch after the /RECURSIVE
switch).
Examples:
SEND /RECURSIVE *
Sends all of the files in the current directory and all the files in
all of its subdirectories, and all of their subdirectories, etc, including
their relative pathnames. Empty directories are not sent.
SEND /RECURSIVE /PATHNAMES:ABSOLUTE *
Sends all of the files in the current directory and all the files in
all of its subdirectories, and all of their subdirectories, etc, including
their absolute pathnames.
SEND /RECURSIVE /PATHNAMES:OFF *
Sends all of the files in the current directory and all the files in
all of its subdirectories, and all of their subdirectories, etc, without
pathnames.
SEND /RECURSIVE /usr/olga/*
Sends all of the files in the /usr/olga directory and all the files in
all of its subdirectories, and all of their subdirectories, etc.
SEND /RECURSIVE /usr/olga (or /usr/olga/)
Same as above. If the name is a directory name (with or without a
trailing slash), its files are sent, and those of its subdirectories,
and their subdirectories, etc (see section 4.9).
SEND /RECURSIVE /TEXT /usr/olga/*.txt
As above, but only files whose names end with ".txt" are sent, and they
are sent in text mode (as they would be by default anyway if SET FILE
PATTERNS is ON or AUTO).
SEND .
UNIX only: Send all the files in the current directory.
SEND /RECURSIVE .
UNIX only: Sends all of the files in the current directory and all of its
subdirectories, etc (section 4.9).
The /RECURSIVE switch is different from most other switches in that its effect
is immediate (but still local to the command in which it is given), because it
determines how filenames are to be parsed. For example, "send *.txt" fails
with a parse error ("No files match") if there are no *.txt files in the
current directory, but "send /recursive *.txt" succeeds if there are ".txt"
files anywhere in the tree rooted at the current directory.
The /RECURSIVE switch also affects the file lists displayed if you type "?"
in a filename field. "send ./?" lists the regular files in the current
directory, but "send /recursive ./?" lists the entire directory tree rooted
at the current directory.
4.11.3. The GET /RECURSIVE Command
In a client/server setting, the client can also request a recursive
transfer with:
GET /RECURSIVE [ other switches ] <remote-filespec> [ <local-spec> ]
In which remote file specification can be a directory name, a filename, a
wildcard, or any combination. If the <local-spec> is not given (and PATHNAMES
are RELATIVE), incoming files and directories go into the current local
directory. If <local-spec> is given and is a directory, it becomes the root
of the tree into which the incoming files and directories are placed. If
<local-spec> has the syntax of a directory name (e.g. in UNIX it ends with /),
C-Kermit creates the directory and then places the incoming files into it.
If <local-spec> is a filename (not recommended), then all incoming files are
stored with that name with collisions handled according to the FILE COLLISION
setting.
Again, the normal method for transferring directory trees uses relative
pathnames, and this is the default when the sender has been given the
/RECURSIVE switch. The action at the receiver depends on its RECEIVE
PATHNAMES setting. The default is AUTO, meaning that if the sender tells
it to expect a recursive transfer, then it should automatically switch to
relative pathnames for this transfer only; otherwise it obeys the RECEIVE
PATHNAMES setting of OFF, ABSOLUTE, or RELATIVE.
What happens if a file arrives that has an absolute pathname, when the
receiver has been told to use only relative pathnames? As a security
precaution, in this case the receiver treats the name as if it was relative.
For example, if a file arrives as:
/usr/olga/oofa.txt
The receiver creates a "usr" subdirectory in its current directory, and
then an "olga" subdirectory under the "usr" subdirectory in which to store
the incoming file.
Suppose, however there is a sequence of directories:
/usr/olga/a/b/c/d/
in which "a" contains nothing but a subdirectory "b", which in turn contains
nothing but a subdirectory "c", which in turn contains nothing but a
subdirectory "d", which contains nothing at all. Thus there are no files in
the "/usr/olga/a/" tree, and so it is not sent, and therefore it is not
reproduced on the target computer.
4.11.4. New and Changed Functions
C-Kermit 7.0 adds the following functions:
ffiles(pattern[,&a])
This function has been changed to match only regular files in the current
or given directory, and to take an optional array name as a second argument
(explained below).
fdirectories(pattern[,&a])
Returns the number of directories that match the given pattern.
If the pattern does not include a directory, then the search is performed
in the current directory.
frfiles(pattern[,&a])
Returns the number of files in the current or given directory and all of
its subdirectories, and their subdirectories, etc, that match the given
pattern. Warning -- this one can take quite some time if performed at the
root of a large directory tree.
frdirectories(pattern[,&a])
Returns the number of directories in the current or given directory and all
of its subdirectories, and their subdirectories, etc, that match the given
pattern.
Each of these functions builds up a list of files to be returned by the
fnextfile() function, just as ffiles() always has done. (This can also
be done with the /ARRAY switch of the DIRECTORY command; see Sections 4.5.1
and 7.10).
Each of these functions can be given an array name as an optional second
argument. If an array name is supplied, the array will contain the number of
files as its 0th element, and the filenames in elements 1 through last. If
the array already existed, its previous contents are lost. For example, if
the current directory contains two files, oofa.txt and foo.bar, then
"ffiles(*,&a)" creates an array &a[] with a dimension of 2, containing the
following elements:
&a[0] = 2
&a[1] = oofa.txt
&a[2] = foo.bar
If no files match the specification given in the first argument, the array
gets a dimension of 0, which is the same as undeclaring the array.
Note that the order in which the array is filled (and in which fnextfile()
returns filenames) is indeterminate (but see Section 7.10.5).
Here's an example that builds and prints a list of all the file whose names
end in .txt in the current directory and all its descendents:
asg %n frfiles(*.txt)
declare &a[%n]
for %i 1 %n 1 {
asg &a[%i] fnextfile()
echo flpad(%i,4). "&a[%i]"
}
Alternatively, using the array method, and then printing the filenames in
alphabetic order (see Sections 7.10.3 and 7.10.5):
asg %n frfiles(*.txt,&a)
sort &a
for %i 1 %n 1 {
echo flpad(%i,4). "&a[%i]"
}
Or even more simply:
asg %n frfiles(*.txt,&a)
sort &a
show array &a
As noted elsewhere, the file lists built by ffiles(), frfiles(), etc, are
now "safe" in the sense that SEND and other file-related commands can
reference fnextfile() without resetting the list:
set send pathnames relative
for %i 1 frfiles(*.txt) 1 {
asg %a fnextfile()
echo Sending %a...
send %a
if fail break
}
Copying to an array (as shown on p.398 of "Using C-Kermit" 2nd Ed) is no
longer necessary.
4.11.5. Moving Directory Trees Between Like Systems
4.11.5.1. UNIX to UNIX
Transferring a directory tree from one computer to another replicates the file
sender's arrangement of files and directories on the file receiver's computer.
Normally this is done using relative pathnames, since the user IDs might not
be identical on the two computers. Let's say both computers are UNIX based,
running C-Kermit 7.0 or later. On the sending computer (leaving out the
connection details, etc):
C-Kermit> cd /usr/olga
C-Kermit> send /recursive .
The /RECURSIVE switch tells C-Kermit to descend through the directory tree
and to include relative pathnames on outbound filenames.
On the receiving computer:
C-Kermit> mkdir olgas-files ; Make a new directory.
C-Kermit> cd olgas-files ; CD to it.
C-Kermit> receive /recursive ; = /PATHNAMES:RELATIVE
Each Kermit program recognizes that the other is running under UNIX and
switches to binary mode and literal filenames automatically. Directories
are automatically created on the receiving system as needed. File dates
and permissions are automatically reproduced from source to destination.
4.11.5.2. VMS to VMS
To send recursively from VMS, simply include the /RECURSIVE switch, for
example at the sender:
$ kermit
C-Kermit> cd [olga]
C-Kermit> send /recursive *.*;0
And at the receiver:
C-Kermit> cd [.olga]
C-Kermit> receive /recursive
The notation "..." within directory brackets in VMS means "this directory
and all directories below it"; the /RECURSIVE switch, when given to the
sender, implies the use of "..." in the file specification so you don't have
to include "..."; but it makes no difference if you do:
$ kermit
C-Kermit> send /recursive [olga...]*.*;0
And at the receiver:
C-Kermit> cd [.olga]
C-Kermit> receive /recursive
In either case, since both systems recognize each other as VMS, they switch
into LABELED transfer mode automatically.
4.11.6. Moving Directory Trees Between Unlike Systems
There are several difficulties with recursive transfers between unlike
systems:
. File formats can be different, especially text files character sets and
record formats. This can now be handled by using SET FILE PATTERN,
SET FILE TEXT-PATTERNS, and SET FILE BINARY-PATTERNS (Section 4.3).
. File naming conventions are different. For example, one system might allow
(and use) longer filenames than the other. You can tell Kermit how to
handle file names with the normal "set file names" and "set file
collision" mechanisms. Most modern Kermits are fairly tolerant of illegal
filenames and should not fail simply because of an incoming filename;
rather, it will do its best to convert it to a recognizable and unique
legal filename.
. Directory notations can be different, e.g. backslashes instead of slashes,
brackets, parentheses, spaces, etc. But this is now handled by converting
pathnames to a standard format during transfer (Section 4.10).
So now, for the first time, it is possible to send directory trees among
any combination of UNIX, DOS, Windows, OS/2, VMS, AOS/VS, etc. Here's an
example sending files from an HP-UX system (where text files are encoded in
the HP Roman8 character set) to a PC with K95 (where text files are encoded
in CP850):
Sender:
cd xxx ; CD to root of source tree
set file type binary ; Default transfer mode
set file character-set hp-roman8 ; Local character set for text files
set xfer character-set latin1 ; Transfer character set
set file patterns on ; Enable automatic file-type switching...
set file binary-patterns *.Z *.gz *.o ; based on these patterns...
set file text-patterns *.txt *.c *.h ; for binary and text files.
send /recursive * ; Send all the file in this directory tree
Receiver:
cd yyy ; CD to root of destination tree
set file character-set cp850 ; Local character set for text files
receive /pathnames:relative ; Receive with pathnames
Notes:
. Replace "xxx" and "yyy" with the desired directories.
. Replace the file character sets appropriately.
. Change the patterns as needed (or just use the built-in default lists).
. SEND /RECURSIVE also implies /PATHNAMES:RELATIVE.
. The file sender tells the file receiver the transfer mode of each file.
. The file sender tells the file receiver the transfer character set.
. By default, destination file dates will be the same as on the source.
. Many of the settings shown might already be set by default.
. See sections 4.3, 4.10, and 4.15 for additional explanation.
If you are refreshing an existing directory on the destination computer,
use "set file collision update" or other appropriate file collision option
to handle filename collisions.
4.12. Where Did My File Go?
Now that Kermit can be started by clicking on desktop icons (thus obscuring
the concept of "current directory"), and can have a download directory, and
can create directories for incoming files on the fly, etc, sometimes it is
easy to lose a file after transfer. Of course, if you keep a transaction log:
LOG TRANSACTIONS
it will record the fate and final resting place of each file. But in case
you did not keep a log, the new command:
WHERE
added in C-Kermit 7.0, gives you as much information as it has about the
location of the last files transferred, including the pathname reported by
the receiving Kermit, if any, when C-Kermit is the sender. This information
was also added to SHOW FILE in somewhat less detail.
4.13. File Output Buffer Control
(UNIX only). The new command SET FILE OUTPUT lets you control how incoming
files are written to disk:
SET FILE OUTPUT BUFFERED [ <size> ]
Chooses buffered file output; this is the default. UNIX does its normal
sort of disk buffering. The optional <size> specifies Kermit's own file
output buffer size, and therefore the frequency of disk accesses (write()
system calls) -- the bigger the size, the fewer the disk accesses.
SET FILE OUTPUT UNBUFFERED [ <size> ]
This forces each file output write() call to actually commit the data to
disk immediately. Choosing this option will usually slow file reception
down.
SET FILE OUTPUT BLOCKING
Write() calls should not return until they are complete. This is the normal
setting, and it lets Kermit detect disk-write errors immediately.
SET FILE OUTPUT NONBLOCKING
Write() calls should return immediately. This can speed up file reception,
but also delay the detection of disk-write errors.
Experimentation with these parameters should be harmless, and might (or might
not) have a perceptible, even dramatic, effect on performance.
4.14. Improved Responsiveness
In version 7.0, C-Kermit's file-transfer protocol engine has been tuned
for additional speed and responsiveness.
. Binary-mode transfers over 8-bit connections, a very common case, are
now handled in a special way that minimizes overhead.
. SET TRANSFER CRC-CALCULATION is now OFF by default, rather than ON.
(This affects only the overall per-transfer CRC, v(crc16), not the
per-packet CRCs)
. Connection loss during file transfer is now detected immediately in most
cases on Internet connections and on serial connections when CARRIER-WATCH
is not set to OFF.
4.15. DOUBLING AND IGNORING CHARACTERS FOR TRANSPARENCY
The following commands were added in 7.0, primarily to allow successful
file transfer through ARPAnet TACs and with Honeywell DPS6 systems, but can
be used in any setting where they might be needed:
SET SEND DOUBLE-CHAR { [ <char> [ <char> [ ... ] ] ], NONE }
Tells C-Kermit to double the specified characters (use decimal notation)
in packets that it sends. For example, if you are sending files through
a device that uses @ as an escape character, but allows you to send a
single copy of @ through by doubling it, use "set send double 64".
SET RECEIVE IGNORE-CHAR [ <char> [ <char> [ ... ] ] ]
Tells C-Kermit to ignore the specified character(s) in incoming packets.
Use this, for example, when something between the sender and receiver is
inserting linefeeds for wrapping, NULs for padding, etc.
4.16. New File-Transfer Display Formats
SET TRANSFER DISPLAY { BRIEF, CRT, FULLSCREEN, NONE, SERIAL }
BRIEF is the new one. This writes one line to the screen per file, showing
the file's name, transfer mode, size, the status of the transfer, and when the
transfer is successful, the effective data rate in characters per second (CPS).
Example:
SEND ckcfn3.o (binary) (59216 bytes): OK (0.104 sec, 570206 cps)
SEND ckcfns.o (binary) (114436 bytes): OK (0.148 sec, 772006 cps)
SEND ckcmai.c (text) (79147 bytes): OK (0.180 sec, 438543 cps)
SEND ckcmai.o (binary) (35396 bytes): OK (0.060 sec, 587494 cps)
SEND ckcnet.o (binary) (62772 bytes): REFUSED
SEND ckcpro.o (binary) (121448 bytes): OK (0.173 sec, 703928 cps)
SEND ckcpro.w (text) (63687 bytes): OK (0.141 sec, 453059 cps)
SEND makefile (text) (186636 bytes): OK (0.444 sec, 420471 cps)
SEND wermit (binary) (1064960 bytes): OK (2.207 sec, 482477 cps)
Note that transfer times are now obtained in fractional seconds, rather than
whole seconds, so the CPS figures are more accurate (the display shows 3
decimal places, but internally the figure is generally precise to the
microsecond).
4.17. New Transaction Log Formats
The new command:
SET TRANSACTION-LOG { VERBOSE, FTP, BRIEF [ <separator> ] }
lets you choose the format of the transaction log. VERBOSE (the default)
indicates the traditional format described in the book. BRIEF and FTP are
new. This command must be given prior to the LOG TRANSACTION command if a
non-VERBOSE type is desired.
4.17.1. The BRIEF Format
BRIEF chooses a one-line per file format suitable for direct importation into
databases like Informix, Oracle, or Sybase, in which:
. Each record has 8 fields.
. Fields are separated by a non-alphanumeric separator character.
. The default separator character is comma (,).
. Any field containing the separator character is enclosed in doublequotes.
. The final field is enclosed in doublequotes.
The fields are:
1. Date in yyyymmdd format
2. Time in hh:mm:ss format
3. Action: SEND or RECV
4. The local filename
5. The size of the file
6. The transfer mode (text, binary, image, labeled)
7. The status of the transfer: OK or FAILED
8. Additional status-dependent info, in doublequotes.
Examples:
20000208,12:08:52,RECV,/u/olga/oofa.txt,5246,text,OK,"0.284sec 18443cps"
20000208,12:09:31,SEND,/u/olga/oofa.exe,32768,binary,OK,"1.243sec 26362cps"
20000208,12:10:02,SEND,"/u/olga/a,b",10130,text,FAILED,"Refused: date"
Note how the filename is enclosed in doublequotes in the final example,
because it contains a comma.
To obtain BRIEF format, you must give the SET TRANSACTION-LOG BRIEF command
before the LOG TRANSACTIONS command. (If you give them in the opposite order,
a heading is written to the log by the LOG command.)
4.17.2. The FTP Format
SET TRANSACTION-LOG FTP (available only in UNIX) chooses a format that is
compatible with the WU-FTPD (Washington University FTP daemon) log, and so can
be processed by any software that processes the WU-FTPD log. It logs only
transfers in and out, both successful and failed (but success or failure is
not indicated, due to lack of a field in the WU-FTPD log format for this
purpose). Non-transfer events are not recorded.
Unlike other logs, the FTP-format transaction log is opened in append mode
by default. This allows you to easily keep a record of all your kermit
transfers, and it also allows the same log to be shared by multiple
simultaneous Kermit processes or (permissions permitting) users. You can, of
course, force creation of a new logfile by specifying the NEW keyword after
the filename, e.g.
log transactions oofa.log new
All records in the FTP-style log are in a consistent format. The first field
is fixed-length and contains spaces; subsequent fields are variable length,
contain no spaces, and are separated by one or more spaces. The fields are:
Timestamp
This is an asctime-style timestamp, example: "Wed Sep 16 20:19:05 1999"
It is always exactly 24 characters long, and the subfields are always in
fixed positions.
Elapsed time
The whole number of seconds required to transfer the file, as a string
of decimal digits, e.g. "24".
Connection
The name of the network host to which C-Kermit is connected, or the name
of the serial device through which it has dialed (or has a direct
connection), or "/dev/tty" for transfers in remote mode.
Bytes transferred
The number of bytes transferred, decimal digits, e.g. "1537904".
Filename
The name of the file that was transferred, e.g.
"/pub/ftp/kermit/a/README.TXT". If the filename contains any spaces or
control characters, each such character is replaced by an underscore ('_')
character.
Mode
The letter 'b' if the file was transferred in binary mode, or 'a'
if it was transferred in text (ASCII) mode.
Options
This field always contains an underscore ('_') character.
Direction
The letter 'o' if the file was transferred Out, and 'i' if the file was
transferred In.
User class
The letter 'r' indicates the file was transferred by a Real user.
User identification
The ID of the user who transferred the file.
Server identification
The string "kermit". This distinguishes a Kermit transfer log
record from a WU-FTPD record, which contains "ftp" in this field.
Authentication class
The digit '1' if we know the user's ID on the client system,
otherwise '0'. Currently, always '0'.
Authenticated user
If the authentication class is '1', this is the user's ID on the client
system. Otherwise it is an asterisk ('*'). Currently it is always an
asterisk.
Examples:
Thu Oct 22 17:42:48 1998 0 * 94 /usr/olga/new.x a _ i r olga kermit 0 *
Thu Oct 22 17:51:29 1998 1 * 147899 /usr/olga/test.c a _ o r olga kermit 0 *
Thu Oct 22 17:51:44 1998 1 * 235 /usr/olga/test.o b _ i r olga kermit 0 *
Fri Oct 23 12:10:25 1998 0 * 235 /usr/olga/x.ksc a _ o r olga kermit 0 *
Note that an ftp-format transaction log can also be selected on the Kermit
command line as follows:
kermit --xferfile:<filespec>
This is equivalent to:
SET TRANSACTION-LOG FTP
LOG TRANSACTIONS <filespec> APPEND
Conceivably it could be possible to have a system-wide shared Kermit log,
except that UNIX lacks any notion of an append-only file; thus any user who
could append to the log could also delete it (or alter it). This problem
could be worked around using setuid/setgid tricks, but these would most likely
interfere with the other setuid/setgid tricks C-Kermit must use for getting
at dialout devices and UUCP logfiles.
4.18. Unprefixing NUL
As of 6.1.193 Alpha.10, C-Kermit can finally send and receive file-transfer
packets in which NUL (ASCII 0) is unprefixed (no more NUL-terminated
packets!). NUL is, of course, extremely prevalent in binary files such as
executables, and this has been a significant source of packet overhead. For
example, when transferring itself (the SunOS C-Kermit executable) with minimal
prefixing and 9000-byte packets, we see:
File size: 1064960
Packet chars with 0 prefixed: 1199629 overhead = 12.65%
Packet chars with 0 unprefixed: 1062393 overhead = -0.03%
Transfer rates go up accordingly, not only because of the reduced amount of
i/o, but also because less computation is required on each end.
4.19. Clear-Channel Protocol
Now that C-Kermit itself is capable of sending and receiving any byte at all
on a clear channel (section 4.18), it is, for the first time, in a position to
negotiate a clear channel with the other Kermit, giving it permission (but not
requiring it) to unprefix any and all characters that it knows are safe. In
general this means all but the Kermit start-of-packet character (normally
Ctrl-A), Carriage Return (not only Kermit's end-of-packet character, but also
treated specially on Telnet NVT links), and IAC (255, also special to Telnet).
By default, C-Kermit will say it has a clear channel only if it has opened a
TCP socket. Since the Kermit program on the far end of a TCP/IP connection
generally does not know it has a TCP/IP connection, it will not announce a
clear channel unless it has been told to do so. The command is:
SET CLEAR-CHANNEL { ON, OFF, AUTO }
AUTO is the default, meaning that the clear-channel status is determined
automatically from the type of connection. ON means to announce a clear
channel, OFF means not to announce it. Use SHOW STREAMING (Section 4.20)
to see the current CLEAR-CHANNEL status. Synonym: SET CLEARCHANNEL.
CLEAR-CHANNEL is also set if you start C-Kermit with the -I switch (see
Section 4.20).
Whenever a clear channel is negotiated, the resulting control-character
unprefixing is "sticky"; that is, it remains in effect after the transfer so
you can use SHOW CONTROL to see what was negotiated.
You can also see whether a clear channel was negotiated in the STATISTICS
/VERBOSE Display.
The advantage of the clear channel feature is that it can make file transfers
go faster automatically. The disadvantage would be file-transfer failures if
the channel is not truly clear, for example if C-Kermit made a Telnet
connection to a terminal server, and then dialed out from there; or if
C-Kermit made an Rlogin connection to host and then made a Telnet connection
from there to another host. If a file transfer fails on a TCP/IP connection,
use SHOW CONTROL to check whether control characters became unprefixed as a
result of protocol negotiations, and/or SHOW STREAMING (Section 4.20) to see
if "clear-channel" was negotiated. If this happened, use SET CLEAR-CHANNEL
OFF and SET PREFIXING CAUTIOUS (or whatever) to prevent it from happening
again.
4.20. Streaming Protocol
A new Kermit protocol option called "streaming" was added in C-Kermit 7.0.
The idea is that if the two Kermit partners have a reliable transport (such as
TCP/IP or X.25) between them, then there is no need to send ACKs for Data
packets, or NAKs, since a reliable transport will, by definition, deliver all
packets in order and undamaged. On such a connection, streaming cuts down not
only on Kermit program overhead (switching back and forth between reading and
sending packets), but also tends to make the underlying transport use itself
more efficiently (e.g. by defeating the Nagle algorithm and/or Delayed ACK
stratagem of the TCP layer). Furthermore, it allows transfers to work
smoothly on extremely slow network congestions that would otherwise cause
timeouts and retransmissions, and even failure when the retry limit was
exceeded.
The trick is knowing when we can stream:
a. If C-Kermit has opened a TCP socket or X.25 connection, it offers stream.
b. If C-Kermit has been started with the -I (uppercase) option, or if it
has been told to SET RELIABLE ON, it offers to stream.
c. If C-Kermit is in remote mode, and has been told to SET RELIABLE AUTO
(or ON), it always offers to stream, and also always agrees to stream,
if the other Kermit offers. Unless you take explicit actions to override
the defaults, this allows the local Kermit (the one that made the
connection, and so knows whether it's reliable) to control streaming.
(Note that an offer to stream also results in a Clear-Channel announcement if
CLEAR-CHANNEL is set to AUTO; see Section 4.19.)
When BOTH Kermits offer to stream, then they stream; otherwise they don't.
Thus streaming-capable Kermit programs interoperate automatically and
transparently with nonstreaming ones. If the two Kermits do agree to stream,
you'll see the word "STREAMING" on the fullscreen file-transfer display in the
Window Slots field. You can also find out afterwards with the STATISTICS or
SHOW STREAMING commands.
WARNING: Automatic choice of streaming is based on the assumption of a
"direct" end-to-end network connection; for example, a Telnet or Rlogin
connection from host A to host B, and transferring files between A and
B. However, if your connection has additional components -- something
"in the middle" (B) that you have made a network connection to, which
makes a separate connection to the destination host (C), then you don't
really have a reliable connection, but C-Kermit has no way of knowing
this; transferring files between A and C will probably fail. In such
cases, you'll need to tell the *local* C-Kermit to "set reliable off"
before transferring files (it does no good to give this command to the
remote Kermit since the local one controls the RELIABLE setting).
Streaming is like using an infinite window size, with no timeouts and no
tolerance for transmission errors (since there shouldn't be any). It relies
on the underlying transport for flow control, error correction, timeouts, and
retransmission. Thus it is very suitable for use on TCP/IP connections,
especially slow or bursty ones, since Kermit's packet timeouts won't interfere
with the transfer -- each packet takes as long to reach its destination as it
takes TCP to deliver it. If TCP can't deliver the packet within its own
timeout period (over which Kermit has no control), it signals a fatal error.
Just like FTP.
Streaming goes much faster than non-streaming when a relatively small packet
length is used, and it tends to go faster than non-streaming with even the
longest packet lengths. The Kermit window size is irrelevant to streaming
protocol, but still might affect performance in small ways since it can result
in different paths through the code.
The definition of "reliable transport" does not necessarily demand 8-bit and
control-character transparency. Streaming can work with parity and/or
control-character prefixing just as well (but not as fast) as without them;
in such cases you can leave RELIABLE set to ON, but set CLEARCHANNEL and/or
PARITY appropriately.
Maximum performance -- comparable to and often exceeding FTP -- is achieved on
socket-to-socket connections (in which the considerable overhead of the
terminal driver and Telnet or Rlogin server is eliminated) with long packets
and the new "brief" file-transfer display (Section 4.16).
4.20.1. Commands for Streaming
SET RELIABLE { ON, OFF, AUTO }
SET RELIABLE ON tells Kermit that it has a reliable transport.
SET RELIABLE OFF tells Kermit the transport is not reliable.
SET RELIABLE AUTO tells Kermit that it should SET RELIABLE ON whenever
it makes a reliable connection (e.g. TELNET or SET HOST on a TCP/IP or
X.25 network), and when in remote mode it should believe the transport is
reliable if the other Kermit says it is during Kermit protocol negotiation.
AUTO is the default; the Kermit program that makes the connection knows
whether it is reliable, and tells the remote Kermit.
The RELIABLE setting has several effects, including:
. It can affect the timeouts used during normal ACK/NAK protocol.
. It can affect the clear-channel announcement.
. It can affect streaming.
If you TELNET or SET HOST somewhere, this includes an implicit SET RELIABLE ON
command. The -I command-line option is equivalent to SET RELIABLE ON.
Since SET RELIABLE ON (and -I) also implies SET CLEAR CHANNEL ON, you might
find that in certain cases you need to tell Kermit that even though the
connection is reliable, it doesn't have a clear channel after all:
SET CLEAR-CHANNEL OFF
SET PREFIXING CAUTIOUS ; or whatever...
You can control streaming without affecting the other items with:
SET STREAMING { ON, OFF, AUTO }
AUTO is the default, meaning streaming will occur if Kermit has made a TCP/IP
connection or if RELIABLE is ON (or it was started with the -I command line
option). OFF means don't stream; ON means offer to stream no matter what.
4.20.2. Examples of Streaming
Here we look at the use and behavior of streaming on several different kinds
of connections, and compare its performance with non-streaming transfers.
4.20.2.1. Streaming on Socket-to-Socket Connections
Here we get streaming automatically when both Kermit programs are capable of
it, since they both make socket connections. For example, on the far end:
C-Kermit> set host * 3000
C-Kermit> server
and on the near end:
C-Kermit> set host foo.bar.xyz.com 3000
(now give SEND and GET command)
All subsequent file transfers use streaming automatically.
Here are the results from 84 trials, run on a production network,
disk-to-disk, in which a 1-MB binary file (the SunOS C-Kermit Sparc
executable) was sent from a Sun Sparc-10 with SunOS 4.1.3 to an IBM Power
Server 850 with AIX 4.1, socket-to-socket, over a 10Mbps 10BaseT Ethernet,
using minimal control-character unprefixing, window sizes from 10 to 32, and
packet sizes from 1450 to 9010:
Streaming Nonstreaming
Max CPS 748955 683354
Min CPS 221522 172491
Mean CPS 646134 558680
Median CPS 678043 595874
Std Dev 101424 111493
Correlations:
CPS and window size: -0.036
CPS and packet length: 0.254
CPS and streaming: 0.382
Note that the relationship between streaming and throughput is significantly
stronger than that between CPS and window size or packet length.
Also note that this and all other performance measurements in this section
are snapshots in time; the results could be much different at other times when
the load on the systems and/or the network is higher or lower.
In a similar socket-to-socket trial, but this time over a wide-area TCP/IP
connection (from New York City to Logan, Utah, about 2000 miles), the
following results were obtained:
Streaming Nonstreaming
Max CPS 338226 318203
Min CPS 191659 132314
Mean CPS 293744 259240
Median CPS 300845 273271
Std Dev 41914 52351
Correlations:
CPS and window size: 0.164
CPS and packet length: 0.123
CPS and streaming: 0.346
4.20.2.2. Streaming on Telnet Connections
In this case the local copy of Kermit is told to TELNET or SET HOST, and so it
knows it has a reliable connection and -- unless it has been told not to --
will offer to stream, and the other Kermit program, since it has STREAMING set
to AUTO, agrees.
Since we have a reliable connection, we'll also get control-character
unprefixing automatically because of the new clear-channel protocol (Section
4.19).
Any errors that occur during streaming are fatal to the transfer. The
message is "Transmission error on reliable link". Should this happen:
a. Check the remote Kermit's flow control setting (SHOW COMMUNICATIONS).
If it is NONE, change it to XON/XOFF, or vice versa. If it is XON/XOFF
(or you just changed it to XOFF/XOFF), make sure the file sender is
prefixing the XON and XOFF characters. In the most drastic case, use
"set prefix all" to force prefixing of all control characters.
b. The remote Telnet server might chop off the 8th bit. In that case, tell
C-Kermit to "set parity space". Or, you might be able to force the
Telnet to allow eight-bit data by telling C-Kermit to "set telopt binary
request accept" -- that is, request the Telnet server to enter binary
mode, and accept binary-mode bids from the server.
c. The remote Telnet server might have a buffering limitation. If a and b
don't cure the problem, tell the file receiver to "set receive
packet-length 1000" (or other number -- use the largest one that works).
This too, is no different from the non-streaming case (more about this
in Section 4.20.2.3).
And remember you can continue interrupted binary-mode transfers where they
left off with the RESEND (= SEND /RECOVER) command.
Here are the figures for the same 84 trials between the same Sun and IBM
hosts as in 4.20.2.1, on the same network, but over a Telnet connection rather
than socket-to-socket:
Streaming Nonstreaming
Max CPS 350088 322523
Min CPS 95547 173152
Mean CPS 321372 281830
Median CPS 342604 291469
Std Dev 40503 29948
Correlations:
CPS and window size: 0.001
CPS and packet length: 0.152
CPS and streaming: 0.128
Here the effect is not as emphatic as in the socket-to-socket case, yet on
the whole streaming tends to be beneficial.
Additional measurements on HP-UX using C-Kermit 7.0 Beta.06:
Windowing Streaming
HP-UX 8->8 not tested 14Kcps
HP-UX 8->9 not tested 76Kcps
HP-UX 8->10 36Kcps 66Kcps
HP-UX 9->9 not tested 190Kcps
HP-UX 9->10 160Kcps 378Kcps
4.20.2.3. Streaming with Limited Packet Length
The IRIX telnet server (at least the ones observed in IRIX 5.3 and 6.2) does
not allow Kermit to send packets longer than 4096 bytes. Thus when sending
from IRIX C-Kermit when it is on the remote end of a Telnet connection, the
packet length must be 4K or less. Trials in this case (in which packet
lengths range from 1450 to 4000) show a strong advantage for streaming, which
would be evident in any other case where the packet length is restricted, and
stronger the shorter the maximum packet length.
Streaming Nonstreaming
Max CPS 426187 366870
Min CPS 407500 276517
Mean CPS 415226 339168
Median CPS 414139 343803
Std Dev 6094 25851
Correlations:
CPS and window size: 0.116
CPS and packet length: 0.241
CPS and streaming: 0.901
4.20.2.4. Streaming on Dialup Connections
Here "dialup" refers to a "direct" dialup connection, not a SLIP or PPP
connection, which is only a particular kind of TCP/IP connection.
Attempt this at your own risk, and then only if (a) you have error-correcting
modems, and (b) the connections between the modems and computers are also
error-free, perfectly flow-controlled, and free of interrupt conflicts.
Streaming can be used effectively and to fairly good advantage on such
connections, but remember that the transfer is fatal if even one error is
detected (also remember that should a binary-mode transfer fail, it can be
recovered from the point of failure with RESEND).
To use streaming on an unreliable connection, you must tell both Kermits that
the connection is reliable:
kermit -I
or:
C-Kermit> set reliable on
In this case, it will probably be necessary to prefix some control characters,
for example if your connection is through a terminal server that has an escape
character. Most Cisco terminal servers, for example, require Ctrl-^ (30, as
well as its high-bit equivalent, 158) to be prefixed. To unprefix these,
you'll need to defeat the "clear channel" feature:
C-Kermit> set reliable on
C-Kermit> set clear-channel off
C-Kermit> set prefixing none
C-Kermit> set control prefix 1 13 30 158 ; and whatever else is necessary
Dialup trials were done using fixed large window and packet sizes. They
compare uploading and downloading of two common types of files, with and
without streaming. Configuration:
HP-9000/715/33 -- 57600bps, RTS/CTS -- USR Courier V.34 -- V.34+V.42,
31200bps -- USR V.34+ Rackmount -- 57600bps, RTS/CTS -- Cisco terminal
server -- Solaris 2.5.1. Packet size = 8000, Window Size = 30, Control
Character Unprefixing Minimal (but including the Cisco escape character).
Since this is not a truly reliable connection, a few trials failed when a bad
packet was received (most likely due to UART overruns); the failure was
graceful and immediate, and the message was informative. The results of ten
successful trials uploading and downloading the two files with and without
streaming are:
Streaming..
Off On
Upload 5194 5565 txt (= C source code, 78K)
3135 3406 gz (= gzip file, compressed, 85K)
Download 5194 5565 txt
3041 3406 gz
Each CPS figure is the mean of 10 results.
A brief test was also performed on a LAT-based dialout connection from a VAX
3100 with VMS 5.5 to a USR Courier V.34 connected to a DECserver 700 at 19200
bps. The 1-MB Sparc executable downloaded from a Sun to the VAX at 1100cps
without streaming and 1900cps with streaming, using 8000-byte packets, 30
window slots, and minimal prefixing in both cases.
4.20.2.5. Streaming on X.25 Connections
We have only limited access to X.25 networks. One trial was performed in
which the 1MB Solaris 2.4 Sparc executable was transferred over a SunLink X.25
connection; nothing is known about the actual physical connection. With a
packet length of 8000 and a window size of 30, the file transferred at 6400
cps (using a maximum of 6 window slots). With the same packet length, but
with streaming, it transferred without mishap at 6710 cps, about 5% faster.
4.20.3. Streaming - Preliminary Conclusions
The results vary with the particular connection, but are good overall.
Although numerous lower-level tricks can be used to improve performance on
specific platforms or connection methods, streaming occurs at a high,
system-independent level of the Kermit protocol and therefore can apply to all
types of platforms and (reliable) connections transparently.
4.21. The TRANSMIT Command
Prior to C-Kermit 7.0, the TRANSMIT command transmitted in text or binary
mode according to SET FILE TYPE { TEXT, BINARY }. But now that binary mode
is likely to be the default for protocol transfers, it is evident that this
not also an appropriate default for TRANSMIT, since binary-mode TRANSMIT is
a rather specialized and tricky operation. Therefore, TRANSMIT defaults to
text mode always, regardless of the FILE TYPE setting.
C-Kermit 7.0 expands the capabilities of the TRANSMIT command by adding the
following switches (see Section 1.5). The new syntax is:
TRANSMIT [ switches... ] filename
Zero or more switches may be included:
/PIPE
When /PIPE is included, "filename" is interpreted as a system command
or program whose output is to be sent. Synonym: /COMMAND. Example:
transmit /pipe finger
You may enclose the command in braces, but you don't have to:
xmit /pipe {ls -l | sort -r +0.22 -0.32 | head}
/BINARY
Transmits the file (or pipe output) in binary mode.
/TEXT
Transmits the file (or pipe output) in line-oriented text mode.
Current FILE CHARACTER-SET and TERMINAL CHARACTER-SET selections govern
translation. Default.
/TRANSPARENT
Specifies text mode without character-set translation, no matter what the
FILE and TERMINAL CHARACTER-SET selections are.
/NOWAIT
This is equivalent to SET TRANSMIT PROMPT 0, but for this TRANSMIT command
only. Applies only to text mode; it means to not wait for any kind of
echo or turnaround character after sending a line before sending the next
line. (Normally Kermit waits for a linefeed.)
When TRANSMIT ECHO is ON, C-Kermit tries to read back the echo of each
character that is sent. Prior to C-Kermit 7.0, 1 second was allowed for each
echo to appear; if it didn't show up in a second, the TRANSMIT command would
fail. Similarly for the TRANSMIT PROMPT character. However, with today's
congested Internet connections, etc, more time is often needed:
SET TRANSMIT TIMEOUT <number>
Specifies the number of seconds to wait for an echo or the prompt character
when TRANSMIT PROMPT is nonzero; the default wait is 1 second. If you
specify 0, the wait is indefinite. When a timeout interval of 0 is
specified, and a desired echo or prompt does not show up, the TRANSMIT
command will not terminate until or unless you interrupt it with Ctrl-C;
use SET TRANSMIT TIMEOUT 0 with caution.
Note: to blast a file out the communications connection without any kind of
synchronization or timeouts or other manner of checking, use:
SET TRANSMIT ECHO OFF
SET TRANSMIT PROMPT 0 (or include the /NOWAIT switch)
SET TRANSMIT PAUSE 0
TRANSMIT [ switches ] <filename>
In this case, text-file transmission is not-line oriented and large blocks
can be sent, resulting in a significant performance improvement over
line-at-at-time transmission. Successful operation depends (even more than
usual for the TRANSMIT command!) on a clean connection with effective flow
control.
For details on TRANSMIT and character sets, see Section 6.6.5.4.
4.22. Coping with Faulty Kermit Implementations
Kermit protocol has been implemented in quite a few third-party commercial,
shareware, and freeware software packages, with varying degrees of success.
In most cases operation is satisfactory but slow -- only the bare minimum
subset of the protocol is available -- short packets, no sliding windows,
no attributes, etc. In other cases, the implementation is incorrect,
resulting in failures at the initial negotiation stage or corrupted files.
C-Kermit 7.0 and Kermit 95 1.1.18 include some new defense mechanisms to
help cope with the most common situations. However, bear in mind there is
only so much we can do in such cases -- the responsibility for fixing the
problem lies with the maker of the faulty software.
4.22.1. Failure to Accept Modern Negotiation Strings
The published Kermit protocol specification states that new fields can be
added to the parameter negotiation string. These are to be ignored by any
Kermit implementation that does not understand them; this is what makes the
Kermit protocol extensible. Unfortunately, some Kermit implementations become
confused (or worse) when receiving a negotiation string longer than the one
they expect. You can try working around such problems by telling Kermit to
shorten its negotiation string (and thus disable the corresponding new
features):
SET SEND NEGOTIATION-STRING-MAX-LENGTH number
Try a number like 10. If that doesn't work, try 9, 8, 7, 6, and so on.
4.22.2. Failure to Negotiate 8th-bit Prefixing
The published Kermit protocol specification states that 8th-bit prefixing
(which allows transfer of 8-bit data over a 7-bit connection) occurs if the
file sender puts a valid prefix character (normally "&") in the 8th-bit-prefix
field of the negotiation string, and the receiver puts either a letter "Y" or
the same prefix character. At least one faulty Kermit implementation exists
that does not accept the letter "Y". To force C-Kermit / K-95 to reply with
the other Kermit's prefix character rather than a "Y", give the following
(invisible) command:
SET Q8FLAG ON
Use SET Q8FLAG OFF to restore the normal behavior.
4.22.3. Corrupt Files
Refer to Section 4.22.2. Some Kermit implementations mistakenly interpret the
"Y" as a prefix character. Then, whenever a letter Y appears in the data, the
Y and the character that follows it are replaced by a garbage character. At
this writing, we are not sure if there is any solution, but try "set send
negotiation-string-max-length 6" and/or "set q8flag on".
File corruption can also occur when control characters within the file data
are sent without prefixing, as at least some are by default in C-Kermit 7.0
and K-95. Some Kermit implementations do not handle incoming "bare" control
characters. To work around, "set prefixing all".
4.22.4. Spurious Cancellations
The Kermit protocol specification states that if an ACK to a Data packet
contains X in its data field, the transfer of the current file is canceled,
and if it contains a Z, the entire transfer is canceled. At least one
overzealous Kermit implementation applies this rule to non-Data packets as
well, the typical symptom being that any attempt to transfer a file whose name
begins with X or Z results in cancellation. This is because the file receiver
typically sends back the name under which it stored the file (which might not
be the same as the name it was sent with) in the ACK to the File Header
packet. This is information only and should not cause cancellation. To work
around the problem, use:
SET F-ACK-BUG { ON, OFF }
ON tells Kermit not to send back the filename in the ACK to the file header
packet as it normally would do (OFF puts Kermit back to normal after using ON).
A variation on the this bug occurs in an obscure Kermit program for MUMPS:
When this Kermit program sends a file called (say) FOO.BAR, it requires that
the ACK to its F packet contain exactly the same name, FOO.BAR. However,
C-Kermit likes to send back the full pathname, causing the MUMPS Kermit to
fail. SET F-ACK-BUG ON doesn't help here. So a separate command has been
added to handle this situation:
SET F-ACK-PATH { ON, OFF }
Normally it is ON (regardless of the SET SEND PATHNAMES setting). Use
SET F-ACK-PATH OFF to instruct Kermit to send back only the filename without
the path in the ACK to the F packet.
4.22.5. Spurious Refusals
Some Kermit implementations, notably PDP-11 Kermit 3.60 and earlier, have bugs
in their handling of Attribute packets that can cause unwarranted refusal of
incoming files, e.g. based on date or size. This can be worked around by
telling one or both of the Kermit partners to:
SET ATTRIBUTES OFF
4.22.6. Failures during the Data Transfer Phase
This can be caused by control-character unprefixing (Section 4.22.3), and
fixed by:
SET PREFIXING ALL
It can also have numerous other causes, explained in Chapter 10 of "Using
C-Kermit": the connection is not 8-bit transparent (so use "set parity space"
or somesuch), inadequate flow control, etc. Consult the manual.
4.22.7. Fractured Filenames
At least one well-known PC-based communications package negotiates data
compression, which (according to the protocol specification) applies to both
the filename and the file data, but then fails to decompress the filename.
Example: C-Kermit sends a file called R000101.DAT (where 000101 might be
non-Y2K-wise YYMMDD notation), and the package in question stores the files
as R~#0101.DAT. Workaround: Tell C-Kermit to SET REPEAT COUNTS OFF.
4.22.8. Bad File Dates
At least one well-known PC-based communications package negotiates the
passing of file timestamps from sender to receiver, but when it is sending
files, it always gives them a timestamp of 1 February 1970. Workaround:
tell C-Kermit to SET ATTRIBUTE DATE OFF. You don't get the file's real date,
but you also don't get 1 Feb 1970; instead the file gets the current date
and time.
4.23. File Transfer Recovery
Prior to C-Kermit 7.0, RESEND (SEND /RECOVER) and REGET (GET /RECOVER) refused
to work if FILE TYPE was not BINARY or the /BINARY switch was not included.
Now these commands include an implied /BINARY switch, meaning they set the
file type to binary for the duration of the command automatically.
In the client/server arrangement, this also forces the server into binary
mode (if it is C-Kermit 7.0 or greater, or K95 1.1.18 or greater) so the
recovery operation proceeds, just as you asked and expected.
BUT... Just as before, the results are correct only under the following
conditions:
. If the prior interrupted transfer was also in binary mode; or:
. If the prior transfer was in text mode and the other computer was
a "like platform" (e.g. UNIX-to-UNIX, Windows-to-Windows, DOS-to-Windows)
AND there was no character-set translation (i.e. TRANSFER CHARACTER-SET
was TRANSPARENT).
Note that these circumstances are more likely to obtain in C-Kermit 7.0,
in which:
. The default FILE TYPE in C-Kermit 7.0 is BINARY.
. The default FILE INCOMPLETE setting is AUTO, which means KEEP if the
transfer is in binary mode, DISCARD otherwise.
. C-Kermit 7.0, Kermit 95 1.1.17, and MS-DOS Kermit 3.15 and later can
recognize "like platforms" and switch into binary mode automatically.
Transfers between like platforms are always binary unless character-set
translation has been requested, and then is still binary for all files
whose names match a binary pattern, unless the automatic mechanisms
have been disabled (with a /TEXT switch, or with SET TRANSFER MODE
MANUAL).
. SEND /BINARY and GET /BINARY always force binary-mode transfers,
even when FILE TYPE is TEXT, even when TRANSFER MODE is AUTOMATIC,
even when PATTERNS are ON and the file's name matches a text pattern.
But also note that the automatic client/server transfer-mode adjustments
do not work with versions of C-Kermit prior to 7.0 or K95 prior to 1.1.16.
If the prior transfer was in text mode:
. If text-mode transfers between the two platforms are "length-changing"
(as they are between UNIX -- which terminates text lines with LF -- and
DOS or Windows -- which terminates text lines with CRLF), the recovered
file will be corrupt.
. If text-mode transfers between the two platforms are not length-changing,
but character-set translation was active in the prior transfer, the result
will be a file in which the first part has translated characters and the
second part does not.
But in C-Kermit 7.0 and K95 1.1.18 and later, incompletely transferred text
files are not kept unless you change the default. But if you have done this,
and you have an incompletely transferred text file, you'll need to:
. Transfer the whole file again in text mode, or:
. Use SEND /STARTING-AT: to recover the transfer at the correct point;
but you have to find out what that point is, as described in the
manual.
Kermit has no way of knowing whether the previous transfer was in text or
binary mode so it is your responsibility to choose the appropriate recovery
method.
If you use C-Kermit to maintain parallel directories on different computers,
using SET FILE COLLISION to transfer only those files that changed since last
time, and the files are big enough (or the connection slow enough) to require
SEND /RECOVER to resume interrupted transfers, you should remember that SEND
/RECOVER (RESEND) overrides all FILE COLLISION settings. Therefore you
should use SEND /RECOVER (RESEND) only on the file that was interrupted, not
the file group. For example, if the original transfer was initiated with:
SEND *
and was interrupted, then after reestablishing your connection and starting
the Kermit receiver with SET FILE COLLISION UPDATE on the remote end, use the
following sequence at the sender to resume the transfer:
SEND /RECOVER <name-of-interrupted-file>
and then:
SEND *
(In C-Kermit 7.0 and later, v(filename) contains the name of the file
most recently transferred, as long you have not EXITed from Kermit or
changed directory, etc.
4.24. FILE COLLISION UPDATE Clarification
In UNIX, file modification dates are used when comparing the file date with
the date in the attribute packet. In VMS, however, the file creation date
is used. These two policies reflect the preferences of the two user
communities.
Also, remember that the file date/time given in the attribute packet is the
local time at the file sender. At present, no timezone conversions are
defined in or performed by the Kermit protocol. This is primarily because
this feature was designed at a time when many of the systems where Kermit runs
had no concept of timezone, and therefore would be unable to convert (say,
to/from GMT or UTC or Zulu time).
As a consequence, some unexpected results might occur when transferring files
across timezones; e.g. commands on the target system that are sensitive to
file dates might work (UNIX "make", backups, etc).
Timezone handling is deferred for a future release.
4.25. Autodownload Improvements
Refer to pages 164-165 of "Using C-Kermit" about the hazards of autodownload
when C-Kermit is "in the middle". As of C-Kermit 7.0, no more hazards. If
C-Kermit has TERMINAL AUTODOWNLOAD ON and it detects a packet of the current
protocol type (Kermit or Zmodem), it "erases" the visual aspect of the packet
that would be seen by the terminal (or, more to the point, the emulator, such
as K95). This way, only C-Kermit goes into RECEIVE mode, and not also the
terminal emulator through which C-Kermit is accessed. And therefore, it is no
longer necessary to SET TERMINAL AUTODOWNLOAD OFF to prevent multiple Kermits
from going into receive mode at once, but of course it is still necessary to
ensure that, when you have multiple Kermits in a chain, that the desired one
receives the autodownload.
The defaults have not been changed; Kermit 95 still has autodownload ON by
default, and C-Kermit has it OFF by default.
(5) CLIENT/SERVER
5.0. Hints
If you use SET SERVER GET-PATH to set up your server, and the GET-PATH does
not include the server's current directory, clients can become quite confused.
For example, "remote dir oofa.txt" shows a file named oofa.txt, but "get
oofa.txt" fails. In this situation, you should either DISABLE DIR or make
your GET-PATH include the current directory.
5.1. New Command-Line Options
The -G command-line option is like -g (GET), except the incoming file is
sent to standard output rather than written to disk.
The -I option ("Internet") is used to tell a remote C-Kermit program that you
are coming in via Internet Telnet or Rlogin and therefore have a reliable
connection. The -I option is equivalent to SET RELIABLE ON and SET FLOW
NONE.
The -O option ("Only One") tells C-Kermit to enter server mode but then exit
after the first client operation.
See section 9.3 for details.
5.2. New Client Commands
BYE and FINISH no longer try to do anything if a connection is not active.
Thus a sequence like "hangup" followed by "bye" or "finish" will no longer get
stuck in a long timeout-and-retransmission cycle, nor will it try to open a
new connection.
REMOTE EXIT
Similar to FINISH, except it ensures that the Kermit server program exits
back to the operating system or shell prompt. (FINISH would return it to
its interactive prompt if it was started in interactive mode, and would
cause it to exit if it entered server mode via command-line option.) When
C-Kermit is to be the server, you can use { ENABLE, DISABLE } EXIT to
control the client's access to this feature.
REMOTE MKDIR <directory-name>
Tells the client to ask the server to create a directory with the given
name, which can be absolute or relative. The syntax of the directory name
depends on the Kermit server (see next section); in all cases, it can be in
the syntax of the system where the server is running (UNIX, VMS, DOS, etc)
but newer servers also accept UNIX syntax, no matter what the underlying
platform. The server will not execute this command if (a) it does not
understand it, (b) a DISABLE MKDIR command has been given, or (c) a DISABLE
CWD command has been given; otherwise, the command is executed, but will
fail if the directory can not be created, in which cases most servers will
attempt to return a message giving the reason for failure. The REMOTE MKDIR
command succeeds if the remote directory is created, or if it already exists
and therefore does not need to be created, and fails otherwise.
REMOTE RMDIR <directory-name>
Tells the client to ask the server to remove (delete) a directory with the
given name. The same considerations apply as for REMOTE MKDIR.
REMOTE SET FILE INCOMPLETE { DISCARD, KEEP, AUTO }
Previously this was only available in its earlier form, REMOTE SET
INCOMPLETE (no FILE). The earlier form is still available, but invisible.
Also, AUTO was added, meaning KEEP if in binary mode, DISCARD otherwise.
REMOTE SET TRANSFER MODE { AUTOMATIC, MANUAL }
Tells the client to ask the server to set the given file-transfer mode.
Automatic means (roughly): if the client and the server are running on the
same kind of computer (e.g. both are on UNIX), then use binary mode
automatically; if the system types are different, use some other method
to automatically determine text or binary mode, such as filename pattern
matching. MANUAL means, in this context, obey the client's FILE TYPE
setting (TEXT or BINARY). Synonym: REMOTE SET XFER MODE ...
[ REMOTE ] QUERY KERMIT function(args...)
Prior to C-Kermit 7.0, the arguments were not evaluated locally. Thus it
was not possible to have the server run the function with client-side
variables as arguments. Now:
define %a oofa.*
remote query kermit files(%a) ; Client's %a
remote query kermit files(\%a) ; Server's %a
[ REMOTE ] LOGIN [ <user> [ <password ] ]
LOGIN is now a synonym for REMOTE LOGIN.
LOGOUT
This command, when given in local mode, is equivalent to REMOTE LOGOUT.
When given at the IKSD prompt, it logs out the IKSD. When given at the
C-Kermit prompt when it has no connection, it does nothing.
Note that in C-Kermit 7.0, the REMOTE (or R) prefix is not required for QUERY,
since there is no local QUERY command. The new top-level QUERY command does
exactly what REMOTE QUERY (RQUERY) does.
All REMOTE commands now have single-word shortcuts:
Shortcut Full Form
RASG REMOTE ASSIGN
RCD REMOTE CD
RCOPY REMOTE COPY
RDEL REMOTE DELETE
RDIR REMOTE DIRECTORY
REXIT REMOTE EXIT
RHELP REMOTE HELP
RHOST REMOTE HOST
RPWD REMOTE PWD
RSET REMOTE SET
etc.
The R prefix is not applied to LOGIN because there is already an RLOGIN
command with a different meaning. It is not applied to LOGOUT either, since
LOGOUT knows what to do in each case, and for symmetry with LOGIN.
5.2.1. Remote Procedure Definitions and Calls
This is nothing new, but it might not be obvious... REMOTE ASSIGN and REMOTE
QUERY may be used to achieve remote procedure execution. The remote procedure
can be defined locally or remotely.
A remote procedure call is accomplished as noted in the previous section:
[ remote ] query kermit function-name(args...)
This invokes any function that is built in to the Kermit server, e.g.:
[ remote ] query kermit size(foo.bar)
returns the size of the remote file, foo.bar.
Now note that C-Kermit includes an fexecute() function, allowing it to
execute any macro as if it were a built-in function. So suppose MYMACRO
is the name of a macro defined in the server. You can execute it from
the client as follows (the redundant "remote" prefix is omitted in the
remaining examples):
query kermit execute(mymacro arg1 arg2...)
The return value, if any, is the value of the RETURN command that terminated
execution of the macro, for example:
define addtwonumbers return feval(%1+%2)
The client invocation would be:
query kermit execute(addtwonumbers 3 4)
7
The result ("7" in this case) is also assigned to the client's v(query)
variable.
To execute a remote system command or command procedure (shell script, etc)
use:
query kermit command(name args...)
Finally, suppose you want the client to send a macro to the server to be
executed on the server end. This is done as follows:
remote assign macroname definition
query kermit execute(macroname arg1 arg2...)
Quoting is required if the definition contains formal parameters.
5.3. New Server Capabilities
5.3.1. Creating and Removing Directories
The C-Kermit 7.0 server responds to REMOTE MKDIR and REMOTE RMDIR commands.
The directory name may be in either the native format of the server's
computer, or in UNIX format. For example, a server running on VMS with a
current directory of [IVAN] can accept commands from the client like:
remote mkdir olga ; Makes [IVAN.OLGA] (nonspecific format)
remote mkdir .olga ; Makes [IVAN.OLGA] (VMS format without brackets)
remote mkdir olga/ ; Makes [IVAN.OLGA] (UNIX relative format)
remote mkdir /ivan/olga ; Makes [IVAN.OLGA] (UNIX absolute format)
remote mkdir [ivan.olga] ; Makes [IVAN.OLGA] (VMS absolute format)
remote mkdir [.olga] ; Makes [IVAN.OLGA] (VMS relative format)
5.3.1.1. Creating Directories
If a directory name is given that contains more than one segment that does not
exist, the server attempts to create all the segments. For example, if the
client says:
REMOTE MKDIR letters/angry
a "letters" subdirectory is created in the server's current directory if it
does not already exist, and then an "angry" subdirectory is created beneath
it, if it does not already have one. This can repeated to any reasonable
depth:
REMOTE MKDIR a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/z/y/z
5.3.1.2. Removing Directories
When attempting to execute a REMOTE RMDIR, the server can remove only a single
directory, not an entire sequence or tree. The system service that is called
to remove the directory generally requires not only that the server process
has write delete access, but also that the directory contain no files.
In the future, a REMOTE RMDIR /RECURSIVE command (and the accompanying
protocol) might be added. For now, use the equivalent REMOTE HOST command(s),
if any.
5.3.2. Directory Listings
Directory listings are generated by C-Kermit itself, rather than by running
the underlying system's directory command. Some control over the listing
format can be obtained with the SET OPTIONS DIRECTORY command (Section 4.5.1).
The following options affect listings sent by the server: /[NO]HEADING,
/[NO]DOTFILES, and /[NO]BACKUP. In UNIX and VMS, the listing is always sorted
by filename. There is, at present, no protocol defined for the client to
request listing options of the server; this might be added in the future.
The server's directory listings are in the following format:
Protection or permissions:
In UNIX and OS-9, this is a 10-character field, left adjusted. In VMS it
is a 22-character field, left-adjusted. In each case, the protection /
permission codes are shown in the server platform's native format. In
other operating systems, this field is not shown.
Size in bytes:
This is always a 10-character field. The file's size is shown as a decimal
number, right adjusted in the field. If the file is a directory and its
size can not be obtained, the size is shown as "<DIR>". Two blanks follow
this field.
Date:
Always in yyyy-mm-dd hh:mm:ss numeric format, and therefore 19 characters
long. If the file's date/time can't be obtained, zeros (0) are shown for
all the digits. This field is followed by two blanks.
Filename:
This field extends to the end of the line. Filenames are shown relative
to the server's current directory. In UNIX, symbolic links are shown as
they are in an "ls -l" listing as "linkname -> filename".
In UNIX and VMS, listings are returned by the server in alphabetical order of
filename. There are presently no other sort or selection options.
However, since these are fixed-field listings, all fields can be used as
sort keys by external sort programs. Note, in particular, that the format
used for the date allows a normal lexical on that field to achieve the date
ordering. For example, let's assume we have a UNIX client and a UNIX server.
In this case, the server's listing has the date in columns 22-40, and thus
could be sorted by the UNIX sort program using "sort +0.22 -0.40" or in
reverse order by "sort +0.22 -0.40r".
Since the UNIX client can pipe responses to REMOTE commands through filters,
any desired sorting can be accomplished this way, for example:
C-Kermit> remote directory | sort +0.22 -0.40
You can also sort by size:
C-Kermit> remote directory | sort +0.11 -0.19
You can use sort options to select reverse or ascending order. "man sort"
(in UNIX) for more information. And of course, you can pipe these listings
through any other filter of your choice, such as grep to skip unwanted lines.
5.4. Syntax for Remote Filenames with Embedded Spaces
C-Kermit and K95, when in server mode, assume that any spaces in the file
specification in an incoming GET command are filename separators. Thus if
the client gives a command like:
get {oofa.txt oofa.bin}
or, equivalently:
mget oofa.txt oofa.bin
the server tries to send the two files, oofa.txt and oofa.bin. But what if
you want the server to send you a file named, say:
D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL
How does the server know this is supposed to be one file and not seven?
In this case, you need to the send file name to the server enclosed in either
curly braces:
{D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL}
or ASCII doublequotes:
"D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL"
The method for doing this depends on your client. If your client is C-Kermit
7.0, any recent version of Kermit 95, or MS-DOS Kermit 3.16, then you have
to enclose the name in braces just so the client can parse it, so to send
braces or doublequotes to the server, you must put them inside the first,
outside pair of braces. And you also need to double the backslashes to
prevent them from being interpreted:
get {{D:\HP OfficeJet 500\Images\My Pretty Picture Dot PCL}}
get {"D:\HP OfficeJet 500\Images\My Pretty Picture Dot PCL"}
To get around the requirement to double backslashes in literal filenames,
of course you can also use:
set command quoting off
get {{D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL}}
get {"D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL"}
set command quoting on
If you are giving a "kermit" command to the UNIX shell, you have to observe
the shell's quoting rules, something like this:
kermit -ig "{D:HP OfficeJet 500ImagesMy Pretty Picture Dot PCL}"
Here, the quotes go on the outside so UNIX will pass the entire filename,
spaces, braces, and all, as a single argument to Kermit, and the backslashes
are not doubled because (a) the UNIX shell ignores them since they are in a
quoted string, and (b) Kermit ignores them since the interactive command parser
is not activated in this case.
5.5. Automatic Orientation Messages upon Directory Change
C-Kermit 7.0, when acting as a server, can send an orientation message to
the client whenever the server directory changes. For example, when the
client gives a REMOTE CD command, the server sends the contents of the
new directory's "Read Me" file to the client's screen. The following commands
govern this feature:
SET SERVER CD-MESSAGE FILE <name>
Given to the servr, allows the message-file name to be specified at runtime.
A list of names to look for can be given in the following format:
{{name1}{name2}{name3}{...}}