[ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 3.1.0-0.3

This release comes with a couple of new features and quite a few
bug fixes.

The most interesting changes:

- A revamp of the old FIFO code.  It should now be possible to open
  FIFOs multiple times for writing, something the old code failed on.
  Courtesy Ken Brown.

- Support the new pseudo console in PTY. Pseudo console is a new feature
  in Windows 10 1809, which provides console APIs on virtual terminal.
  With this patch, native console applications can work in Cygwin PTYs.
  Courtesy Takashi Yano.

Please test.

=======================================================================

What's new:
-----------

- Add 24 bit color support using xterm compatibility mode in Windows 10
  1703 or later.  Add fake 24 bit color support for legacy console,
  which uses the nearest color from 16 system colors.

- Support pseudo console in PTY. Pseudo console is a new feature
  in Windows 10 1809, which provides console APIs on virtual
  terminal. With this patch, native console applications can work
  in PTYs such as mintty, ssh, gnu screen or tmux.

- New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np,
  pthread_setaffinity_np, plus CPU_SET macros.

- New APIs: dbm_clearerr, dbm_close, dbm_delete, dbm_dirfno, dbm_error,
  dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store.


What changed:
-------------

- FIFOs can now be opened multiple times for writing.
  Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00047.html
             https://cygwin.com/ml/cygwin/2015-12/msg00311.html

- If a SA_SIGINFO signal handler changes the ucontext_t pointed to by
  the third parameter, follow it after returning from the handler.

- Eliminate a header file name collision with <X11/XLocale.h> on case
  insensitive filesystems by reverting <xlocale.h> back to <sys/_locale.h>.


Bug Fixes
---------

- Fix select() on console in canonical mode.  Return after one line is
  completed, instead of when only one key is typed.

- Make console I/O functions thread-safe.

- Define missing MSG_EOR.  It's unsupported by the underlying Winsock
  layer so using it in send(2), sendto(2), or sendmsg(2) will return -1
  with errno set to EOPNOTSUPP and recvmsg(2) will never return it.

- Fix a timerfd deadlock.
  Addresses: https://cygwin.com/ml/cygwin/2019-06/msg00096.html

- Fix sigpending() incorrectly returning signals for unrelated threads.
  Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00051.html

- Fix a hang when opening a FIFO with O_PATH.
  Addresses: https://cygwin.com/ml/cygwin-developers/2019-06/msg00001.html

- Don't append ".lnk" when renaming a socket file.
  Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00139.html

- Make tcsetpgrp() return -1 if its argument is negative.
  Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00166.html

- Avoid mistakenly moving a process under debugger control into the
  process group of the debugger.
  Addresses a problem visible in GDB 8.1.1, related to
  https://cygwin.com/ml/cygwin/2019-07/msg00166.html

- Return ENOEXEC from execve for arbitrary files only if the files are
  executable.
  Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00054.html

- Fix off-by-one in environment evaluation leading to an abort.
  Addresses: https://cygwin.com/ml/cygwin-patches/2019-q3/msg00069.html

- Make output of /proc/[PID]/stat consistent with getpriority().
  Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00082.html

- 64 bit only: Avoid collisions between memory maps created with shmat
  and Windows datastructures during fork.
  Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html

=======================================================================


Have fun,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Biswapriyo Nath]

On Thursday, August 29, 2019, Corinna Vinschen <corinna-cygwin@cygwin.com>
wrote:
> Support the new pseudo console in PTY. Pseudo console is a new feature
 in Windows 10 1809, which provides console APIs on virtual terminal.

Some queries about this specific feature:

1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
be checked before use? Also what the FIXME says, isn't clear. Any hint?

1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
it easier to get all the pseudo console function pointers in one
constructor?

2. There are many defined values are added but those are also present in
mingw-w64 current git repo. For example, ENABLE_VIRTUAL_TERMINAL_PROCESSING.

3. I can't reproduce this issue with exact steps. But when I zoom in/out +
resize mintty window + execute cmd.exe in mintty in some random order it
crashed. Here is the error:

[main] D:\Cygwin64\bin\bash 1129
fhandler_pty_slave::push_to_pcon_screenbuffer: pty0: pcon_attach
mismatch?????? (0x18035DBD0)

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

[CC Takashi]

On Aug 29 22:15, Biswapriyo Nath wrote:
> On Thursday, August 29, 2019, Corinna Vinschen <corinna-cygwin@cygwin.com>
> wrote:
> > Support the new pseudo console in PTY. Pseudo console is a new feature
>  in Windows 10 1809, which provides console APIs on virtual terminal.
> 
> Some queries about this specific feature:

