lwv27@CAS.BITNET (Larry W. Virden ext. 2487) (06/18/91)
A user just had quite a strange problem for which I wondered if anyone had a fix. They are using the xterm from the latest MIT X11R4 tape, compiled for SunOS 4.1.1 . They are using OpenWindows 2.0. They performed a set command, which of course echoed their environment. Within their EXINIT variable were a number of map commands, including a series of escape sequences. When the shell got around to echoing out the map for Escape P (that is a capital P) the output ceased. It took a hard reset of the terminal to get input and output to resume. I assume that xterm's state table interpreting escape sequences has a problem. Unknown escape sequences should just fall out I would think- but instead are causing the program to 'cease' up. Anyone know what the fix is for this problem? Thanks! -- Larry W. Virden UUCP: osu-cis!chemabs!lwv27 Same Mbox: BITNET: lwv27@cas INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 America Online: lvirden
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (06/18/91)
> [when an xterm received] Escape P (that is a capital P) the output > ceased. It took a hard reset of the terminal to get input and output > to resume. > I assume that xterm's state table interpreting escape sequences has a > problem. Unknown escape sequences should just fall out I would > think- but instead are causing the program to [seize] up. > Anyone know what the fix is for this problem? ESC P is the 7-bit representation of X3.64's DCS (device control sequence) initiator. The DCS sequence is defined, according to the notes I took while reading X3.64, as Control strings: intro delimiter, one of OSC, PM, APC, DCS Gs...Gs closing delimiter, ST Presence of other controls or 10/0-15/15 is error, recovery not specified where Gs is "graphic character in a string, 2/0 to 7/14" and ST is either 9/12 or its corresponding 7-bit sequence ESC \. (Characters are specified in hexadecimal with the digits expressed in decimal with a slash between them; thus 7/14 is 0x7e and 9/12 is 0x9c, for example. This is the way the standard reads; it is not clear to me why ANSI chose such a weird way of writing them. Surely anyone capable of understanding their notation would be equally capable of understanding normal hex.) So xterm is entirely within its rights to go out to lunch; you are sending it a sequence which is in error (a DCS string with CR and LF and probably TAB control characters in it). Of course, one could wish it recovered from the error a little more gracefully :-) If you want to do this, go into VTPrsTbl.c in the xterm source and edit the definition of igntable and possibly iestable (see charproc.c for their usage) to have it return to CASE_GROUND_STATE when it sees a control character in igntable.... Or at least it looks as though that should work, based on a thirty-second perusal of VTPrsTbl.c and charproc.c. I haven't tried this, for the simple reason that I don't use xterm. (I believe mterm does this better than xterm does.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rchui@neptune.nswc.navy.mil (Chui) (06/22/91)
I am not quite understand your question. What is EXINIT relative to Escape sequences. If you want echo a Escape sequences or input a Escape sequences in vi editor. You must press ctrl-v 1st, then press the Escape sequences key. for example if I want to echo Esc]0;testingctrl-G I must type echo ctrl-v Esc ]0;testing ctrl-v ctrl-G <CR>