ahh@glyph.UUCP (Andy Heffernan) (12/23/90)
In article <37154@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: [...] > >Glad to hear my use of "CDraw 2.0" was a neat idea! One comment: it, like the >"Tetrix"-clone, leave the 3B1 console keyboard in a "weird" state regarding >the use of ESCape key ... this only affects those who use ksh in emacs mode >for either filename completion or for ESCape sequences to move back-and-forth >in the line. In other words, if you run either CDraw or Tetris, each ESCape >you type comes into the system as TWO escapes. Comparing the "before" and >"after" ``stty -a'' shows no obvious problem, but a minor problem it is; >solution is to log out and then log back in. Weird. Heh, heh -- I've seen a lot of this in the past few days. TAM development has its drawbacks, especially when you're just being introduced to the mystery of wrastop(3T) and friends. ("What?? Everything's backwards! [flip flip flip -- peruse peruse] Ooops...") I'm developing a program that displays X-Windows BDF fonts, and I've found that SIGINT'ing out of it provokes this double-ESC phenomenon. -- Even with a SIGINT-catcher that restores the cursor, wdelete()'s the window (for good measure) and calls wexit() -- all in the same sequence I use for normal termination (which leaves everything normal) ! More than ksh are affected -- anything that reads from stdin appears to suffer this strange malady -- even poor little od. The behavior of child processes affecting parent processes, and the lack of any obvious stty control which relates to this behavior suggests to me that I've somehow screwed up my console window, and asking init to make me a new one is the only recourse (as Thad notes). Is this an already-solved, common TAM-programming problem? Or an already-exposed bug? ("I would like to play nethack now.") -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "Buck leaned back, laughing his manly laugh and clutching his goiter in pain."
ahh@glyph.UUCP (Andy Heffernan) (01/04/91)
Shortly before I left for the holidays I received some mail regarding the double-ESC problem. I sent mail back requesting another hint as I got stuck with the first one, but I haven't gotten a response yet so I thought I'd throw this out to unix-pc at large. To review the problem, some TAM programs will leave a window in a strange state where each press of the ESC key actually yields two ESC characters into the input stream. A program I have under development causes this to happen whenever it treats stdin as its input file. Getting input from a file named in the argument list causes no problems, but than SIGINTs aren't recognized (shades of VM/CMS -- home of the Programs That Will Not Die). Enough of that, here's the hint I got (edited): " There's a flag (documented in /usr/include/sys/wd.h) that needs to be cleared. " ...and sure enough, $ grep ESC /usr/include/sys/wd.h #define ESC 1 /* received ESC (0x1b) */ #define CSI 2 /* received CSI (ESC [) */ #define WDESC 0x20 /* double esc flag */ ^^^^^ ^^^^^^^^^^^^^^^ Hey look! Hey look! According to the comments, this is a flag for the w_flags member of the windef structure. Well, this is lervly and everything, but where-oh-where does the windef chain(s) start? This constant beeping in vi is making me goofy. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "`Ha ha ha,' taunted Judy. `Your scaly exterior seems to be failing you!'"
ahh@glyph.UUCP (Andy Heffernan) (01/16/91)
In article <1991Jan07.045230.2540@quest.UUCP> ssb@quest.UUCP (Scott Sheldon Bertilson) writes: > > Just fiddled a little and found that the WIOCSESC can be used >to turn it off or on. Any non-zero argument enables it, and a >0 argument disables it: > ioctl(0, WIOCSESC, 0); /* disable */ > ioctl(0, WIOCSESC, 1); /* enable */ Yes, a fresh lead from my mysterious informant (actually it was Bob Manson, manson@cis.ohio-state.edu -- thanks, Bob) redirected me to that ioctl, and it seems to work. The return from the ioctl() also appears to be the old state of the flag. Very interesting. Of course, I don't understand the point of the flag, why it gets set in the first place, and why my news software continually fills in a stripped-down Followup-To line whenever I cross-post to unix-pc.general and comp.sys.att. I suppose I ought to be satisfied (heh). -- ------------------------------------------------------------------------- Andy Heffernan 文字 uunet!glyph!ahh
steve@digibd.com (Steve Wahl) (01/19/91)
In article <1551@glyph.UUCP> ahh@glyph.UUCP (Andy Heffernan) writes: >In article <1991Jan07.045230.2540@quest.UUCP> ssb@quest.UUCP (Scott Sheldon Bertilson) writes: >> >> Just fiddled a little and found that the WIOCSESC can be used >>to turn it off or on. Any non-zero argument enables it, and a >>0 argument disables it: >> ioctl(0, WIOCSESC, 0); /* disable */ >> ioctl(0, WIOCSESC, 1); /* enable */ > >Yes, a fresh lead from my mysterious informant (actually it was >Bob Manson, manson@cis.ohio-state.edu -- thanks, Bob) redirected me >to that ioctl, and it seems to work. The return from the ioctl() also >appears to be the old state of the flag. Very interesting. > >Of course, I don't understand the point of the flag, why it gets >set in the first place, and why my news software continually fills in >a stripped-down Followup-To line whenever I cross-post to unix-pc.general >and comp.sys.att. I think I understand the point of this flag. When parsing an input stream from a terminal, keys such as F1 and the arrow keys usually send a multiple character sequence, and these sequeces usually start with an ESC. If your parser receives an ESC, it can either be from pressing the ESC key or from pressing one of the function keys. The only way to tell the difference is to wait and see if the characters that follow make up the sequence that one of the function keys send; if not, it was just the escape key. In many cases, such as vi(1), the user wants the ESC alone to cause some action without pressing any more keys, so a timeout is usually used also -- if no more characters come in before the timeout expires, the program assumes that only the escape key was pressed. If the escape key always sent two escapes, the timeout wouldn't be necessary, and the keyboard input parsing routine would be much easier to write; one could also be more certain about whether the escape key was pressed or not. That's probably what this feature is used for (in the TAM routines, if I'm not mistaken). --> Steve -- Steve Wahl steve@digibd.com DigiBoard Inc. St. Louis Park, MN (612) 922-8055