Please note that this is very likely not the final version.  I'm
planning for a release end of october or early november so there's
still lots of time to fix issues.  However, this is a great new feature
which needs good testing, that's why we do these test releases.

> 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> be checked before use? Also what the FIXME says, isn't clear. Any hint?

Yeah, right.  What happens on pre-W10 1809 systems?  They probably
crash on TIOCSWINSZ.  See below.

> 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
> it easier to get all the pseudo console function pointers in one
> constructor?

In terms of GetModuleHandle/GetProcAddress the right thing to do is to
use the autoload feature, i.e., add the functions to autoload.cc like
this:

  LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
  LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
  LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)

If the function call returns FALSE with GetLastError() ==
ERROR_PROC_NOT_FOUND, then the function is not available.

Takashi, I didn't actually notice the usage of the Windows heap here.
The usual method is to use a tls_pbuf buffer, and rather than
using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
sys_wcstombs.

Also, can you please change the camelback names in class tty_min to
underscored writing, e.g., term_codepage rather than TermCodePage?

> 2. There are many defined values are added but those are also present in
> mingw-w64 current git repo. For example, ENABLE_VIRTUAL_TERMINAL_PROCESSING.

We can only use what's part of the current w32api-headers package.

> 3. I can't reproduce this issue with exact steps. But when I zoom in/out +
> resize mintty window + execute cmd.exe in mintty in some random order it
> crashed. Here is the error:
> 
> [main] D:\Cygwin64\bin\bash 1129
> fhandler_pty_slave::push_to_pcon_screenbuffer: pty0: pcon_attach
> mismatch?????? (0x18035DBD0)

Takashi?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Takashi Yano]

Hi Biswapriyo and Corinna,

Thank you very much for testing.

On Fri, 30 Aug 2019 09:55:23 +0200
Corinna Vinschen wrote:
> On Aug 29 22:15, Biswapriyo Nath wrote:
> > On Thursday, August 29, 2019, Corinna Vinschen <corinna-cygwin@cygwin.com>
> > 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> > be checked before use? Also what the FIXME says, isn't clear. Any hint?
> 
> Yeah, right.  What happens on pre-W10 1809 systems?  They probably
> crash on TIOCSWINSZ.  See below.

This code is protected by
if (getPseudoConsole () && ...
that is, pseudo console handle is set only if CreatePseudoConsole()
successes. In pre-W10 1809, since pseudo console handle is not set,
this code is not reached. However, it is better to check before
call as you suggest.

What is meant in FIXME comment:
ResizePseudoConsole() needs handle to pseudo console. This handle is
valid only in the process which created it. If ioctl(TIOCSWINSZ, ...)
is called from other process, it fails. I had tried DuplicateHandle(),
but it did not work. Therefore, ResizePseudoConsole() is called
only if ioctl() is called from PTY master process. Similarly,
ClosePseudoConsole() can work only in the master process.

> > 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
> > it easier to get all the pseudo console function pointers in one
> > constructor?
> 
> In terms of GetModuleHandle/GetProcAddress the right thing to do is to
> use the autoload feature, i.e., add the functions to autoload.cc like
> this:
> 
>   LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
>   LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
>   LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)
> 
> If the function call returns FALSE with GetLastError() ==
> ERROR_PROC_NOT_FOUND, then the function is not available.
> 
> Takashi, I didn't actually notice the usage of the Windows heap here.
> The usual method is to use a tls_pbuf buffer, and rather than
> using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
> sys_wcstombs.
> 
> Also, can you please change the camelback names in class tty_min to
> underscored writing, e.g., term_codepage rather than TermCodePage?

OK. I will revised the code followed to your advice.

First, I would like to fix some bugs and will post a patch.
Second, I will revise the coding style.

May I post them as indivisual patches? I also suppose the patch should
be against the v9 patch, right?

> > 3. I can't reproduce this issue with exact steps. But when I zoom in/out +
> > resize mintty window + execute cmd.exe in mintty in some random order it
> > crashed. Here is the error:
> > 
> > [main] D:\Cygwin64\bin\bash 1129
> > fhandler_pty_slave::push_to_pcon_screenbuffer: pty0: pcon_attach
> > mismatch?????? (0x18035DBD0)
> 
> Takashi?

This most likely is caused by a bug. Now, I am looking into this problem.
I have found the culprit, maybe.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

