This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3 0/1] Pseudo console support in PTY (v3)

Hi Takashi,

The major changes from v2 is as follows.
My testing showed the following observations.

(3) Code page handling is refined a bit. Now, code page 65001 (UTF8)
      and native code page in your region should work without garbled
     characters. This works properly only on terminal which supports
Character output conversion works with my test program (using WriteConsoleW). Using java, output works too (with proper java encoding option), but non-ASCII input characters are replaced by and echoed as space.

If I try a non-Unicode terminal session, e.g. running mintty -o Locale=C -o Charset=CP1252 -, and enter a € key, mintty hangs. While you said it doesn't work (yet), it should better not hang at least. I'd like to repeat at this point that the whole mechanism should only be applied if a non-cygwin program is run. (If it were, entering € in bash would not block the terminal.)

(4) Synchronization between real terminal and pseudo console screen
     buffer is improved. For this, screen is cleared on startup of pty
     slave app. Also echo for key input is pushed into pseudo console
     screen buffer.
Do you actively synchronize anything? I thought this is not needed anymore (unlike winpty) because the ConPTY performs the adaptation.

Terminal reports "\033[6n" and "\033[0c" are apparently emulated and sent in reverse order; response to primary device attribute request is wrong (not what mintty would report). There is no response to secondary device attribute request ("\033[>0c") and others, e.g. '\033[18t' or '\033]10;?\033\' and many others; why can't these requests be passed to the terminal and handled transparently? (You explained something around handles before but I don't get the point.)

Output to alternate screen seems to be forced to the primary screen, mostly;
if I try to switch screen in various ways (menu, echo "\033[?1047h" > /dev/pty1, before or while cmd.exe runs), behaviour appears to be inconsistent and not as expected (expected behaviour is that any output goes to the active screen). Again, I don't see a need that you intercept this at all.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]