dennis@rlgvax.UUCP (Dennis Bednar) (01/08/86)
[Could someone see that this reaches mod.protocols.kermit? I don't
know the address of the moderator.]
Quick Overview
VT100 terminal generating XON/XOFF causes Kermit to think extra
command has been typed by person, but actually sent by terminal.
Seen during Kermit data transfer mode (Connected state) when
typing ESCAPE ? to request a help menu.
Details
While connected, I type ESCAPE ? to get the help menu.
Kermit prints the help menu, then mysteriously printed the status,
as if I had typed S in response to the Command > prompt, but I hadn't.
The problem is that typing control-s into the Command > prompt also
requests a status, *AND MY VT100 HAD XON/XOFF ENABLED*. The menu
for the connected command caused by vt100 terminal to send XOFF (control-s)
to stop the burst of characters in the menu, then later sent the XON
(control-q) to later resume the output. Well, the control-s generated
by my terminal accounts for why the the status command mysteriously happened.
I surmise that the control-q was sent as data over the communications line.
I verified this was the problem disabling XON/XOFF on my terminal, then the
ESCAPE ? command then properly waited for terminal input after sending
the Command > prompt. I did not verify with a Line Monitor.
Suggested Solution
I did not attempt to fix this minor vt100 XON/XOFF problem
in the kermit source code. Perhaps by temporarily enabling
recognition of XON/XOFF received on the tty side *before* outputting
the help menu, and by restoring it to enable XON/XOFF recognition
*after* outputting the help menu would do the trick.
--
Dennis Bednar Computer Consoles Inc. Reston VA 703-648-3300
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis
dennis@rlgvax.UUCPgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/11/86)
Aargh! PLEASE, all software developers: NEVER make ^S or ^Q a user-typed command! Far too many terminals usurp these ASCII codes (DC3/DC1, aka XOFF/XON) for use as hardware flow control. One would think the word had gotten out by now...