On Mon, 17 Feb 2020 11:16:50 +0100 Corinna Vinschen wrote: > On Feb 17 18:45, Takashi Yano wrote: > > 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. > > Ok. I just wonder if I should merge your patch into 3.1.3 as is for the > time being. It's better than the old state, right?
I think so. But I found a small bug in this patch, so please use v2 patch which I will submit soon. -- Takashi Yano <[email protected]>
