[PATCH] Cygwin: console: Change timing of set/unset xterm compatible mode.
Takashi Yano
takashi.yano@nifty.ne.jp
Mon Feb 17 09:46:00 GMT 2020
On Mon, 17 Feb 2020 10:00:15 +0100
Corinna Vinschen wrote:
> On Feb 16 17:13, Takashi Yano wrote:
> > - If two cygwin programs are executed simultaneousley with pipes
> > in cmd.exe, xterm compatible mode is accidentally disabled by
> > the process which ends first. After that, escape sequences are
> > not handled correctly in the other app. This is the problem 2
> > reported in https://cygwin.com/ml/cygwin/2020-02/msg00116.html.
> > This patch fixes the issue. This patch also fixes the problem 3.
> > For these issues, the timing of setting and unsetting xterm
> > compatible mode is changed. For read, xterm compatible mode is
> > enabled only within read() or select() functions. For write, it
> > is enabled every time write() is called, and restored on close().
>
> Oh well, I was just going to release 3.1.3 :}
>
> In terms of this patch, rather than to change the mode on every
> invocation of read/write/select/close, wouldn't it make more sense to
> count the number of mode switches in a shared per-console variable, i.e.
>
> LONG shared_console_info::xterms_mode = 0;
>
> on open:
>
> if (InterlockedIncrement (&xterm_mode) == 1)
> switch to xterm mode;
>
> on close:
>
> if (InterlockedDecrement (&xterm_mode)) == 0)
> switch back to compat mode;
>
> ?
Thanks for the advice. However this unfortunately does not work
in bash->cmd->bash case.
For cmd.exe, xterm mode should be disabled, however, the second
bash need xterm mode enabled.
On Mon, 17 Feb 2020 10:28:19 +0100
Corinna Vinschen wrote:
> On second thought, also consider that switching the mode and
> reading/writing is not atomic. You'd either have to add locking, or you
> may suffer the same problem on unfortunate task switching.
Hmm, it may be. Let me consider. It may need time, so please
go ahead for 3.1.3.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
More information about the Cygwin-patches
mailing list