Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!sri-unix!gwyn@BRL-VLD.ARPA From: gwyn@BRL-VLD.ARPA Newsgroups: net.unix-wizards Subject: Re: VT100 and bagbiting Message-ID: <1321@sri-arpa.UUCP> Date: Wed, 27-Jun-84 00:35:09 EDT Article-I.D.: sri-arpa.1321 Posted: Wed Jun 27 00:35:09 1984 Date-Received: Sat, 30-Jun-84 06:17:49 EDT Lines: 55 From: Doug Gwyn (VLD/VMB) Yes, the ESC key should be removed from ANSI X3.64-conforming terminals. The reason is that ESC indicates the start of an escape sequence and so it cannot have meaning by itself. What some people have done for things like screen editors to support user-typed ESCs is to see if the input queue is still empty a second or so after getting an ESC, and if so assuming that it could not have been the start of an escape sequence. I once modified a screen editor so that ESC ESC was taken as a user- typed ESC, and ESC-anything-else was assumed to be an escape sequence. All these kludges are caused by having an accessible ESC key. As to DC3/DC1, the old Teletypes did use them for controlling the attached paper tape units (DC1 = enable reader, DC2 = enable punch, DC3 = disable reader, DC4 = disable punch as I recall), but their meaning is just "device control". It is fairly easy to see how the DC3/DC1 flow control protocol logically evolved from this. As far as I know this in-band flow control protocol is not an ANSI standard, but it definitely is one of three industry standard asynch flow control protocols: DTR/CTS per-character handshaking (lousy over modems with most computer systems) ENQ/ACK master-slave handshaking (not suitable for real full- duplex interaction as we know it) DC3/DC1 (XOFF/XON) flow control (in both directions) My impression is that the vast majority of ASCII terminals being sold today provide DC3/DC1 flow control, usually as an option (often the DTR/CTS method is available as an alternative). This implies that it is a mistake for a programmer to expect a ^Q or ^S (DC1 or DC3) to be typed by the user. Indeed, years ago DEC published an internal standard that prohibited the use of ESC ^S ^Q (and maybe ^R ^T) as user-typed input for DEC program products. (I do not know how well this corporate standard was obeyed.) As a recent example, the Teletype model 5620 (reborn Blit) in its resident terminal mode does not transmit ^S or ^Q when they are typed on the keyboard, but it does transmit them automatically when its input buffer is nearly full and when the user puts it in SET-UP mode (i.e. DC3 is sent to suspend host transmission then DC1 is sent when the emergency is past). One could argue that user ^S ^Q should be coordinated with automatic DC3 DC1 (as on the DEC VT100), but (a) the resident terminal mode is not used for real 5620 work, and (b) the function keys can be programmed to send ^S and ^Q if desired. One of the great lossages on 4.2BSD is that DC3/DC1 flow control is not available in "RAW" mode, although the need for this support is actually dependent on the terminal hardware, not on whether or not an application program wants input canonicalization done. This non- orthogonality of the various things bundled into the meaning of "RAW" mode was fixed in the terminal driver supplied as part of UNIX System III and V. This may explain why AT&T UNIX users understand the use of DC3/DC1 flow control and BSD users think that its existence is a terminal design botch..