SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (10/08/85)
Info-Kermit Digest Mon, 7 Oct 1985 Volume 3 : Number 22
Departments:
MISCELLANY -
Half-Duplex Windowing vs Long Buffers
Use of Kermit by the Blind (Several Messages)
Hint for VMS Binary File Transfer using Kermit
UNIX KERMIT -
Ken Poulton's C-Kermit Changes (Several Messages)
C-Kermit Works on HP Integral Kermit
C-Kermit EOF Bug
C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
Masscomp Kermit
TI NU Machine Kermit
Bug in C-Kermit Remote Commands under VAX/VMS
----------------------------------------------------------------------
Date: Thu, 3 Oct 85 19:35 EDT
From: RAF@UMDC.BITNET
Subject: Half-Duplex Windowing vs Long Buffers
Is everyone agreed that in half-duplex windowing, the EOL character should
not be sent until the end of a group of packets? If an EOL character is
sent after each packet, my 370 TSO and WYLBUR systems will require some
delay before the next packet is sent. Otherwise following packets will be
lost. Also, if a packet received in error results in a parity error (likely,
but not certain), the resulting error message from the system will cause
the following packet to be obliterated also. For my systems, I think it is
best not to send an EOL until the end of a group of packets.
However, if the EOL is not sent until the end of a group, there is another
problem which may be common to systems that check incoming parity. Since
the whole group of packets is considered to be one "line" by the system,
an error in any packet that also results in a parity error (highly likely,
although not guaranteed), will cause the entire line (group of packets)
to be discarded. Thus the half duplex windowing scheme results in extra
overhead for multiple packets per "line" with little corresponding benefit
in reduced retransmission when compared to the big packet proposal.
Therefore I prefer big buffers to half-duplex windowing.
Roger Fajman <RAF@UMDC.BITNET>
Computer Center
National Institutes of Health
[Ed. - Last chance to get your comments in... The tide of opinion seems to
be favoring long packets, distinct from sliding windows.]
------------------------------
Date: Tue 1 Oct 85 14:17:51-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Use of Kermit by the Blind
To: Info-Kermit@CU20B.ARPA
cc: Info-IBMPC@USC-ISIB.ARPA, Info-Micro@BRL-VGR.ARPA
I've had a call from Kenneth Reed at NASA in Greenbelt, MD (phone 301-344-8414)
asking how Kermit can be used effectively by blind people. Back in the days
when computers had terminals, you could put a device like a Votrax or DECtalk
or whatever between the terminal and the computer, and it could try to speak
the letters and numbers, or words, as they went by. But microcomputers don't
generally have a place to attach such a device. Kenneth says his Apple II
has a special card that somehow gets characters just before they're about to
be put on the screen and presumably can transmit them to a speaking device,
but that's just for the Apple.
I'm sure there has been a lot of discussion about this elsewhere, but I must
have missed it. How can blind people use microcomputer applications in
general? Obviously, graphics-oriented stuff is mostly out (and therefore,
presumably, also the Macintosh). In MS-DOS, maybe there are console drivers
that can intercept characters, strip out (or interpret) formatting information,
and send the text out the serial port to, say, a Votrax, or maybe there are IBM
PC boards that "speak the screen" directly. Anyhow, Kenneth's department is
selecting microcomputers and he'd like to see them pick one that text oriented
applications (like Kermit) can be adapted to give comprehensible audible
output. If you have any information, please post it and also give Kenneth a
call at the number listed.
By the way, the way the Kermit file transfer display is done is important here.
On MS-DOS systems, a "form" is put up on the screen at the beginning of the
file transfer, and then numbers and messages are filled in and updated
randomly throughout. If one were to read this stuff in sequence as it appeared
on the screen, it would be a pretty confusing jumble. Also, you'd need a
pretty fast talker at high baud rates... The serial output of local-mode Unix
Kermit or DEC-20 Kermit would be a lot more comprehensible when interpreted
by a voice device.
------------------------------
Date: Wed, 2 Oct 85 06:21:51 MDT
From: halff@utah-cs.arpa (Henry M. Halff)
Subject: Re: Use of Kermit by the Blind
References: <1835@brl-tgr.ARPA>
Let me suggest that your friend contact the following firm.
Talking Computers, Inc.
6931 North 27th Road
Arlington, VA 22213
703-241-8224
The fellow that runs the firm is Doug Wakefield. His business is putting
speech synthesizers on computers for blind people. He pretty much specializes
in IBM PC's, but he might be able to help with Apples. The software that he
uses should have no problem with a screen display like Kermit's since the
user can, at any time, get a readout of the entire screen or any line
on the screen.
Hope this helps.
Henry M. Halff
Halff Resources, Inc.
halff@utah-cs.ARPA
------------------------------
Date: Sat, 5 Oct 85 10:28:24 mst
From: Kelvin Nilsen <kelvin%arizona.csnet@CSNET-RELAY.ARPA>
Subject: Kermit for the Blind
[Ed. - This is from the author & proprietor of VersaCom, a communication
program that includes Kermit.]
versacom does not run windows! all i/o to the terminal is serialized through
the bios, write tty (except of course when it comes to terminal emulation).
this makes it possible to run versacom on a pc from a terminal and connect
to another system to transfer files. for example:
vt100 dumb tty emulation
+-------------+ +---------+ +----------+
|home terminal|- 1200 baud -|office pc|-19200 baud-|office vax|
+-------------+ +---------+ +----------+
xon/xoff handshaking is supported on both ports, in both directions and works
independently. the amount of information reported by file transfers can be
each packet, or each file transfered.
anyway, this capability makes possible two solutions to the problem you
mentioned. first, attach a votrax-type terminal to one of the com ports
of the pc. second, modify versacom to send bios tty output to an internal
voice synthesizer instead of or in addition to the bios tty output.
kelvin nilsen
------------------------------
DATE: October 07, 1985 11:29:44 EDT
FROM: NUNNALLY%VPIVM1.BITNET@WISCVM.ARPA
SUBJECT: TERMINAL FOR THE BLIND
WE ARE TRYING SEVERAL DIFFERENT PRODUCTS FOR THE BLIND HERE AT VA. TECH
ONE IS A PACKAGE ON THE IBM PC CALL ED FREEDOM. VERY NICE PACKAGE.
WORKS OUTSIDE OF ALMOST ANY OTHER PACKAGE ON THE PC. WE USE THE TERM
EMULATOR YTERM WITH IT NO PROBLEMS.
WE ALSO USE THE AUDIOTRONICS TALKING KEYBOARD FOR THE PC. HAVING SOME
SPEED INTERFACE PROBLEMS. QUESTIONS CALL 703-961 5961.
------------------------------
Date: 5 Oct 1985 1454-PDT (Saturday)
From: randy@uw-bluechip.arpa (William Randy Day)
Subject: Re: Use of Kermit by the Blind
I am part of a research project here at the University of Washington aimed
at developing software for deaf-blind (both deaf and blind) users. The
presentation problem is severe. As you say, graphics-oriented software is
out. As you describe in you posting, even ``non-graphics'' programs like
kermit can prove incomprehensible if a straight screen output to speech
translation is made. We have come to the conclusion that a simple
hardware/software translation unit sitting on top of normal software is
inadequate, particularly for our severely handicapped target group. We have
taken the custom software approach.
Randy Day.
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy
ARPA: randy@washington
CSNET: randy%washington@csnet-relay
------------------------------
Date: 3 Oct 85 17:20:20 GMT
From: walton%Deimos@CIT-HAMLET.ARPA
Subject: Hint for VMS Binary File Transfer using Kermit
If one has two VMS Vaxes connected together with RS-232 ports, binary files
will transfer OK, using 8-bit data. The catch is that Kermit cannot possibly
be taught about all of the wild and wonderful RMS file formats (how many are
there? 1.0e10?), so making a BACKUP set (which contains the RMS formats) and
transferring it via Kermit will work fine. Do a SET FILE TYPE FIXED in the
Kermits at both ends. This allows .EXE files to be transferred directly, and
BACKUP save sets to be transferred and read from after fixing up the block
size.
------------------------------
Date: Wed, 25 Sep 85 11:38:25 pdt
From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA
Subject: More Kermit Changes Comments
> -g rfn -a name
> changed ckcfns.c to try treating "-a name" as a directory name
> bug: zopeno gives an err msg if the name is a directory,
> even though it works.
> [Ed. - This is a little tricky, not sure it's worth it...]
It is consistent with other file transfer facilities such as uucp (and I
*needed* it for that reason). The code *is* a bit messy because I didn't dare
change the machine-dependent primitives like zopeno (I can't write or test new
VMS or Mac versions). I think adding an argument to zopeno will allow having
it do this operation (if appropriate for that opsys).
> eXIT command
>
> [Ed. - This is the most controversial area of all. First of all, case-
> sensitive commands are not in the spirit of Kermit. Second, giving the
The typed command is 'x' or 'xit'.
This is sometimes an essential feature, but not always desirable. How about
making this feature depend on a compile-time ifdef? Then the system manager
can control the use of this as appropriate.
Ken Poulton
------------------------------
Date: Tue, 24 Sep 85 18:43:32 pdt
From: "Scott Weikart; Community Data Processing" <cdp!scott@glacier>
Subject: Info-Kermit Digest V3 #21: Ken Poulton reactions
Here's my reactions to Ken Poulton's changes.
> !
> merged ! and other uses of fork to call new routine zexecl in ckufio
> zexecl does an exec, using 1) the shell defined by environment variable
> SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
> failing that, 3) /bin/sh.
I like it.
> control chars
> added conchr to ckutio and changes in ckucmd to support using the
> user's predefined control characters as he expects
I like it, for those systems that support it (and leave ^W as backward
delete word on SYSIII, etc).
> startup files
> 1) ./.kermrc 2) ~/.kermrc 3) /usr/local/lib/kermrc
> settable with -DKERMRC (as before) and -DSYS_KERMRC
> Note that order of first two is intentionally changed
I would like to have two system files, kermrc.1st and kermrc.lst.
.1st would be done first, then a user's (if any) would be done (i.e. either
1) or 2) above), then .lst. Basically, I want both defaults and mandatory
values, and this seems to be the only way to do it.
I think /etc might be a better place for the system-wide files, like
/etc/profile and /etc/cshprofile.
I'm not sure I like 1); it seems like a take file in the appropriate
directory would be safer.
> eXIT command
> added eXIT command - allows leaving Kermit w/o unlocking or dropping line
> added ttnohu to close the tty w/o hangup
> creates ~/UNLOCKttyxx to remind user
> EXIT deleted to avoid confusion
> (maybe this should be disabled on BSD systems as not needed)
I don't like it. I still think that pushing a subshell is the only reasonable
way to do it, with /usr/spool/uucp group accessible and kermit setgid (as I
described at length a while back). Of course, I can't bitch too much since
I'm not offering to implement it.
> #
> added comment command
> for documenting scripts
> (done with % by 4C(057))
>
> [Ed. - I used "%" for this to avoid confusion with shell scripts.]
But I'd *rather* have it be like shell scripts; my Emacs already assumes
that files with no or unknown extionsions use # as comment, and most
UNIX types will recognize # as comment. And I doubt that a kermit
script will often look like a shell script.
> locking
> now accepts existing lock files owned by the user (to support eXIT)
This seems good as long as it doesn't break when files or directories
or unreadable. At least some people could have it right.
------------------------------
Date: Thu Sep 26 1985 17:55:58
From: Marco Papa <papa%usc-cse.csnet@CSNET-RELAY.ARPA>
Subject: Comments on C-Kermit new features
These are my comments about the possible additional features or chhanges to
current features of C-Kermit.
1. SHELL stuff. OK.
2. Control chars. OK.
3. Startup files. BAD!!! Much better like it is now.
3. Exit command. BAD too!! I do not like case sensitivity, but much more
important I do not want users to leave locked lines around. There is really
no real advantage, and the risks are enormous.
4. Scripts with no echo. OK. In fact I hate to have my login script to show
right on the monitor the password I am using to login on another system.
Logging transactions is enough. After one has found the correct login
sequence there is absolutely no need to show it everytime.
5. comment command for shell scripts. OK together with 4.
6. locking. It won't work in most systems. System managers are becoming
more restrictive in letting users create locks owned by them.
Marco Papa
USC - Computer Science Dept.
UUCP: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!papa
CSNET: papa@usc-cse.csnet
ARPA: papa%usc-cse@csnet-relay.arpa
------------------------------
Date: Wed, 25 Sep 85 10:43:58 pdt
From: hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Use of '%' and '#' in Scripts
On the use of '%' or '#' for comments in scripts:
*Many* Unix programs allow '#' to introduce comments, not just shells.
In addition, some Unix systems allow "#! program" at the beginning of a file
to indicate that that file is a script for 'program' and should be executed
as such. This is usually used for csh scripts ("#! /bin/csh") but would
allow one to write executable kermit scripts by writing
#!/usr/local/bin/kermit
at the head of the file. Then (on systems which support this) one need only
type the script's filename to execute it with kermit.
Ken
------------------------------
Date: 25 Sep 85 09:22:11 EDT
From: GH0N@CMU-CC-TC
Subject: C-Kermit Works on HP Integral Kermit
This is in regard to whether C-Kermit 4C runs on the HP Integral. I have
gotten C-Kermit to run on the Integral with very little trouble. Make sys3
does get the job done, but you need to either remove the code that sets up
lock files, or have the lock files put in a directory that is guaranteed
to be there (such as /tmp). Another thing that crops up is that the C
compiler for the Integral has a bug in it (at least the version I have does)
that will cause it to report the sizeof() an array as being 0. Sizeof() on
lone variables and structures (including structures containing arrays) work
fine. The biggest hassle with making C-Kermit for the Integral is the fact
that you can't use make if you don't have either LOTS of memory or a hard
disk. To compile and link all the code takes about an hour.
Hope this helps.
Gordon Haverland
GH0N % CMU-CC-TC @ Carnegie Mailnet }
GH0N @ CMU-CC-TC BITnet } soon to be GH0N.TC.CC.CMU.EDU ?
...!cmu-cs-pt!cmu-cc-tc!gh0n uucp?
------------------------------
Date: Tue, 1 Oct 85 11:31:06 -0100
From: mcvax!philmds!duvel!frans@seismo.css.gov
Subject: C-Kermit EOF Bug
I've encountered a bug in C-Kermit v57.
The bug is that in ckcpro.c (and .w) a test is done on the return value of
reof. However reof() does *never* return a value. This makes ckcpro.c barf
sometimes that a file cannot be closed, but evidently there is no problem at
all. By the way reof() is declared in ckcfns.c. I could not find other
calls except for the one in ckcpro.c
Frans Meulenbroeks, Philips Microprocessor Development Systems
...!{seismo|philabs|decvax}!mcvax!philmds!frans
[Ed. - Right you are -- reof() should return the value that was returned to
it by clsof(), indicating whether the file was closed successfully or not.
Will be fixed in next release; noted in "beware file" till then.]
------------------------------
Date: Thu, 3 Oct 85 11:07:42 PDT
From: brian@sdcsvax.arpa (Brian Kantor)
Subject: C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
The routine 'unchar' in ckcker.h has a name conflict with the unsigned
character typedef included from sys/types.h. Changing it to 'myunchar'
permits Kermit to compile.
Brian Kantor UC San Diego
decvax\ brian@ucsd.arpa
akgua >--- sdcsvax --- brian
ucbvax/ Kantor@Nosc
[Ed. - Thanks, will change this in the next release, and note it in the beware
file until then.]
------------------------------
Date: Sat, 5 Oct 85 02:19:30 CDT
From: Stan Barber <neuro1!sob@rice.ARPA>
Subject: Masscomp Kermit
I submitted an version of 4.2 C-Kermit to the Masscomp Users Group that had
line-locking that would work (I hope) for most environments. I have not had a
chance to get the most recent release of 4C to add those features to it that
deal with the line-locking problem effectively.
make sys3 does just fine, if line-locking is not an issue. If it is, then my
mods would probably satisfy most. It is fortunate that the new version of UUCP
(BSD 4.3) supports a read/write by the world LCK directory to remove the need
for setuid programs.
I will be making the 4C version work on masscomp sometime soon, but 4.2 seems
to work for most people even with the bugs it has.
I will be happy to field any comments on the masscomp users group version.
Stan Barber
Baylor College of Medicine
sob@rice.edu
ihnp4!shell!neuro1!sob
------------------------------
Date: 20-Sep-85 14:33:10EDT
From: "KENNETH POOLE" <poole@nusc-ada>
Subject: NU-Machine Unix Kermit
I have done a simple mod of 4c(57) of the unix kermit for the NU-machine
unix from TI. This Unix is the one on the LMI Lambda-Plus machines.
Please indicate how you would like me to send you the mods for adding
to the main source. I modified ckutio,ckufio and ckuker.mak. Also,
please add my name to the list for the info-kermit digest. I was on
before, but we lost our arpanet software fo a while and i think i was
taken off the list. Thanks,
Ken Poole 849-6270
[Ed. - I tried to respond to this message, but couldn't seem to push a
message through. Ken, please send me context diffs...]
------------------------------
Date: Thu, 26 Sep 85 15:21:32 GMT
From: John Rainbow Messenger <jlm@uucp.stl>
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
Subject: Bug in C-Kermit Remote Commands under VAX/VMS
We have found a bug in the remote command execution code for the VMS version
of C-Kermit. The symptom was a complete failure to execute remote commands,
with a message of the form %F - Can't delete file (for instance).
The enclosed fix enables remote commands to be executed.
The patch is a context diff, and can be installed with the patch command.
[Ed. - Patch omitted, but listed in KER:CKVKER.BWR on CU20B.]
------------------------------
End of Info-Kermit Digest
*************************
-------