File ktfc0d5.txt, copyright (C) Peter Lyall Easthope, 2000.
All rights reserved.
** Contents
What is it?
Benefits of using KTFC
Disclaimer
Requirements
What is in the package?
How do I get KTFC?
Installation
User Configuration
Sending a message
Receiving a message
Signature Lines
Serial Port Problems
Tidying the Mailbox
Scanning Other Conferences
Automated Startup
FAQs
System Specific Notes
Macintosh
Microsoft Windows
MS-DOS
Oberon
Unixes and other systems running C-Kermit
Bugs
Limitations
Support
References
Conditions of Use
Fee
Registration
Thanks
History
Trademarks
** What is it?
KTFC is the acronym for "Kermit To FirstClass". See references
1 and 2 below. KTFC is also the name of a script set which
allows Kermit to communicate automatically with a FirstClass
Server.
** Benefits of using KTFC
- Kermit works on many systems including MS-DOS, MS Windows
and unixes. KTFC has the potential to work with any Kermit
which has script processing at least as good as MS-DOS Kermit
3.1.6. See System Specific Notes and reference 1.
- Messages are read and composed off line using a text editor.
- Options for user configuration are set by switches which are
easily changed with a text editor.
- Signature lines can be appended to a message automatically.
- User confirmation before sending a message and before deleting
an old message from the server is optional.
- Messages can be read from directories other than the
Mailbox---a directory in OneNet for example.
- The KTFC scripts in their entirety are accessible to user
customization.
** Disclaimer
This software is provided "as is" without express or implied
warranty.
The author disclaims all warranties with regard to this
software, including all implied warranties of merchantability
and fitness. In no event shall the author be liable for any
special, indirect or consequential damages or any damages
whatsoever resulting from loss of use, data or profits, whether
in an action of contract, negligence or other tortious action,
arising out of or in connection with the use or performance of
this software.
The author may change the software and documentation and issue a
revision at any time without prior notice.
** Requirements
KTFC has been tested with MS-DOS Kermit 3.1.6 and FirstClass
Server 3.5.2. Kermit is available for many operating systems.
See reference 1 and System Specific Notes.
Installation and use of Kermit and KTFC require an editor. In
DOS, EDIT is recommended. Various text processors can also be
used. The vi and emacs editors are commonly used in unix
systems.
Before attempting to install KTFC the user should install Kermit
and configure it so that communication can be established with a
FirstClass server. Using the terminal emulator in Kermit, the
user should be able to log in to the server and to read and send
mail interactively. To allow the <delete> key on a PC to
produce a backspace in the FC Server task, the Kermit command
"set key \270 \8" should be issued---usually in the MSCUSTOM.INI
or .kermrc file.
** What is in the package?
The KTFC version 0.5 package comprises these 7 files. Each file
contains plain text.
datefil0.5 An auxiliary script; see Automated Startup below.
ktfc0d5.txt This file.
mailout File where outgoing messages are queued.
prolog0.5 The script containing the user configuration, the
login code and other procedures used by scan and sr.
readme.kfc A brief description of the package.
scan0.5 The script which reads the mailbox, deletes outdated
messages from the FC server and reads directories
other than the mailbox.
sr0.5 The script for sending and receiving messages.
The version number m.n is real. In the following discussions
the version number is omitted from the file name. Thus, a
mention of the file name prolog is really a reference to the
file prolog0.5.
** How do I get KTFC?
KTFC might be found on an Internet server or on your FirstClass
server.
If you find the 7 files on a ftp or iksd server transfer them to
your Kermit directory. If binary mode is used for the transfer,
the files will be received on your machine with the end-of-line
notation that they have on the server. If text mode is used for
the transfer, the end-of-line notation will be translated from
that on the server to that used in your system. Text mode is
appropriate, for example, if unix files are brought to a MS
Windows machine. Various utilities and editor capabilities can
also translate end-of-line notations.
Alternatively, get the MIME file ktfc0d5.64. This is a text
file which can be transmitted in an e-mail message. 0d5
represents the version number 0.5. The .64 extension on the
file name refers to MIME base64 encoding. Transfer this file to
your Kermit directory in text mode if you wish to use it.
Alternatively, get the ZIP file ktfc0d5.zip. Transfer this file
to your Kermit directory in binary mode if you wish to use it.
** Installation
The objective of installation is simply to have the 7 files of
the KTFC package in the Kermit directory with the correct
end-of-line notation for the system. These are a few system
specific notes.
*** MS-DOS
This is the procedure for extracting the files from the MIME
archive in MS-DOS.
If ktfc0d5.64 is on a diskette in the a: drive and the Kermit
directory is c:\util\kermit type this.
copy a:\ktfc0d5.64 c:\util\kermit<enter>
Move to the Kermit directory. In our example type this.
cd c:\util\kermit<enter>
Expand the archive using a MIME base64 decoder. MIME
en/decoding programs are available for all operating systems in
current use. In MS-DOS I use MIME64 written by Karl Hahn.
Search for mime64b.zip on the Web. If mime64.exe is in the
\mime directory type this to expand the KTFC archive.
\mime\mime64 ktfc0d5.64<enter>
The 6 files plus this readme.kfc will be produced. After
extracting the files, mime64 will report "No MIME base64 lines
found in ktfc0d5.64". Don't worry about this message.
If using ktfc0d5.zip follow the analogous procedure. Unpack the
archive with pkunzip.exe which is readily available from BBS and
Internet servers.
*** Macintosh
As of early 1999, development of Mac Kermit was not keeping pace
with MS-DOS Kermit or with C-Kermit. KTFC has not been tested
with Mac Kermit. Mac users should consider one of the off-line
FirstClass clients---BulkRate by Greg Neagle for example.
*** Microsoft Windows
MS Windows users should also consider the OffRoad client written
by Hans Haider.
I have not tested KTFC with Kermit-95 but, of course, anyone is
welcome to try that configuration. Until successful use of KTFC
with Kermit-95 is established I can not offer the same level of
support for that configuration as is provided for KTFC in the
MS-DOS system.
*** Unixes
Testing in a unix system is on my "to do" list. Until testing
is completed I can not offer the same level of support for KTFC
in a unix system as is provided for KTFC in the MS-DOS system.
If you wish to try KTFC, get the individual files in text mode.
Alternatively, get ktfc0d5.64 or ktfc0d5.zip, unpack the archive
and translate the end-of-lines using dos2unix or the like.
*** Other Systems
Files in the .64 and .zip archives have lines ending in
<cr><lf>. The end-of-line notation may have to be translated
for your system. Reports of problems and successes are welcome.
** User Configuration
Approximately the first 70 lines of the prolog script is the
User Configuration. This is where you set parameters and
switches according to equipment and preferences.
Open an editor on prolog and change the line "set modem HAYES"
according to your modem. In MS-DOS, modem files are in the
modems directory in your Kermit directory. You should already
have a modem file specified in the MSCUSTOM.INI file.
If your modem does not use COM2 change the line "set port com2"
accordingly. If you do not know which com port is used try
com2. If this fails check your MSCUSTOM.INI file.
In the line "def _dialnum {}" insert the number of your FC
server inside the {} brackets. Prefix the number with T for
tone dialing. For pulse dialing give the number alone.
To avoid being asked for your UserID every time you log in,
change the line "def AU 1" to "def AU 0".
To avoid being asked for your Password every time you log in,
change the line "def AP 1" to "def AP 0".
If AU is defined to 0 replace "guest" with your UserID.
If AP is defined to 0 replace "please" with your Password.
Additional configuration features are discussed as FAQs below.
Save prolog. Quit the editor. KTFC is ready to use.
** Sending a message
These instructions assume that you are in the Kermit directory
and that Kermit works. To verify that Kermit is working, log in
to your FirstClass server and send or read a message
interactively. Solve any problem before attempting to use KTFC.
Using an editor, compose outgoing messages in the file mailout
(yyyymmdd.out if the dated OutFile is configured. For more
information see "FAQs > ... How is the name of the outgoing
file changed?"). Syntax is explained below. Close the editor.
Type the command to invoke Kermit to process sr and strike the
<enter> or <return> key. With MS-DOS Kermit version 3.1.6 and
KTFC version 0.5, type this.
msk316 -f sr0.5<enter>
The KTFC version and the login process should be reported on the
screen. If the login fails, try to identify the problem
precisely. Once a problem is identified the solution may be
simple.
A prompt for each message gives the opportunity to avoid
sending. This is useful if an old message has been left in the
OutFile. Once you have sent a few messages and become familiar
with KTFC you will probably want to shut off this prompt; see
"FAQs > What is the purpose of the CS flag ... ?"
After sr sends and reads all pending messages Kermit will quit
and the prompt from your operating system will appear. Using
the editor again, delete from the OutFile any message you do not
want to send the next time sr is processed. Alternatively, old
messages can be left in the OutFile and two message separator
lines can be placed where sending is to stop. sr will not send
messages in the OutFile which follow a pair of separator lines.
The paired separators can be the first two lines of the OutFile.
This is the syntax of the OutFile. The stock OutFile, mailout,
contains example messages which you can use as a template. The
example is addressed to the author; there is no harm in sending
it.
========== syntax of text in OutFile =====================
<message>
{<messageseparator>[n]<text>
[<messageseparator><text>]
<message>}
==========================================================
=============== syntax of <message> ======================
[To:]<recipient>
{[To:]<recipient>}
[Copies:<copy recipient>
{[Copies:]<copy recipient>}]
Subject:<text>
<messagetext>
==========================================================
Notes.
1. Line breaks must be as shown. For example, a message ends
at the end of a line and a recipient address ends at the end of
a line. In DOS the end-of-line notation is <cr><lf>, in Mac it
is <cr> and in unix it is <lf>. In most text editors the
end-of-line character(s) is (are) inserted by pressing <enter>
or <return>. This produces a line break in a text file.
Otherwise the end-of-line characters are invisible.
Square brackets, [], enclose a construct which can occur 0 or 1
times. Curly brackets, {}, enclose a construct which can occur
0 or more times. A term in pointed brackets and the brackets,
<recipient> for example, must be replaced by appropriate text.
Other text, Subject: for example, must appear just as shown.
<text> may contain any ordinary text typed with an editor,
excluding end-of-line characters of course. <messagetext> is
any ordinary text including end-of-lines and excluding the
message separator at the beginning of a line.
2. Every message must have the first line.
[To:]<recipient>
<recipient> must be a name in the directory of your FirstClass
server or a valid Internet address. A valid Internet address
has the form "[<realname>,] <userid>@<node>", not including the
quote characters of course. The "<realname>," portion is
optional. The remaining portions are required.
These are two valid Internet addresses for me.
peter_easthope@gulfnet.pinc.com
Peter Easthope, peter_easthope@gulfnet.pinc.com
sr checks for an @ character in the address. If one is found
the address is assumed to be an Internet address and the
characters ",i" are sent after it. Do not put ",i", ",I" or
",Internet" after an Internet address in the KTFC OutFile. If
you do, this gateway identifier will be duplicated and the
address will fail.
3. The "Copies:" section of the message header is optional.
4. The "Subject:" line is necessary and may not occupy more
than one line. The <text> of the subject line may be empty.
5. Limitations on <message text> with MS-DOS Kermit are
described under System Specific Notes.
6. The OutFile can contain more than one message. A message
separator line, a line beginning with the message separator
defined in the User Configuration section of prolog, separates
messages. KTFC is distributed with the separator being
"**EndOfMsg**", not including the " characters.
7. No messages after two consecutive separator lines are sent.
8. All lines between the "Subject:" line and the next message
separator line, or the end of the file, are included in the
message body. If one of your messages must contain a line
beginning **EndOfMsg** change the message separator. Refer to
"FAQs > I want to send a message which contains ...".
9. If the message separator is immediately followed by the
character n, sr will not send the signature lines after the
message text.
10. The message separator is not required after the last
message. The end of the file is the end of the message.
** Receiving a message
Type the command to invoke Kermit to process sr and strike the
<enter> or <return> key. With MS-DOS Kermit version 3.1.6 and
KTFC version 0.5, type this.
msk316 -f sr0.5<enter>
Messages in mailout will be sent and incoming messages which
have not previously been read will be appended to the file
mailin (yyyymmdd.in if the dated InFile is configured).
** Signature Lines
"Signature" lines are applied to the end of each outgoing
message by the procedure Sig invoked in ProceedMsg.
The signature lines are defined at the end of the user
configuration section of prolog. The number and contents of the
signature lines can be changed by the user. The value assigned
to SigLen must be the number of signature lines. If, for
example, 4 signature lines are intended, the line "def SigLen 2"
must be changed to "def SigLen 4". The 3rd and 4th lines must
be defined; ie. lines "def \&s[3] {...}" and "def \&s[4] {...}"
must be added immediately following "def \&s[2] {...}".
The signature on an individual message can be suppressed by
appending the character "n" to the separator. This is shown in
the formal syntax above. "n" is meant to suggest "no
signature".
The signature can be eliminated permanently from all messages by
commenting the line "xif not equal ... {Sig}" near the end of
ProceedMsg in the sr file (ie. by inserting a ";" at the
beginning of the line).
** Serial Port Problems
This topic really belongs to Kermit rather than to KTFC but some
details are just too significant to ignore.
Kermit documentation recommends RTS/CTS flow control, sometimes
called hardware flow control, in preference to XON/XOFF flow
control. The serial link between a computer and an external
modem can be deadlocked by changing the flow control in Kermit
to RTS/CTS before changing the flow control in the modem. When
this is done Kermit waits indefinitely for CTS assertion from
the modem but the modem never asserts CTS because it continues
to use XON/XOFF flow control. If you have an external modem,
view the modems\*.scr file with the editor. The command to turn
on RTS/CTS flow control in the modem, "output AT &H1&R2\13" for
example, should preceed the command "set flow rts/cts" which
sets flow control in Kermit.
Every serial port and internal modem in a PC with the old ISA
bus had a Universal Asynchronous Receiver Transmitter or UART.
(A machine with the newer PCI bus may be delivered with Windows
specific hardware such as a Winmodem. These notes on serial
ports and UARTs may not apply to such a machine.)
Communications through such a serial port or modem pass through
a register or buffer in the UART. If the register or buffer is
overrun, MS-DOS inserts a BEL character in the data stream. You
will notice the BEL character because a tone will be emitted
from the system speaker. If this error occurs in characters
which KTFC depends upon to make a decision, it will fail. When
KTFC fails you might find a BEL character among those it was
processing. Kermit documentation, KERMIT.BWR for example,
recommends a UART referred to as a 16550A to avoid errors.
Additional information about UARTs can be found in reference 4.
The 16550A is found infrequently on serial port cards for the
ISA bus. If you have an external modem on an ISA system, the
UART of the serial port is likely to be poorer than the 16550A.
If this is the case the external modem is unlikely to work
reliably at speeds above 9600 b/s.
If your modem is faster and you observe errors, set the speed
down to 9600 b/s. Make a backup copy of the modems\*.scr file
and then open your editor on it. Look for a line such as "set
speed 57600". If the speed setting is that simple, change it to
"set speed 9600" and save the file. In some *.scr files the
speed is set by a more complex process. In such a case study
the code carefully before changing it.
This is how I modified ppi.scr for a Practical Peripherals
MC144MTII. Originally the speed was set by "atok 38400". That
line was commented and a line "atok 9600" was inserted. That
set the intended speed. Following the line "chkok {Can't
initialize modem}" the line "goto config" was inserted. That
skipped the model specific speed setting process. Following the
label :CONFIG are these lines.
echo Enabling modulation negotiation...
output AT \m(_modcmd)\13
chkok {Can't enable modulation speed negotiation}
define _modcmd
These four lines are commented so that negotiation does not push
the speed up again. With these changes saved, ppi.scr reports a
connection at 9600 b/s.
** Tidying the Mailbox
Old messages accumulate in the mailbox on the FirstClass server.
The user can log in interactively and delete unwanted messages.
This process is automated by scan. This script examines each
message in the Mailbox. If a message is unread scan reads it
into the InFile just as sr does. If a message has already been
read, scan calculates the age---the difference in days between
the creation date and the current date. Each message older than
the value in the variable MsgLife is a candidate for deletion.
If the variable CDM has the value 1 the user is prompted to
confirm deletion. If CDM is 0 the message is deleted without
user confirmation. According to previous examples, the script
is invoked with the command "msk316 -f scan0.5".
** Scanning Other Conferences
Many users routinely read messages in conferences other than the
Mailbox. This includes conferences in OneNet. The scan script
automates retrieval of such messages.
Before scan can be applied, the path from the home conference to
each conference to be scanned, must be placed in the User
Configuration section at the beginning of the scan script. For
example, on the GulfNet FirstClass server the conference
"Science Talk" is reached by keying <6> <enter> <1> <1> <enter>
<3> <enter>; the path is 6 11 3. Note the path from the Home
conference to each conference you wish to scan.
Open the editor on the scan script and find the definition of
ListLen. ListLen must be given the number of conferences to be
scanned. Change the 0 in the line "def ListLen 0" to the number
of conferences you want to scan. Next, the values for the
\%d[ ] array must be inserted. Each line beginning with "def
\%d[1] {3 3}" specifies a path inside the {} brackets.
Decomment ";def \%d[1] {..}" and ";def \%d[2] {..}"; ie. remove
the ";" character at the beginning of each line. Add additional
definitions as required. The index of the last component of d
must be the value of ListLen. Inside each pair of {} brackets
put a path as described in the preceeding paragraph. Save the
scan file and close the editor. With MS-DOS Kermit version
3.1.6 and KTFC version 0.5, type this.
msk316 -f scan0.5<enter>
The messages retrieved will be found in the file which is also
used for incoming mail. Normally I run scan once per day. On
average a scan of 18 directories at 9600 b/s takes about 10
minutes.
** Automated Startup
MS-DOS can be configured to automate the use of KTFC at startup.
Adding these two lines to the end of the autoexec.bat file
allows sr to be processed automatically when MS-DOS is started.
cd \kermit
msk316 -f sr0.5
Modify the cd command if your Kermit directory is not \kermit.
Modify the Kermit invocation if you are using a MS-DOS Kermit
later than version 3.1.6.
A second arrangement automatically opens EDIT on an OutFile when
MS-DOS is started. Configure the dated OutFile as described in
"FAQ > ... How is the name of the outgoing file changed?"
At the end of the autoexec.bat file insert these three lines.
cd \kermit
msk316 -f datefil0.5
editdate.bat
The command "cd \kermit" tells MS-DOS to switch to the Kermit
directory.
"msk316 -f datefil0.5" invokes Kermit to process datefil.
datefil checks whether a dated OutFile exists for the current
date. If not, the dated file is created and a template of
address, subject and message separator lines are written to it.
Finally, a MS-DOS batch file containing the command to invoke
EDIT on the dated OutFile is created in the Kermit directory.
Processing of datefil is then complete and Kermit exits.
"editdate.bat" invokes EDIT on the dated OutFile. The user can
then compose one or more outgoing messages. When that is
complete the user should exit from EDIT. Message transfer is
initiated with the command "msk316 -f <date>.out" where <date>
is typed in the format yyyymmdd.
Variations of these automation arrangements can be adapted to
other systems.
** FAQs
*** Q. Why are sr and scan not integrated into a single script?
sr pushes the limits of MS-DOS Kermit. All the macros required
to implement the capabilities of sr and scan in one script can
not be defined.
If scan is configured to read several conferences, it requires
much more time to process than does sr. I run sr several times
each day to update the mailbox; usually scan runs only once per
day.
*** Q. scan connects to the server and reads a few conferences.
Then the screen goes blank. What is wrong?
Nothing. The screen fills and then clears. There is a delay
before writing to the fresh screen as scan processes a big
directory.
*** Q. How can interpretation of a Kermit script be interrupted
other than by switching off the power?
A. <ctrl>+<c>; hold down the <ctrl> key and strike <c>.
*** Q. With MS-DOS Kermit, why is there a period at the
beginning of each blank line in an incoming message?
A. This is a side effect associated with a "work around" for an
idiosyncrasy of MS-DOS Kermit. See System Specific Notes >
MS-DOS Kermit > The Side Effect Problem.
*** Q. My InFile is getting too big. What can be done?
A. The simplest solution is to delete the file. In MS-DOS type
"del mailin<enter>". If you want to save the messages, the file
can be renamed; for example, type "rename mailin
mailin1<enter>".
*** Q. What is the purpose of the line "log session
\v(ndate).log" in the User Configuration section of prolog?
It invokes session logging, which is explained in _Using MS-DOS
Kermit_. To activate session logging decomment these lines.
;if exist \v(ndate).log del \v(ndate).log
;log session \v(ndate).log
KTFC will process faster when it is not logging a session.
*** Q. Incoming messages are placed in mailin but I want them in
files named according to date of receipt. How is the name of
the incoming file changed?
A. The name of the incoming file is the value in the macro
variable InFile defined in the User Configuration section of the
prolog file. Decomment the line ";asg InFile \v(ndate).in". An
example of such a dated file name is 19990627.in.
*** Q. Outgoing messages are placed in mailout but I want them
in files named according to date. How is the name of the
outgoing file changed?
A. The name of the outgoing file is the value in the macro
variable OutFile in the prolog file. Decomment the line ";asg
OutFile \v(ndate).out". If sr is executed on June 27 of 1999,
it will try to send messages in a file named 19990627.out. If
no such file exists, no messages will be sent on that day.
*** Q. Old messages are accumulating in my Mailbox on the FC
server; deleting them interactively is tedious. How can old
messages be deleted from the server automatically?
A. Run the scan script. Messages older than MsgLife will be
deleted. MsgLife is assigned a value near the beginning of the
scan script. Change the value if you wish.
*** Q. What is the purpose of the CS flag in the prolog script?
A. CS is the acronym for Confirm Send. With CS set to 1, sr
will read each outgoing message in the OutFile and then prompt
the user for confirmation before sending. When you tire of
giving this confirmation, use the editor to set the value for CS
to 0.
*** Q. What is the purpose of the DAR flag in the prolog script?
A. DAR is the acronym for Delete After Receipt. With DAR set to
1, sr and scan will attempt to delete each unread message in the
Mailbox after reading it. If INPUT of a message fails while it
is being received and DAR is set to 1, there is a possibility of
the message being deleted before it is retrieved from the server
correctly. Most users will be best served by leaving DAR with
the value 0 and relying on scan to delete outdated messages.
*** Q. I want deletion of messages to occur without the prompt
for confirmation. How do I turn off the prompt?
A. The prompt to confirm deletion occurs or not accordingly as
the switch CDM is set to 1 or 0. When you tire of giving this
confirmation, open the editor on prolog and set the value for
CDM to 0.
*** Q. Processing of sr (or scan) failed while a message was
being received. What should be done?
Check that your modem has "hung up" and then restart the script
to finish processing.
The failure probably resulted from a serial port error,
discussed in Serial Port Problems above, or from one of the
limitations of MS-DOS Kermit, described in System Specific
Notes. In any case the faulted message is no longer unread and
will not cause the script to fail again. A message can be read
using Kermit interactively and can be recorded in the session
log. Session logging is explained in _Using MS-DOS Kermit_.
*** Q. I want to send a message which contains a line beginning
with **EndOfMsg** but this is the message separator. How can
the message be sent intact?
A. Change the message separator. Open the editor on prolog and
find the variable MSep in the User Configuration. Change the
assigned value to any string you wish. The length need not be
12 characters. Choose a string which is not likely to appear in
future messages.
** System Specific Notes
*** Microsoft Windows
Microsoft Windows is not available here. Reports from users are
welcome. Appropriate information will be incorporated into
documentation of subsequent releases for benefit of MS Windows
users.
*** MS-DOS
The Side-Effect Problem
KTFC was developed on MS-DOS Kermit. Originally an incoming
message was handled using \v(input) directly. Problems became
evident. For example, if an incoming message contained Kermit
code, the interpretation of KTFC was "sidetracked". Kermit
Support recommended that \v(input) be copied to a macro variable
and that subsequently the macro variable be used rather than
\v(input). This was implemented in the procedure SaveLine
in the sr script.
SaveLine prevented Kermit code received by INPUT from
sidetracking the interpreter but then a new problem appeared.
Lines containing visible characters had a comma appended. This
was solved by deleting the last two characters from the line and
then writing the line to the file with writeln. Perversely,
another problem appeared. A line which was empty was deleted.
This was solved by replacing an empty line with a line
containing a period. All these features are implemented in the
SaveLine defined when KTFC is used with MS-DOS Kermit. With
other systems SaveLine is defined to simply record \v(input) in
a macro variable.
These complications would be eliminated if INPUT simply recorded
incoming characters in a buffer where they would remain
unchanged and available until explicitly cleared.
Other Problems
A minus sign "-" at the end of a line in an outgoing message
causes that line and the following line to be joined when sent
to the server. Avoid ending a line in an outgoing message with
a "-" character.
Transmission failures for messages containing the characters "\"
and "{" have been observed.
Leading blanks are stripped from a line when a message is sent.
Leading and trailing blanks are stripped from an argument passed
to a macro.
A problem specific to MS-DOS Kermit can cause script processing
to fail. Refer to "FAQs > Processing of sr (or scan) failed
...".
*** Oberon
I use the PC Native Oberon operating system; see
http://www.oberon.ethz.ch/. Kermit is not yet implemented in
Oberon so I use MS-DOS Kermit to transfer mail. I reboot the
machine with Oberon to read incoming messages and to compose
outgoing messages. Edit and ET in Oberon are very well suited
to editing message files.
The Oberon.Text file contains these groups in the
InitCommands section.
{ DOS.CopyFrom "c:/kermit" mailin ~ }
{ ET.OpenAscii mailin }
These commands are in System.Tool.
ET.OpenAscii mailin
DOS.CopyTo "c:/kermit" mailin ~
ET.OpenAscii mailout
DOS.CopyTo "c:/kermit" mailout ~
*** Unixes and other systems running C-Kermit
Testing with C-Kermit on a unix system is on my "to do" list.
Reports from users are welcome and appropriate information will
be incorporated in future releases.
** Bugs
Bug reports and suggestions are welcome. Analysis of a bug
resulting from a specific message requires a copy of the message
which caused the problem. The user may need Software
independent of KTFC to send a message for diagnosis.
** Limitations
The limitations of MS-DOS Kermit described in System Specific
Notes can not be completely overcome by KTFC.
The ability to send and receive attachments using the X-modem
protocol imposed by the FC server would be nice. If this can be
implemented for C-Kermit it is unlikely to work with MS-DOS
Kermit because of limitations described above. Nevertheless, a
binary file can be transmitted by ASCII encoding it, with a MIME
algorithm for example, and including the encoded file in the
body of a message. I have no plans to implement attachment
handling.
Rather that descend to each target directory from Home, scan
might perform a tree traversal. The "*" which marks a
FirstClass directory containing unread items might be used to
improve efficiency. The sr script pushes the limits of MS-DOS
Kermit and the programming requirements for tree traversal are
likely to exceed the capability of MS-DOS Kermit. I have no
plans for work on this implementation.
The calculation of the age of a message does not take account of
February 29 in a leap year; the age of a message which is on the
server on February 29 will be one day longer than calculated.
scan will allow this message to remain on the server one day
more than specified by MsgLife. This is unlikely to be
seriously harmful.
** Support
Are you having difficulty installing Kermit? Are you modifying
a KTFC script and in need of help with Kermit programming?
Questions about Kermit and Kermit programming should be sent to
the Usenet forum comp.protocols.kermit.misc. Not all FirstClass
servers subscribe to this forum and you might not have access to
it from home. Most public libraries now have Web terminals.
Anyone can go to http://www.deja.com/, open an account and have
access to comp.protocols.kermit.misc. The Deja account allows
subscription to e-mail delivery of the forum.
KTFC users can subscribe to the ktfcinfo mailing list. Send a
message with empty subject field and empty message body to
ktfcinfo-subscribe@egroups.com. You will be asked for a
confirmation. Once your subscription has been accepted, you can
send support questions to ktfcinfo@egroups.com. To learn more
about eGroups read http://www.egroups.com/. To leave the
mailing list, send an empty message to
ktfcinfo-unsubscribe@egroups.com.
Messages sent to ktfcinfo should be plain ASCII text. html code
wastes communications and human time; please refrain from
sending it.
A query posted to ktfcinfo may benefit other Kermit users. I
will tend to give more attention to a query in ktfcinfo than to
the same query sent in a personal message.
Mention your operating system (Linux, MS-DOS or something else),
Kermit version number and KTFC version number. Be as specific
as possible in describing the problem. If there is an error
message, record and report it. Your InFile or OutFile or the
session log may be required.
If you can not send e-mail, post is acceptable. My address is
given below under Registration. Please do not ask for support
by telephone.
** References
1. Kermit in many forms is available from
http://www.cc.columbia.edu/kermit/ and from
ftp://kermit.columbia.edu/kermit/. Kermit softwares are
products of Kermit Distribution, Columbia University Center for
Computing Activities, 612 West 115th Street, New York, NY 10025,
USA.
2. FirstClass is produced by SoftArc Inc. See
http://www.softarc.com/.
3. MS-DOS Kermit is documented in _Using MS-DOS Kermit_, Second
Edition by Christine M. Gianone, (C) 1992, Butterworth-Heinemann
/ Digital Press. C-Kermit is documented in _Using C-Kermit_,
Second Edition by Frank da Cruz and Christine M. Gianone, (C)
1997, Butterworth-Heinemann / Digital Press. Additional
information is available from the Web site in reference 1.
Features of the Kermit language additional to those described in
the manuals are described in files available from the Columbia
server, reference 1.
4. Information about UARTs is available at these locations.
http://www.linuxdoc.org/HOWTO/Hardware-HOWTO-10.html
http://www.redhat.com/support/docs/howto//PPP-HOWTO/PPP-HOWTO-8.html
Submit "UART 16550A" to a Web searcher to find additional
information.
** Conditions of Use
The copyright to each file in the KTFC package belongs to the
author. The files are not in the public domain. Please
attribute KTFC to the author when mentioning it in a
publication.
If registered, you may
... modify the files for your individual use.
... use the original or modified files for personal, academic
or commercial communications.
... distribute the archive ktfc0d5.64, the archive ktfc0d5.zip
or the complete set of 7 files. The package may be
distributed via a network from a server freely accessible to
the public or by storage media.
Regardless of registration you may not
... violate my copyright by plagiarism. This includes
appropriation and publication of the name KTFC and of any
significant portion of a KTFC file.
... distribute individual files isolated from the KTFC package.
... distribute KTFC under a different name.
... publish similar data under a name resembling KTFC. KtFC,
ktfc, KTFC3 and XKFTC, for example, are too similar.
... suggest, imply or state an affiliation between KTFC and an
entity other than the author.
... charge a fee for distribution of KTFC.
... distribute KTFC to customers of a business, exclusive of the
public at large. This includes distribution on a storage
medium and distribution via a network.
... use KTFC within a hardware or software product which is
given away or sold.
For any use or distribution outside of these conditions please
contact the author.
** Fee
For an individual, the registration fee is 25 US dollars or 35
Canadian dollars. This covers use of version 0.5 of KTFC and
future revisions until further notice. The fee also covers
consultation to assist in installing, configuring and
troubleshooting up to about 30 minutes of my time. The
magnitude of the fee is valid until 2000 August 31 and may
change after that date.
Everyone mentioned under Thanks is exempt from payment.
Extensive time may be required to adapt a script to a specific
purpose. Assistance with modification of scripts may be subject
to charge in addition to the KTFC registration fee.
The fee does not include support for Kermit.
** Registration
Registration is by sending me a name, contact address and the
fee specified under Fees. The post is not perfectly reliable; I
can not take responsibility for a loss of cash or other
instrument of payment in the mail.
Registration fees are my principal source of income; I really
appreciate receiving them. Support can not be provided to users
who are not registered. If the fee is beyond your means, let me
know.
Peter Easthope, peter_easthope@gulfnet.pinc.com
2701 Privateers Road
RR2, Pender Island, BC
V0N 2M2 Canada
** Thanks to
... Maria Watson for extensive testing.
... the staff of the Kermit Project at Columbia University for
assistance with Kermit; in particular to Jeffrey Altman,
Frank da Cruz and Christine Gianone.
... Professor Joseph Doupnik for assistance with MS-DOS Kermit.
** History
1999 January Prototype of KTFC developed with Kermit 3.14.
1999 02 16 KTFC0.0 testing.
1999 02 20 Kermit 3.15 installed.
1999 02 20 Attempt to use \fsubstring(\%a,1,1) to identify
unread messages.
1999 05 11 \fsubstr(\%m,1,1) successfully identified unread
messages.
1999 05 16 Improved extraction of message number.
1999 05 17-18 Incorporated \fsubstr(\%m,1,1) to simplify
processing of header of outgoing message.
1999 05 22 KTFC0.1 released for testing.
1999 05 26 Reported bug in handling of a blank character
(20_F) in an argument to a macro, to Kermit
Support.
1999 05 28 Incorporated minput to simplify handling of
special cases of input, including [More] prompt.
1999 05 29-06 03 Corrected syntax of string comparisons; eg.
if equal \fsubstr(...) \%m changed to if equal
{\fsubstr(...)} {\%m}.
1999 06 05-06 07 Added handling of defective and ambiguous
addresses. Various improvements using SWITCH
statements.
1999 06 12 Fixed end-of-file handling. Double message
separator no longer needed after last message.
1999 06 28 Moved deletion of message into macros.
1999 07 04 Improved the recognition of the end of an incoming
message.
1999 07 05-14 Moved all code for receiving messages into macros.
1999 07 15 Added user configuration section at beginning of
KTFC.
1999 07 16 Reorganized code preceding macro definitions.
1999 07 17 Released KTFC0.2 for testing.
1999 07 17-18 Improvements to SkipDeja. Kermit 3.16 bug found:
leading blanks deleted by INPUT, leading and
trailing blanks deleted when argument is passed to
macro.
1999 07 22 Improvements in handling of login.
1999 08 23
-1999 09 15 Sending of message header rewritten in macros.
1999 09 22 KTFC0.3 script frozen.
1999 09 22-23 Simple mailbox tidying code added.
1999 11 07 Code to avoid a message number beginning with 0 ---
eg. "05".
1999 11 14 KTFC0.4 script frozen.
KTFC split into script for sending and receiving
messages SR and script for tidying the mailbox
TIDY.
1999 12 03-04 Code for applying "signature" lines at the end of
a message added to SR.
2000 01 04-20 Added code for reading messages from directories
other than the mailbox.
2000 02 01-03 Code common to SCAN, SR and TIDY moved to PROLOG.
2000 02 19-21 Mailbox tidying incorporated into SCAN thereby
obsoleting TIDY.
2000 03 01-08 Miscellaneous revisions to README.KFC.
2000 03 09-10 Internet address recognition added; ",Internet" no
longer required in address.
2000 03 10 Name README.KFC changed to KTFC0P4.TXT.
2000 03 11-19 Miscellaneous revisions to KTFC0P4.TXT.
2000 03 20 Revisions to KTFC0P4.TXT and preparations of MIME
-2000 04 06 archive.
2000 04 06 Error in calculation of age of message with
attachment corrected.
2000 04 24-28 Definition of dial and chkmdm macros placed in
PROLOG; MSKERMIT.INI and MSCUSTOM.INI are no
longer required.
2000 04 28 In SR a bug in inputing control sequences when
sending a message was corrected.
2000 05 01-04 Miscellaneous revisions to KTFC0P4.TXT and
README.KFC.
2000 05 08 Names of script files changed to lower case.
2000 05 09 Documentation revised accordingly.
2000 05 10 KFTC0.4 Released to the Kermit Project, Columbia
University.
2000 05 19 \&o[1] tested in place of OutLine.
2000 05 20 Definition of SaveLine made system dependent.
Procedure SLEC removed.
2000 05 19-21 Miscellaneous revisions to ktfc0d5.txt.
2000 05 24 KTFC0.5 Released to the Kermit Project, Columbia
University.
** Trademarks
"Macintosh", Apple Computer, Cupertino, CA.
"FirstClass", SoftArc Inc., Markham, ON.
"Kermit", Henson Associates, Inc., New York, NY. Name used with
permission by Kermit Distribution, Columbia University
Center for Computing Activities, New York, NY.
"IBM PC", International Business Machines Corp., Armonk, NY.
"Linux", registrant: Croce, William R. Della, Jr., Boston, MA.
last listed owner: Torvalds, Linus, Santa Clara, CA.
"MS-DOS", "Microsoft Windows", Microsoft Corporation, Redmond,
WA.
"Red Hat", registrant: Red Hat Software, Inc. Durham, North
Carolina.
"UNIX" exclusive licensee: X/Open Company Ltd.
registrant: American Telephone and Telegraph Company
Corporation, New York, NY.
last listed owner: UNIX System Laboratories, Inc.
Delaware, NJ.