On Aug 31 03:20, Takashi Yano wrote:
> On Fri, 30 Aug 2019 09:55:23 +0200
> Corinna Vinschen wrote:
> > On Aug 29 22:15, Biswapriyo Nath wrote:
> > > On Thursday, August 29, 2019, Corinna Vinschen <corinna-cygwin@cygwin.com>
> > > 1a. In fhandler_pty_mater::ioctl function, shouldn't the function pointer
> > > be checked before use? Also what the FIXME says, isn't clear. Any hint?
> > 
> > Yeah, right.  What happens on pre-W10 1809 systems?  They probably
> > crash on TIOCSWINSZ.  See below.
> 
> This code is protected by
> if (getPseudoConsole () && ...
> that is, pseudo console handle is set only if CreatePseudoConsole()
> successes. In pre-W10 1809, since pseudo console handle is not set,
> this code is not reached. However, it is better to check before
> call as you suggest.
> 
> What is meant in FIXME comment:
> ResizePseudoConsole() needs handle to pseudo console. This handle is
> valid only in the process which created it. If ioctl(TIOCSWINSZ, ...)
> is called from other process, it fails. I had tried DuplicateHandle(),
> but it did not work. Therefore, ResizePseudoConsole() is called
> only if ioctl() is called from PTY master process. Similarly,
> ClosePseudoConsole() can work only in the master process.

Ah, that makes sense.

> > > 1b. GetModuleHandle and GetProcessHeap is called several times. Wouldn't be
> > > it easier to get all the pseudo console function pointers in one
> > > constructor?
> > 
> > In terms of GetModuleHandle/GetProcAddress the right thing to do is to
> > use the autoload feature, i.e., add the functions to autoload.cc like
> > this:
> > 
> >   LoadDLLfuncEx (ClosePseudoConsole, 4, kernel32, 1)
> >   LoadDLLfuncEx (CreatePseudoConsole, 20, kernel32, 1)
> >   LoadDLLfuncEx (ResizePseudoConsole, 8, kernel32, 1)
> > 
> > If the function call returns FALSE with GetLastError() ==
> > ERROR_PROC_NOT_FOUND, then the function is not available.
> > 
> > Takashi, I didn't actually notice the usage of the Windows heap here.
> > The usual method is to use a tls_pbuf buffer, and rather than
> > using MultiByteToWideChar/WideCharToMultiByte, use sys_mbstowcs/
> > sys_wcstombs.
> > 
> > Also, can you please change the camelback names in class tty_min to
> > underscored writing, e.g., term_codepage rather than TermCodePage?
> 
> OK. I will revised the code followed to your advice.
> 
> First, I would like to fix some bugs and will post a patch.
> Second, I will revise the coding style.
> 
> May I post them as indivisual patches?

That would be great.  Individual patches with each of them fixing just
a single problem are definitely preferrable over bulk patches.  Please
send them to the cygwin-patches mailing list.

>  I also suppose the patch should be against the v9 patch, right?

Well, actually they should be against current git master.  Incidentally
that's your v9 patch ;)


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Biswapriyo Nath]

On Friday, August 30, 2019, Takashi Yano <takashi.yano@nifty.ne.jp> wrote:

> If ioctl(TIOCSWINSZ, ...)
is called from other process, it fails.

The HPCON isn't a handle. It's a pointer of a struct of three handles. In
my opinion, I think it's consistent with pty functions in libc. Like in
forkpty(2) the pid is returned in master side, here HPCON is same.

Q: From which process do you want to access it?

To know more about the ConPTY internals here are two of my sample program:

* XConPty: https://github.com/Biswa96/XConPty
* wslbridge2: https://github.com/Biswa96/wslbridge2/tree/master/rawpty

** Do not use that code in cygwin. It's undocumented. **

Thank you <3

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Takashi Yano]

On Sat, 31 Aug 2019 02:51:34 +0530
Biswapriyo Nath wrote:
> On Friday, August 30, 2019, Takashi Yano <takashi.yano@nifty.ne.jp> wrote:
> The HPCON isn't a handle. It's a pointer of a struct of three handles. In
> my opinion, I think it's consistent with pty functions in libc. Like in
> forkpty(2) the pid is returned in master side, here HPCON is same.

Then, is it possible to DuplicateHanlde() for three handles in HPCON
to other process which calls ioctl() with new HPCON?

> Q: From which process do you want to access it?

Just a posibility. Some programs may open pty in a process, call
fork(), exit the process and call ioctl in the fork'ed process.

