From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Corbat Thomas
Sent: Tuesday, September 15, 2015 4:35 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Bug 159803: PTY in console mode on Windows
Hi Toni
Thanks for checking! I’m working on Windows 7 64bit too. It might depend on the compiler or the standard library implementation though. Currently, I use MinGW g++ 4.8.1 from mingw-builds (http://sourceforge.net/projects/mingwbuilds/).
My test program was very small: main function with an endless while loop. After checking again I figured out that it depends on whether I have an include to iostream or not. With include to iostream the program
crashes (in CDT with PTY, not in an external console). Without that include it works properly, as far as I can tell.
I actually wanted to check whether the PTY implementation can cope with sending EOT before closing the stream or not. Unfortunately, I cannot try it with the current behavior of my system. I’ll try another compiler.
Kind Regards
Thomas
Hi Thomas,
using winpty in console mode on Windows has always been an experimental feature which can only be enabled with -Dorg.eclipse.cdt.core.winpty_console_mode=true.
Anyway, I just tried it with a hello world project and some other programs. It seems to work for me (Windows 7 64-bit).
Please provide details about the target program, how you build it and on which version of Windows you run it.
Thanks,
Toni
Hi
Marc-André and I are currently investigating the ctrl-D issue (Bug 159803). While trying to figure out whether
a possible fix would have some issues on Windows I tried to use the PTY in console mode, explicitly enabled with -Dorg.eclipse.cdt.core.winpty_console_mode=true. This resulted in my target program to terminate immediately, regardless of whether it contained
I/O or not.
Has anybody recently used the PTY in console mode on Windows successfully? I remember that the corresponding flag in the run configuration had been disabled on Windows for quite some time (I don’t know whether it had been active at any
time at all), so it would have been required to set this explicitly using the system property mentioned above.
Any input on that issue is welcome!
Regards
Thomas