Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!ucbvax!WLV.IMSD.CONTEL.COM!mcc From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Newsgroups: comp.protocols.tcp-ip Subject: Re: Escape sequences over Telnet/TCP Message-ID: <9105051507.AA24545@WLV.IMSD.CONTEL.COM> Date: 5 May 91 15:07:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 52 Warner: -In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM> -mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: ->IAS, RSX, RSTS/E, TSX, VMS, etc. Standard handling of an -> by the terminal driver is to terminate the current read when ->received. -I don't recall the other operating systems well enough to comment, but -this IS *NOT* the case under VMS. The terminal driver "knows" about -VT100 escape sequences so it can do command line editing. Since these -escape sequences start with ESC, the terminal driver CAN'T abort the -read. Now if it gets , then it will abort the read with a -bad escape sequence. (Or maybe this is an RMS level function, it has -been a while....) Are you confusing observed behaviour with actual behaviour? Its been a number of years since I've looked at the VMS sources and at that time there was no command line editing; however, it would seem inappropriate to add command line editing into the terminal port driver (maybe its class--I keep getting confused as to which deals with the physical interface and which deals with the logical interface). I would suspect that there is no logic in the terminal driver that is check- ing to determine if the I/O request was issued by DCL. The usage of escape sequences are application dependent and in this case DCL is the application. If the terminal driver were interpreting escape sequences, receipt of a cursor up sequence would reposition the cursor one line up on the display and not display the previous command line on the current line. Terminal drivers for all of the above operating systems know about ANSI and DEC proprietary escape sequences. Except in the case of , the read completes with a successful status with the reason that an had been received. Assuming that the application had been using multi-byte buffers for its read operations, the status that an had been received can be used to switch to single byte reads until the entire escape sequence has been read. The application, at this point, performs whatever operations are appropriate for the escape sequence--perhaps, display the previous command line on the current line. Depending on the mode associated with the read, some of the terminal drivers will return a secondary status that is an encoded value that is a translation of the entire escape sequence. Some modes such as read-pass-all (essentially equivalent to Unix "raw" mode) ignore escape sequences in their entirety and only return a completed status when the receive buffer is exhausted. Having been involved in porting a TELNET client from a Unix environment some years ago, the interface to the terminal driver was, perhaps, the most difficult aspect of the port. Merton Campbell Crockett GTE Contel Federal Systems