> To know more about the ConPTY internals here are two of my sample program:
> 
> * XConPty: https://github.com/Biswa96/XConPty
> * wslbridge2: https://github.com/Biswa96/wslbridge2/tree/master/rawpty

Oh! Is that your work? I already know XConPty site and I wondered
what is this and how the auther knows such internal things.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Biswapriyo Nath]

To Corinna Vinschen:

> We can only use what's part of the current w32api-headers package.

I occasionally contribute to mingw-w64 repository. Is there anything I can
do so that cygwin uses latest headers and libraries from mingw-w64?

To Takashi Yano:

> Then, is it possible to DuplicateHandle() for three handles in HPCON to
other process which calls ioctl() with new HPCON?

** THE FOLLOWING PROCEDURE USES UNDOCUMENTED AND UNSTABLE CODE **

To use HPCON in another process, first cast it to a pointer of struct of
three handles as below:

    struct HPCON_INTERNAL {
        HANDLE hWritePipe;
        HANDLE hConDrvReference;
        HANDLE hConHostProcess;
    };

    HPCON hpCon;
    HRESULT hRes = CreatePseudoConsole(consoleSize, hPipePTYIn,
hPipePTYOut, 0, &hpCon);
    HPCON_INTERNAL *hpConInt = hpCon;

Then **inherit** and use hpConInt->hWritePipe to write the resize signal.
Get detail information about that buffer here[1]. Sample in my repo[2].

[1]:
https://github.com/microsoft/terminal/blob/master/src/host/PtySignalInputThread.cpp
[2]: https://github.com/Biswa96/wslbridge2/blob/master/rawpty/rawpty.cpp

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Sep  1 12:00, Biswapriyo Nath wrote:
> To Corinna Vinschen:
> 
> > We can only use what's part of the current w32api-headers package.
> 
> I occasionally contribute to mingw-w64 repository. Is there anything I can
> do so that cygwin uses latest headers and libraries from mingw-w64?

This is JonY's domain, he's the maintainer of the w32api-headers
package.  However, there's not much pressure since we can always
define our own macros temporarily inside Cygwin.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Biswapriyo Nath]

While compiling cygwin with gcc version 7.4.0 (GCC) this error is shown:

Making all in reent
/d/newlib-cygwin/newlib/libc/reent/execr.c: In function ‘_wait_r’:
/d/newlib-cygwin/newlib/libc/reent/execr.c:120:14: warning: implicit
declaration of function ‘_wait’; did you mean ‘wait’?
[-Wimplicit-function-declaration]
   if ((ret = _wait (status)) == -1 && errno != 0)
              ^~~~~
              wait

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Corinna Vinschen]

[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]

On Sep  3 14:56, Biswapriyo Nath wrote:
> While compiling cygwin with gcc version 7.4.0 (GCC) this error is shown:
> 
> Making all in reent
> /d/newlib-cygwin/newlib/libc/reent/execr.c: In function ‘_wait_r’:
> /d/newlib-cygwin/newlib/libc/reent/execr.c:120:14: warning: implicit
> declaration of function ‘_wait’; did you mean ‘wait’?
> [-Wimplicit-function-declaration]
>    if ((ret = _wait (status)) == -1 && errno != 0)
>               ^~~~~
>               wait

The attached patch should fix it.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #1.2: 0001-Cygwin-sys-wait.h-Add-_wait-prototype-to-avoid-compi.patch --]
[-- Type: text/plain, Size: 935 bytes --]

From 4d04ee50958deebc8c024cbb23f6164f0bf21ae1 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
Date: Tue, 3 Sep 2019 12:45:55 +0200
Subject: [PATCH] Cygwin: sys/wait.h: Add _wait prototype to avoid compiler
 warning

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 winsup/cygwin/include/sys/wait.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/winsup/cygwin/include/sys/wait.h b/winsup/cygwin/include/sys/wait.h
index 97e5d9998114..1ed1f5a2e801 100644
--- a/winsup/cygwin/include/sys/wait.h
+++ b/winsup/cygwin/include/sys/wait.h
@@ -22,6 +22,10 @@ pid_t waitpid (pid_t __pid, int *__status, int __options);
 pid_t wait3 (int *__status, int __options, struct rusage *__rusage);
 pid_t wait4 (pid_t __pid, int *__status, int __options, struct rusage *__rusage);
 
+#ifdef _COMPILING_NEWLIB
+pid_t _wait (int *);
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Jim Reisert AD1C]

Since I started using this version, I've been having some strange
hangs running g++ (called from make).  The compilation just hangs
(probably at the link stage).  The .o file is generated but the .exe
is not.  If I remove the .o file and try again, sometimes it works.

