info-kermit@ucbvax.ARPA (03/23/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Fri, 22 Mar 1985 Volume 2 : Number 15
Departments:
ANNOUNCEMENTS -
Corrections, Reminders, Notes
New MVS/TSO Kermit Recalled
New Kermit for Honeywell DPS-8 with GCOS
New Kermit for TRS-80 Model 4
New Kermit for TRS-80 Color Computer with Radio Shack DOS
UNIX KERMIT -
C-Kermit Suggestions, Comments
Installing Kermit on CADMUS (system V)
C-Kermit Comments Revisited
More C-Kermit Line Locking Problems
----------------------------------------------------------------------
Date: Fri 22 Mar 85 13:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Corrections, Reminders, Notes
To: Info-Kermit
The previous issue of the digest was V2 #14; it was correctly labeled in
the message "Subject:" field, but internally it said V2 #13. Sorry.
I fell behind a little bit in mailing list additions, deletions, changes.
They should be up to date now. There are currently 315 addresses in the
Info-Kermit list, and many of them are themselves distribution lists. If
you get this message and didn't want it, or didn't get it but did want it,
then let me know. Some of the people who asked to be removed were not on
in the first place, which means they must be getting Info-Kermit through a
local redistribution list.
In the previous issue I forgot to say that the new release of Brian
Nelson's PDP-11 Kermit is available, as usual, via anonymous FTP from host
CU20B. The files are KER:K11*.* (there are about 88 of them!); the file
KER:K11FIL.DOC explains what they are.
For those who haven't seen the following information before, or for a long
time, here it is again, briefly:
A complete collection of Kermit programs, documentation, and other files
is available on CU20B, a DECSYSTEM-20, Internet host number 192.5.43.128,
using the Internet FTP (File Transfer Protocol) facility: login via FTP
(not TELNET) as user anonymous, any password will do, and GET or MULTIPLE
GET the file or files you want. Several files are of special interest:
KER:00README.TXT tells what files are available and how they are named.
KER:VERSIONS.DOC lists existing versions and those in preparation.
KER:CURRENT.DOC lists current versions chronologically.
KER:FLYER.DOC gives ordering information for Kermit on magnetic tape.
Kermit files are also available via BITnet ("SMSG RSCS MSG CUVMA KERMSRV HELP")
and UUCP (from host okstate; see recent Info-Kermit messages). New files
usually take a few days to find their way to these alternate sources.
------------------------------
Date: Fri 22 Mar 85 11:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New MVS/TSO Kermit Recalled
To: Info-Kermit
The TSO Kermit modified at the University of Toronto for Series/1 front
end support announced in the previous issue of the Info-Kermit digest has
been recalled. It turns out that the modification allows it to work ONLY
with the Series/1, and does not allow it to work over ordinary asynchronous
connections. So now, we have three MVS/TSO Kermits:
1. The original, from U of Chicago: KER:TSOKERM.*, KER:TSODYNAL.*
2. (1), modified for Series/1: KER:TSOS1.ASM
3. The Rice University PL/I version: KER:TSORICE.HLP tells how to get it.
Sorry for the confusion.
------------------------------
Date: Thu 21 Mar 85 18:56:20-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: New Kermit for Honeywell DPS-8 with GCOS
To: Info-Kermit@CU20B.ARPA
Contributed by John Huxtable of the University of Kansas in Lawrence, this
new Kermit (unrelated to the other Honeywell GCOS Kermit donated by Terry
Carlin of Honeywell) operates in remote mode only, is capable of acting as
a Kermit server, and provides options supporting the different communications
modes used on Honeywell mainframes, and all GCOS file formats. The files,
including B language source, the executable program in packed-text form
along with a Fortran unpacker, documentation, and ROFF documentation source,
are available via anonymous FTP from CU20B as KER:HDPS8.*.
------------------------------
Date: 20 Mar 85 13:43:35-CST (Wed)
From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa>
To: sy.fdc@cu20b.ARPA
Subject: New Kermit for TRS-80 Model 4
Here, finally, is the Model 4(p) Kermit for TRSDOS 6.1. I decided to go
ahead and let you have it before I got all of the stuff that I really want
to add, added. I named all of the files M4* noting that this did not
confilict with any of the files we have in the distribution.
[Ed. - Thanks, Greg! It looks like a very complete implementation,
including VT52 emulation with key mapping and session logging, a full
complement of SET commands, command and initialization files, and a script
facility based on the INPUT/OUTPUT/PAUSE/CLEAR model with some
extensions. The files are in KER:M4*.*, available via anonymous FTP.]
------------------------------
Date: Thu 21 Mar 85 19:01:49-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: New Kermit for TRS-80 Color Computer with Radio Shack DOS
To: Info-Kermit@CU20B.ARPA
Contributed by Wes Hubert of the University of Kansas, this new Kermit
implementation runs on the TRS-80 CoCo with the Radio Shack disk operating
system. It requires a machine with at least 16K memory and one disk drive,
and the Radio Shack disk ROM 1.0 or 1.1. The program is available via
anonymous FTP from CU20B as KER:CC*.*.
------------------------------
Date: 20 Mar 85 21:15:59-CST (Wed)
From: Gregg Wonderly <gregg%okstate.csnet@csnet-relay.arpa>
To: sy.fdc@cu20b
Subject: C-Kermit Suggestions, Comments
Just got a few more ideas of improvements to C-Kermit, and would also like
to hear of anything that others have sent your way since you last posted the
Bugs report.
1) How about making SET LINE look in a file for valid devices. We would like
to let certain students go out through the network, and get onto other
machines to use KERMIT. Since you can really create a LCK.. file for
more devices than we would like, it would seem natural to limit the valid
outbound lines, based on a file similar to /etc/passwd, where you have
login names, passwords, and other info. This way, someone can not lock
up the UUCPKER, UUCP, or CSNET lines.
[Ed. - Several objections: (1) Adds yet more hair, and associated startup
time to the program; (2) Doesn't really accomplish anything, since none of the
other programs that use tty devices would honor this convention; (3) Starts
moving Kermit into the category of software that can only be installed and
maintained by the system manager -- something I want to avoid.]
2) After much frustration, I have decided that there probably really should
be complete trapping of all interupts. It seems that Mark Vasoll, and my-
self have this habit of hitting delete (Our ^C) in the middle of a command
line when we mistype. If SIGINT is traped in the parser, and results in
a parse error, than operation would be smoother. I have said something
to you before about this, but now I think it is manditory that it be done.
[Ed. - Yet more hair to be added to the program, but in this case, I'm
afraid I have to concur; it's really bad to leave the user with an
unusable terminal. I hope that we can let this question ride for a while,
until after the next release. I have to do a huge amount of work to get
the next release out -- merging in the VMS support, your own forthcoming
V7 support, and much else -- and would prefer to have the interrupt stuff
added on top of that by people who know more about these things than I do.]
3) I have already changed all printf's, that did not require any format
translations, i.e. no "%s", "%d", etc... to calls to a function that I
added in the chusr3.c module. This function is quite simply:
outstr(s)
char *s;
{
while (*s)
putc(stdout, *s++);
}
This completely eliminates the problems associated with various systems
different size buffers used in the printf() function.
BUGS:
There seems to be some problems with recognition of error packets when get
is used to retrieve a file from another server. I found that when I asked
for a file that did not exist, C-KERMIT kept retrying, while clearly there
was a sequence of E%E%E%E%E% characters appearing on my screen. Haven't
looked at this one yet, but hope to by this weekend.
[Ed. - Strange. I can't reproduce this one. Please send more details.]
Get also seems to be retrying an abnormal amount of times on certain files.
This may be related to the double packet exchange that was recently
discussed in the INFO-KERMIT digest.
------------------------------
Date: Thu, 21 Mar 85 14:51:12 est
From: decvax!ittvax!long@Berkeley (H. Morrow Long [Systems Center])
To: fdc@CU20B.ARPA@sy
Subject: Installing Kermit on CADMUS (system V)
We have been using the Unix Kermit Server Program with our
other kermits and have found it to be very useful. I sent you
some implementation notes on the 4.1bsd versus 4.2bsd problem.
Here is a new note on porting to the CADMUS. We using 'make
sys3' on the CADMUS the software will compile with a warning
about truncating a pointer to an integer in the files ckwart.c
and ckzunx.c. When 'wart' (and 'wermit') are run they will die
with 'segmentation violations' and core dump.
The reason for this is the fact that the CADMUS C compiler uses
16 bit integers and 32 bit pointers. The routine malloc() was
not declared as returning a character pointer (char *) and was
therefore taken as returning a 16 bit integer (the default).
The following change clears up the situation:
char *malloc(); /* Needed by CADMUS, and probably many 68000's */
H. Morrow Long
ITT-ATC Systems Center,
1 Research Drive Shelton, CT 06484
------------------------------
Date: Thu, 21 Mar 85 14:55:16 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:poulton@hplabs.CSNET>
To: cc.fdc@columbia-20.ARPA, cc.fdc@cu20b.ARPA
Subject: C-Kermit Comments Revisited
Well, I have a few responses:
> ! cmd
> should use the shell defined by the env var SHELL, if defined
> "!cmd" should work for Unix consistency (not just "! cmd")
>
> [Ed. - The "!" command just does a system() of its argument. Rather than
> write all the code to fork and pipe the desired shell, maybe users can
> just live with typing "! csh xxx" or "! ksh yyy" if they want these
> effects. A space is needed after "!" because "!" is a command keyword,
> and whitespace must separate command fields. Removing this limitation
> would probably make the command package a lot hairier. Maybe to alleviate
> the confusion that this causes, the "!" should be renamed (back) to "shell".
Using the right shell is common courtesy for interactive programs on Unix.
The UW version of old C-Kermit does this, with one routine which works
on all systems, I think.
I understand about the parser, but "!cmd" is completely common on Unix.
This may be worth special-casing if the parser can be short-cicuited on just
this special case. Seems like it might be an easy bypass.
> stat cmd
> can't we get timing info to get effective baud rate?
>
> [Ed. - If you have given a "set speed" command (or -b option), then this
> would be reasonable. Otherwise, the program would not necessarily have a
> reliable way of determining the baud rate. I really tried to avoid all
> this kind of system-dependent hair (system clocks, baud rates, etc)
> because it tends to make the program grow out of proportion to its
> functionality.]
Fine, if it doesn't know, then it can't say, but *effective* transfer
speed (not line baud rate) is the main use of the stat command anyway - I
still have to use a stopwatch to figure out if it's running up to snuff,
so the stat command may as well not exist.
> command interface
> Use the user's line kill char rather than hardwire to ^U.
> Use the user's backspace char rather than hardwire to DEL/BS.
> Respond to the user's interrupt char rather than hardwire to ^C.
> Kermit not observing these is very annoying, since being able to
> choose them is a nice (and often used) feature of Unix. This also
> confuses novices.
>
> [Ed. - But the last guy said you should use something OTHER than the
> user's line and char kill characters; can't please everyone. Also,
> again the point about system independence. C-Kermit 4.0 was a pretty
> clean program. 4.2 already has tons of hair added to the system-dependent
> portions, and every time we add a system-related feature like this, it's
> got to be added for n systems, and soon the program will be an enormous
> pile of verbiage, buried somewhere in the middle of which will be the Kermit
> protocol.]
A question of user-friendly versus "let's all use DEC-20 control chars".
The other guy had the right diagnosis, but the wrong cure: His problem
goes away if you *turn off* the line kill and backspace in the tty driver
(simple enough, while you're setting cbreak mode) and use the user's
control chars *since they are doing the same things*.
Ken Poulton
(I think we're making progress - this is shorter than my last letter.)
[Top-Level Ed. - I tend to agree with all this, but there are tradeoffs.
One is that the program has to be maintainable, and the more system
dependent features creep in, the less maintainable it becomes. Another is
that the bigger it gets, the harder it is to shoehorn it into little systems
(in several senses -- memory segmentation a`la Pro/Venix, memory occupation,
disk space, time to load from disk, time to start up once loaded, etc etc.
Let's see how the next release turns out, if I ever get time to work on it.]
------------------------------
Date: Fri 22 Mar 85 10:34:23-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: More C-Kermit Line Locking Problems
To: Info-Kermit
Two recently reported problems with C-Kermit "line locking" --
Problem 1:
User tries to use a given line; ttopen() opens it, then calls ttlock(), which
finds it locked, gives the appropriate message, and returns failure. User
then exits from program. However, the ckx module still has a valid ttyfd for
the line, so when doexit() is called, the line is closed. This tends to hang
up the line on whoever was really using it.
Problem 2:
User does connect, which calls ttopen(), which reports the line is in use.
However, since a valid ttyfd is left around, the next time the user does
connect, it works even though someone else is using the line.
Easy cure:
If ttopen fails to get exclusive access, put the ttyfd back to -1.
Better cure:
Don't open the tty before calling ttlock. The only reason it's opened
first is for the benefit of flock(). Just get rid of flock(); it doesn't
do anything anyway. After calling ttlock, THEN open the tty, and then do
the ioctl(ttyfd,TIOCEXCL,...) for those systems that support it.
------------------------------
End of Info-Kermit Digest
*************************
-------