I had been running the August 09 version of Cygwin at work and have
never seen the problem there.

Does this ring any bells for anyone?  I just updated work to the 5
September test version, I'll see if the problem shows up.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Ken Brown]

On 9/5/2019 2:11 PM, Jim Reisert AD1C wrote:
> Since I started using this version, I've been having some strange
> hangs running g++ (called from make).  The compilation just hangs
> (probably at the link stage).  The .o file is generated but the .exe
> is not.  If I remove the .o file and try again, sometimes it works.
> 
> I had been running the August 09 version of Cygwin at work and have
> never seen the problem there.
> 
> Does this ring any bells for anyone?  I just updated work to the 5
> September test version, I'll see if the problem shows up.

3.1.0-0.3 had some bugs that were fixed in today's 3.1.0-0.4 release.  Please 
report back after trying it.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Jim Reisert AD1C]

On Thu, Sep 5, 2019 at 8:23 PM Ken Brown wrote:

> 3.1.0-0.3 had some bugs that were fixed in today's 3.1.0-0.4 release.  Please
> report back after trying it.

I'm glad to hear this, because I upgraded to 3.1.0-0.4 at work today
and could not duplicate the problem.  I just upgraded at home and was
not easily able to demonstrate the problem there either.  I'll keep
watching for any strangeness.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Thomas Wolff]

Am 29.08.2019 um 14:22 schrieb Corinna Vinschen:
> - Support the new pseudo console in PTY.
A tool that sets up conpty itself (rawpty from 
https://github.com/Biswa96/wslbridge2) does not work anymore with 
conpty-enabled cygwin. This suggest that double-conpty enabling may be 
interfering.
Unfortunately, I have not yet had the time to checkout the patch code in 
detail, but my suspicion is that conpty may be enabled always, while it 
should in fact be activated only if a non-cygwin program is run.
Please check out on this.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Takashi Yano]

On Fri, 6 Sep 2019 12:02:36 +0200
Thomas Wolff wrote:
> A tool that sets up conpty itself (rawpty from 
> https://github.com/Biswa96/wslbridge2) does not work anymore with 
> conpty-enabled cygwin. This suggest that double-conpty enabling may be 
> interfering.
> Unfortunately, I have not yet had the time to checkout the patch code in 
> detail, but my suspicion is that conpty may be enabled always, while it 
> should in fact be activated only if a non-cygwin program is run.
> Please check out on this.

I have not looked into this yet, but as you might expect, the pseudo
console is always enabled behind even if it is not used.

Owing to this, a cygwin program which directly accesses the console,
as your previous test case, can work normally by just switching the
r/w pipe to pseudo console side.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.3

[Thomas Wolff]

Am 07.09.2019 um 05:32 schrieb Takashi Yano:
> On Fri, 6 Sep 2019 12:02:36 +0200
> Thomas Wolff wrote:
>> A tool that sets up conpty itself (rawpty from
>> https://github.com/Biswa96/wslbridge2) does not work anymore with
>> conpty-enabled cygwin. This suggest that double-conpty enabling may be
>> interfering.
>> Unfortunately, I have not yet had the time to checkout the patch code in
>> detail, but my suspicion is that conpty may be enabled always, while it
>> should in fact be activated only if a non-cygwin program is run.
>> Please check out on this.
> I have not looked into this yet, but as you might expect, the pseudo
> console is always enabled behind even if it is not used.
>
> Owing to this, a cygwin program which directly accesses the console,
> as your previous test case, can work normally by just switching the
> r/w pipe to pseudo console side.
I guess you are right. We are having different use cases. For the 
generic case, the always-enabled conpty support is probably the best 
solution. However, there are exceptions. One particular case is the 
gateway to WSL (wslbridge, wslbridge2, hvpty). When you run WSL from 
cygwin with conpty enabled, unfortunately, the pseudo console will 
enforce MS's idea of what a terminal is, i.e., it handles escape 
sequences, does not pass everthing through, responds to enquiry 
sequences itself, so the terminal cannot even report itself as mintty 
(or whatever) anymore.
This unfortunate situation may hopefully resolve once they provide 
conpty "passthrough mode" as discussed in 
https://github.com/microsoft/terminal/issues/1173 and also in 
https://github.com/mintty/wsltty/issues/171#issuecomment-526778377.
So there is need to switch off conpty support for certain applications, 
e.g. via the CYGWIN environment variable. Please consider.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple