Re: cygwin 3.1 pseudo console in PTY and break/ctrl-c handling
On 19.02.2020 21:21, Brian Inglis wrote: On 2020-02-19 13:02, Kevin Schnitzius via cygwin wrote: On Tuesday, February 18, 2020, 05:54:23 PM EST, Thomas Wolff wrote: With 3.1.2-1: mintty -o "CA+F12:break" => ctrl-alt-F12 causes a break and kills notepad mintty -o "c:break" => ctrl-shift-c causes a break and kills notepad mintty -o "C+c:break" => FAIL -- ctrl-c kills native apps but notepad is not affected mintty -o "CA+c:break" => FAIL -- ctrl-alt-c kills native apps but notepad is not affected This would be mintty -o KeyFunctions='CA+F12:break' etc. The latter two are not valid mintty configuration; Ctrl is only supported as a modifier for function keys and special keys, not letters. This is unchanged with the cygwin version. Ah, thank you. That was the clue that I needed. For those also having this problem: mintty.exe -o "KeyFunctions=c:break" -o CtrlExchangeShift=true - will propagate Ctrl-C to the non-native apps and kill them, imitating the behavior of 3.0.X Cygwin. Now that I have played with this for a while, I am thinking that I like the new behavior better and I have assigned a new key to specifically kill native Windows programs instead letting the Ctrl-C do all the work (I am using Alt-F5 to do this). Should the above settings not be the default behaviour for backward compatibility and least surprise to users? I was just taking up the requester's example. Sure ^C is an interrupt function on the command line. This is handled by the pty driver, not by the terminal. The above configuration is a mintty feature of assigning functions (of which break is just one special case) to key combinations, independent of the stty settings. It used to be mintty just worked as expected with most programs, now additional interfaces seem to be required depending on Windows versions, editions, and releases. These helpers should either be included in the package, or be dependencies pulled in by mintty without which it will not install, with the appropriate interfaces installed and configured so that mintty, shells, and programs run under it continue to work as expected. Some recently reported observations are related to the ConPTY project. There have been no changes in mintty concerning keyboard handling. -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
On 20.02.2020 05:00, Eugene Klimov wrote: additional have you tried to set "disable_pcon" ? https://cygwin.com/cygwin-ug-net/using-cygwinenv.html yes i tried WIN+R cmd.exe ``` C:\cygwin64>SET CYGWIN=disable_pcon C:\cygwin64>echo %CYGWIN% disable_pcon ``` press ALT+SPACE - worked, window menu showed ``` C:\cygwin64>bash Slach@SLACH-PC / ``` press ALT+SPACE doesn't work That's because the cygwin console handler interprets Alt+Space itself and sends ESC Space. Same behaviour in mintty if you disable the "Menu and Full screen" option. ``` $ exit exit C:\cygwin64> ``` press ALT+SPACE works again -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
> > press ALT+SPACE doesn't work > That's because the cygwin console handler interprets Alt+Space itself > and sends ESC Space. Same behaviour in mintty if you disable the "Menu > and Full screen" option. how to turn off interprets ALT+SPACE by cygwin console and pass this hotkey to window handler? -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
On Thu, 20 Feb 2020 09:50:44 +0500 Eugene Klimov wrote: > > > inside windows 10 (build 1909) > > > just open WIN+R cmd.exe > > This start cmd.exe. > > > type > > > `ssh root@my_redhat_entrise_linux_7.2` > > This uses windows OpenSSH to connect linux. > no, i install cygwin ssh package > and i have `c:\cygwin64\bin\` in PATH environment rather than > `c:\windows\system32\OpenSSH` > so ssh.exe it's a cygwin process > > > This runs screen command in Linux. > > Where does Cygwin's concern? > ;) as I see it's more related to old `screen` version inside RHEL 7.2 > than cygwin concern ;( > > I tried to run > `C:\Windows\System32\OpenSSH\ssh.exe root@my_rhel_72_host` > and found bugs which look like same under Cygwin ssh, but different > little bit ;-) > also, I run > `C:\Windows\System32\OpenSSH\ssh.exe -i private_key vagrant@127.0.0.1 -p ` > and on my Ubuntu 18.04 screen works fine > > > > and view lot of bugs with wrong keys behaviors: > > > - ctrl+space hotkey not worked (not only in `screen`, but in any cygwin > > > executable) > > What is your expectation by ctrl+space? This normally sends > > ^@ (0x00) to client. Is this as you expected? > sorry to mislead you > I mean `ALT+SPACE` > it's a hotkey for show window main menu > > > > - `left arrow`, `backspace` and `delete` keys works wrong like a `right > > > arrow` > > What happen if you use these keys? > under latest cygwin 3.1.4 + ssh 8.2p1-1 behavior look like I press > space or press "right arrow" > https://recordit.co/thJJRbFzUp > > under win32 openssh behavior different > https://recordit.co/ffAqC8BvtC > > under cygwin1.dll 3.0.7 and c:\cygwin64\bin\ssh.exe 8.2p1-1 behavior > look like normal > https://recordit.co/E0E8sfWGyY I could reproduce your problem with screen 4.02.01 in debian jessie. I also found this does not occur if vbell off is added to .screenrc However, this seems to be a problem in xterm emulation of windows. So, I will make a patch (just a workaround) for this issue. -- Takashi Yano -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
On Thu, 20 Feb 2020 14:51:21 +0500 Eugene Klimov wrote: > > > press ALT+SPACE doesn't work > > That's because the cygwin console handler interprets Alt+Space itself > > and sends ESC Space. Same behaviour in mintty if you disable the "Menu > > and Full screen" option. > how to turn off interprets ALT+SPACE by cygwin console and pass this > hotkey to window handler? In cygwin 3.1.0 or later, Alt-space sends ESC+SPACE (0x1b 0x20) to client as linux console. The new feature is disabled if legacy console mode is enabled, so it behaves as you expected with some sacrifice. -- Takashi Yano -- 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
Mingw pkg-config not working
Hello, I discovered that the mingw cross compilers for i686 and x86-64 have a problem with support of pkg-config. From what I have seen, the mingw included into CYGWIN is not using the usual pkg-config, but it uses pkgconf instead, which is a good thing at first sight, since it does not depend to GLib. Unfortunately, this introduces a problem: the traditional i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config are emulated with a shell script, for example the one for i686 is: #!/bin/sh exec pkgconf --personality=i686-w64-mingw32 $@ But while this solution mostly works when you exec it from the command line, it makes impossible to detect the presence of the tool from meson and cmake build systems. If you try to do this on the bash prompt, you get: $ i686-w64-mingw32-pkg-config --version pkgconf: --version specified with other options or module names, assuming --modversion. Please specify at least one package name on the command line. and this is exactly what happens with those build systems (and perhaps others, I don't know): it tries to call pkg-config with "--version" and it executes the above script that calls pkgconf. But sadly, the presence of the "--personality" option makes the process to fail, because the "--version" is currently allowed only when no other options are added. And, for this reason, meson and cmake fail the detection of the tool. I have also filed an issue here for pkgconf: https://todo.sr.ht/~kaniini/pkgconf/10 because the solution is actually to ignore the presence of the "--personality" option when the "--version" is written, but unfortunately I have not received any feedback. So, I'm also writing here, with the hope that you could find a solution. This behavior is easy to verify, just write that command at the prompt of the shell, or try to build something that uses the detection of the tool: in my case, I found it when I tried to build the audacious media player from sources. Thank you very much for your time and your support. Sincerely. -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
> In cygwin 3.1.0 or later, Alt-space sends ESC+SPACE (0x1b 0x20) > to client as linux console. > The new feature is disabled if legacy console mode is enabled, > so it behaves as you expected with some sacrifice. ok, i understood, but it sad use CTRL+SHIFT+V instead ALT+SPACE+3 times UP+RIGHT+2 times DOWN + ENGER for paste value from the clipboard ;) is enough for me ;) -- 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: howto rollback cygwin 3.1.4-1 to older 3.0.7 version?
> I also found this does not occur if > vbell off > is added to .screenrc oh! thanks a lot, it a really helpful suggestion -- 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
Is Cygwin 3.1.X Stable Enough to Use?
I am worried. I need to instruct an IT department to install Cygwin. I am afraid that if I just tell them to run the installer, they will get an unstable version. I am afraid other new users will be in the same boat. I am fine for myself: I am on Cygwin 3.07, it is a tank, and I can stay there for the rest of the year if necessary. That is not the issue. Would it make sense for Disable_pcon (spelling?) to be the default, until the new pty code settles down? --- Karl Botts, kdbo...@usa.net -- 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: CYGWIN env variable - glob option
Some further investigations. 1. I missed the comment "default is set". So setting CYGWIN=glob is irrelevant. I may still want to set CYGWIN=glob:ignorecase, but that's a separate matter. 2. With forward slashes, globbing works as expected: E:\Utils\Cygwin64\bin\echo E:/Work/Scratch/m*.py E:/Work/Scratch/markov_pmf.py E:/Work/Scratch/monopoly.py However, with backslashes it does not: >E:\Utils\Cygwin64\bin\echo E:\Work\Scratch\*.py E:\Work\Scratch\*.py I can understand that the conflict between Windows using backslash as a directory separator and Unix using it as an escape character makes for a difficult problem, but nevertheless, the current behaviour is problematic for me (I won't say "wrong", because clearly plenty of people are fine with it, but it doesn't suit my use case, and I don't know if there's any setting I can use to improve things). Basically my issue is that I want to use cygwin from a Windows shell (powershell). I do *not* run cygwin commands from the cygwin shell - I am very familiar with, and comfortable in, powershell, but I do need Unix-like commands like grep, diff, etc, and cygwin provides the most reliable forms of those commands (good Unicode support, no weird bugs or porting glitches...) I routinely tab-complete directory names, with things like "grep so*.py" which autocompletes on tab to "grep .\sources\" and then I add "*.py". So it's fairly important for me that backslash-separated pathnames work. I don't know how unusual this is - I hear many people talking about using cygwin tools to get Unix-like utilities on Windows, but I don't know if the common use is via a cygwin shell (with a full Unix experience) or mixing Cygwin into a Windows shell like I do. If cygwin isn't intended to fit seamlessly into this use case, then that's fine - I'll just need to find an alternative way of getting Unix-like commands (maybe go back to mingw-compiled versions, and accept their limitations). But if there *is* a way to get things to work for my situation, I'd be disappointed if I missed it :-) If there *isn't* an option like that, is it something that could be added to the existing globbing code? I've never contributed to cygwin, but how easy would such a change be? Paul On Wed, 19 Feb 2020 at 16:46, Paul Moore wrote: > > I'm not sure if I'm misunderstanding the documentation of the "glob" > option in the CYGWIN environment variable. I have (this is under > Powershell Core 7.0.0-rc2): > > $env:CYGWIN="glob:ignorecase winsymlinks:native" > > if I then try to grep in a file that exists, using wildcards to > specify it, I get > > > C:\Utils\Cygwin64\bin\grep.exe . C:\Work\Scratch\mkpip*.ps1 > /usr/bin/grep: C:\Work\Scratch\mkpip*.ps1: No such file or directory > > Using echo as a (presumably) simpler test case: > > >C:\Utils\Cygwin64\bin\echo.exe C:\Work\Scratch\*.ps1 > C:\Work\Scratch\*.ps1 > > >C:\Utils\Cygwin64\bin\ls.exe -l C:\Work\Scratch\ > total 1121 > -rwxr-xr-x 1 Gustav Gustav 1144832 Feb 17 15:15 DigraphMgr.exe > -rw-r--r-- 1 Gustav Gustav 172 Jan 23 10:37 mkpipclone.ps1 > > I thought that the glob option resulted in glob expansion being done > before the args are passed to the grep command, so my expectation was > that this would work. > > This is with the very latest cygwin DLL - 3.1.4-1. I tried downgrading > to 3.1.2 (the earliest the installer offered) but that was no > different. The odd thing is that I thought I'd tested this on anther > machine, but now I can't get it to work as I expect :-( > > Am I doing something wrong? Or are my expectations incorrect? I need > to work with "native" backslash-delimited path names, because that's > how my shell autocompletes directory names, and patching them up with > forward slashes isn't really an option for me. > > Paul -- 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: Is Cygwin 3.1.X Stable Enough to Use?
Greetings, KARL BOTTS! > I am worried. I need to instruct an IT department to install Cygwin. I am > afraid that if I just tell them to run the installer, they will get an > unstable version. I am afraid other new users will be in the same boat. Cygwin is a rolling release distribution. Whatever is in main installation set is considered stable. You could have found the answer yourself, if you have used search through the list archive. > I am fine for myself: I am on Cygwin 3.07, it is a tank, and I can stay there > for the rest of the year if necessary. That is not the issue. 3.0.7 is not supported anymore. -- With best regards, Andrey Repin Thursday, February 20, 2020 21:34:21 Sorry for my terrible english... -- 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: Pipes bug when spawning non-cygwin processes
Hi Takashi,
On Tue, Feb 18, 2020 at 2:43 PM Takashi Yano wrote:
> Could you please provide a simple test case?
Here you go:
// pipes.cpp
//
// Compile in a Visual Studio x64 Native Tools Command Prompt:
// cl pipes.cpp /link /subsystem:windows
//
// Run from inside a Cygwin shell, the produced pipes.exe
//
#include
#include
INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT)
{
printf("This message used to show up in mintty cygwin v.2.11.2 shell!
or from ssh session\n");
return 0;
}
// end of pipes.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
Salesforce Potential Business
Hi, I would like to know if you're interested in acquiring "Salesforce Users List" for your sales and marketing campaigns We also have related technology users like: Netsuite, Infor, Oracle Siebel, Microsoft Dynamics 365, Nimble, SAP, Sugar, Zoho, and many more. Let me know if you are interested so that I will get back to you with the Counts, Samples and Pricing for your review. Regards, Angela Corbett Sr. Marketing Manager If you are not interested please reply with "Not" In the S -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Andrey Repin wrote: > Greetings, KARL BOTTS! > >> I am worried. I need to instruct an IT department to install Cygwin. I >> am >> afraid that if I just tell them to run the installer, they will get an >> unstable version. I am afraid other new users will be in the same boat. > > Cygwin is a rolling release distribution. Whatever is in main installation > set is considered stable. I suspect that "unstable" in this context means "likely to have noticeable problems". For whatever it's worth, the only problem I've noticed with 3.1.4 was ansi control character handling and that was fixed by importing this bit into the registry: - Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "VirtualTerminalLevel"=dword:0001 - On the plus side, it's HKEY_CURRENT_USER so you don't need admin privs to import it; on the minus side, it's HKEY_CURRENT_USER so you'll have to do it for every user on the machine that'll be using cygwin. Regards, Lee -- 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] Updated: Perl distributions
The following Perl distributions have been updated to their latest version on CPAN, respectively: x86/x86_64 -- perl-Cpanel-JSON-XS-4.19-1 perl-JSON-Parse-0.56-1 perl-Net-DNS-SEC-1.15-1 perl-Scalar-List-Utils-1.54-1 perl-Text-CSV_XS-1.41-1 noarch -- perl-Alien-Build-2.08-1 perl-CGI-4.46-1 perl-IO-Socket-SSL-2.067-1 perl-Mail-Message-3.009-1 perl-Mojolicious-8.33-1 perl-Net-DNS-1.22-1 perl-Test-MockModule-0.172.0-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On Thu, 20 Feb 2020 16:28:26 -0500 Lee wrote: > For whatever it's worth, the only problem I've noticed with 3.1.4 was > ansi control character handling and that was fixed by importing this > bit into the registry: > > - > Windows Registry Editor Version 5.00 > > [HKEY_CURRENT_USER\Console] > "VirtualTerminalLevel"=dword:0001 > - In what situation is registry modification obove necessary? -- Takashi Yano -- 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: Pipes bug when spawning non-cygwin processes
On Thu, 20 Feb 2020 14:33:27 -0500
Edward Lam wrote:
> On Tue, Feb 18, 2020 at 2:43 PM Takashi Yano wrote:
> > Could you please provide a simple test case?
>
> Here you go:
>
> // pipes.cpp
> //
> // Compile in a Visual Studio x64 Native Tools Command Prompt:
> // cl pipes.cpp /link /subsystem:windows
> //
> // Run from inside a Cygwin shell, the produced pipes.exe
> //
>
> #include
> #include
>
> INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT)
> {
> printf("This message used to show up in mintty cygwin v.2.11.2 shell!
> or from ssh session\n");
> return 0;
> }
> // end of pipes.cpp
Thanks for the test case. Indeed, this works upto cygwin 3.0.7,
and does not work in cygwin 3.1.0 or later.
However, I wonder what platform is your program for. This test
case does not work also in native windows command prompt.
Your test case works only in old cygwin pty.
If you want to make a program which works in cygwin pty, you
can use cygwin g++ like:
g++ -mwindows pipes.cpp -o pipes
The binary built by above command works in cygwin pty, but does
not work in cygwin console (cygwin in command prompt) even with
cygwin 3.0.7.
If you want to make a program which works with windows console,
you should change the code like:
INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT)
{
if (!AttachConsole(ATTACH_PARENT_PROCESS)) AllocConsole();
freopen("CONOUT$", "w", stdout);
printf("This message used to show up in mintty cygwin v.2.11.2 shell! or
from ssh session\n");
return 0;
}
--
Takashi Yano
--
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: Pipes bug when spawning non-cygwin processes
On Fri, 21 Feb 2020 10:01:21 +0900
Takashi Yano wrote:
> On Thu, 20 Feb 2020 14:33:27 -0500
> Edward Lam wrote:
> > On Tue, Feb 18, 2020 at 2:43 PM Takashi Yano wrote:
> > > Could you please provide a simple test case?
> >
> > Here you go:
> >
> > // pipes.cpp
> > //
> > // Compile in a Visual Studio x64 Native Tools Command Prompt:
> > // cl pipes.cpp /link /subsystem:windows
> > //
> > // Run from inside a Cygwin shell, the produced pipes.exe
> > //
> >
> > #include
> > #include
> >
> > INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT)
> > {
> > printf("This message used to show up in mintty cygwin v.2.11.2 shell!
> > or from ssh session\n");
> > return 0;
> > }
> > // end of pipes.cpp
>
> Thanks for the test case. Indeed, this works upto cygwin 3.0.7,
> and does not work in cygwin 3.1.0 or later.
>
> However, I wonder what platform is your program for. This test
> case does not work also in native windows command prompt.
> Your test case works only in old cygwin pty.
>
> If you want to make a program which works in cygwin pty, you
> can use cygwin g++ like:
> g++ -mwindows pipes.cpp -o pipes
> The binary built by above command works in cygwin pty, but does
> not work in cygwin console (cygwin in command prompt) even with
> cygwin 3.0.7.
>
> If you want to make a program which works with windows console,
> you should change the code like:
>
> INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT)
> {
> if (!AttachConsole(ATTACH_PARENT_PROCESS)) AllocConsole();
> freopen("CONOUT$", "w", stdout);
> printf("This message used to show up in mintty cygwin v.2.11.2 shell! or
> from ssh session\n");
> return 0;
> }
Or just compile with:
cl pipes.cpp /link /subsystem:console
--
Takashi Yano
--
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: Is Cygwin 3.1.X Stable Enough to Use?
On 2020-02-20 17:20, Takashi Yano wrote: > On Thu, 20 Feb 2020 16:28:26 -0500 > Lee wrote: >> For whatever it's worth, the only problem I've noticed with 3.1.4 was >> ansi control character handling and that was fixed by importing this >> bit into the registry: >> >> - >> Windows Registry Editor Version 5.00 >> >> [HKEY_CURRENT_USER\Console] >> "VirtualTerminalLevel"=dword:0001 >> - > > In what situation is registry modification obove necessary? Enables Console Host Virtual Terminal ANSI Escape Sequence Support; see: https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences https://docs.microsoft.com/en-us/windows/console/setconsolemode https://blogs.msdn.microsoft.com/commandline/2017/06/20/understanding-windows-console-host-settings/ https://devblogs.microsoft.com/commandline/new-experimental-console-features/ https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/ https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ https://github.com/MicrosoftDocs/Console-Docs https://github.com/microsoft/terminal -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Pipes bug when spawning non-cygwin processes
On Fri, 21 Feb 2020 10:07:59 +0900 Takashi Yano wrote: > Or just compile with: > cl pipes.cpp /link /subsystem:console Sorry, you need main() for this. -- Takashi Yano -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On Thu, 20 Feb 2020 18:15:59 -0700 Brian Inglis wrote: > On 2020-02-20 17:20, Takashi Yano wrote: > > On Thu, 20 Feb 2020 16:28:26 -0500 > > Lee wrote: > >> For whatever it's worth, the only problem I've noticed with 3.1.4 was > >> ansi control character handling and that was fixed by importing this > >> bit into the registry: > >> > >> - > >> Windows Registry Editor Version 5.00 > >> > >> [HKEY_CURRENT_USER\Console] > >> "VirtualTerminalLevel"=dword:0001 > >> - > > > > In what situation is registry modification obove necessary? > > Enables Console Host Virtual Terminal ANSI Escape Sequence Support; see: > https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences > https://docs.microsoft.com/en-us/windows/console/setconsolemode > https://blogs.msdn.microsoft.com/commandline/2017/06/20/understanding-windows-console-host-settings/ > https://devblogs.microsoft.com/commandline/new-experimental-console-features/ > https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ > https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ > https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/ > https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ > https://github.com/MicrosoftDocs/Console-Docs > https://github.com/microsoft/terminal I mean what is the problem which need this in cygwin. -- Takashi Yano -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On 2020-02-20 18:27, Takashi Yano wrote: > On Thu, 20 Feb 2020 18:15:59 -0700 > Brian Inglis wrote: >> On 2020-02-20 17:20, Takashi Yano wrote: >>> On Thu, 20 Feb 2020 16:28:26 -0500 >>> Lee wrote: For whatever it's worth, the only problem I've noticed with 3.1.4 was ansi control character handling and that was fixed by importing this bit into the registry: - Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "VirtualTerminalLevel"=dword:0001 - >>> >>> In what situation is registry modification obove necessary? >> >> Enables Console Host Virtual Terminal ANSI Escape Sequence Support; see: >> https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences >> https://docs.microsoft.com/en-us/windows/console/setconsolemode >> https://blogs.msdn.microsoft.com/commandline/2017/06/20/understanding-windows-console-host-settings/ >> https://devblogs.microsoft.com/commandline/new-experimental-console-features/ >> https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ >> https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ >> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ >> https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ >> https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/ >> https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ >> https://github.com/MicrosoftDocs/Console-Docs >> https://github.com/microsoft/terminal > > I mean what is the problem which need this in cygwin. Windows programs which emit (or use?) console ANSI escape sequences run from cmd (which by default switches off Virtual Terminal ANSI Escape Sequence handling for programs run from it) and which do not themselves set that console mode (or can not because they were written for earlier Windows which does not support that flag). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 16:28:26 -0500 > Lee wrote: >> For whatever it's worth, the only problem I've noticed with 3.1.4 was >> ansi control character handling and that was fixed by importing this >> bit into the registry: >> >> - >> Windows Registry Editor Version 5.00 >> >> [HKEY_CURRENT_USER\Console] >> "VirtualTerminalLevel"=dword:0001 >> - > > In what situation is registry modification obove necessary? see http://cygwin.com/ml/cygwin/2020-01/msg00217.html using mintty, started from a desktop shortcut C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico - Lee -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On Thu, 20 Feb 2020 18:34:59 -0700 Brian Inglis wrote: > Windows programs which emit (or use?) console ANSI escape sequences run from > cmd > (which by default switches off Virtual Terminal ANSI Escape Sequence handling > for programs run from it) and which do not themselves set that console mode > (or > can not because they were written for earlier Windows which does not support > that flag). I see. Since it appeared in the context of cygwin stability, I thought it is a cygwin problem. -- Takashi Yano -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Brian Inglis wrote: > On 2020-02-20 18:27, Takashi Yano wrote: >> On Thu, 20 Feb 2020 18:15:59 -0700 >> Brian Inglis wrote: >>> On 2020-02-20 17:20, Takashi Yano wrote: On Thu, 20 Feb 2020 16:28:26 -0500 Lee wrote: > For whatever it's worth, the only problem I've noticed with 3.1.4 was > ansi control character handling and that was fixed by importing this > bit into the registry: > > - > Windows Registry Editor Version 5.00 > > [HKEY_CURRENT_USER\Console] > "VirtualTerminalLevel"=dword:0001 > - In what situation is registry modification obove necessary? >>> >>> Enables Console Host Virtual Terminal ANSI Escape Sequence Support; see: >>> https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences >>> https://docs.microsoft.com/en-us/windows/console/setconsolemode >>> https://blogs.msdn.microsoft.com/commandline/2017/06/20/understanding-windows-console-host-settings/ >>> https://devblogs.microsoft.com/commandline/new-experimental-console-features/ >>> https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ >>> https://github.com/MicrosoftDocs/Console-Docs >>> https://github.com/microsoft/terminal >> >> I mean what is the problem which need this in cygwin. > > Windows programs which emit (or use?) console ANSI escape sequences run from > cmd This was from a mintty console(?) session. There shouldn't have been any windows programs involved. Regards, Lee -- 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
Keywords with high search volume will help your web page
Dear Cygwin, My name is Russell. Everyone wants to achieve better search rankings. Google's search engine uses a variety of methods to determine, which pages are displayed first in the results. If you've been working diligently on your web page optimization but it is not getting the results you want, you may need to consider other factors that will affect your website banner ranking. Our technology is a real help for you. Every time somebody searches your keywords, your website banner will appear on the top portion of search results and no one else can be placed in top position during the whole year. You can see an online demo by going to our website and typing your website cygwin com and your keywords on our online demo box. See you shortly, Russell Munoz -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On Thu, 20 Feb 2020 20:48:17 -0500 Lee wrote: > On 2/20/20, Takashi Yano wrote: > > On Thu, 20 Feb 2020 16:28:26 -0500 > > Lee wrote: > >> For whatever it's worth, the only problem I've noticed with 3.1.4 was > >> ansi control character handling and that was fixed by importing this > >> bit into the registry: > >> > >> - > >> Windows Registry Editor Version 5.00 > >> > >> [HKEY_CURRENT_USER\Console] > >> "VirtualTerminalLevel"=dword:0001 > >> - > > > > In what situation is registry modification obove necessary? > > see http://cygwin.com/ml/cygwin/2020-01/msg00217.html I cannot reproduce that. Without setting VirtualTerminalLevel, I got: [yano@Express5800-S70 ~...build/cmake]$ cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DBUILD_SHARED_LIB:BOOL=YES -DTIDY_RC_NUMBER=next.2020.01.24 -- The C compiler identification is GNU 7.4.0 -- The CXX compiler identification is GNU 7.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++.exe -- Check for working CXX compiler: /usr/bin/c++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- *** Debug Logging is NOT enabled. -- *** Building support for runtime configuration files. -- *** Also building DLL library SHARED, version 5.7.28, date 2019.07.08 -- *** Generating man tidy.1 custom commands... -- Configuring done -- Generating done -- Build files have been written to: /home/yano/tidy/tidy-html5/build/cmake [yano@Express5800-S70 ~...build/cmake]$ make Scanning dependencies of target tidy-share [ 1%] Building C object CMakeFiles/tidy-share.dir/src/access.c.o [ 3%] Building C object CMakeFiles/tidy-share.dir/src/attrs.c.o [ 5%] Building C object CMakeFiles/tidy-share.dir/src/istack.c.o [ 7%] Building C object CMakeFiles/tidy-share.dir/src/parser.c.o [ 8%] Building C object CMakeFiles/tidy-share.dir/src/tags.c.o [ 10%] Building C object CMakeFiles/tidy-share.dir/src/entities.c.o [ 12%] Building C object CMakeFiles/tidy-share.dir/src/lexer.c.o [ 14%] Building C object CMakeFiles/tidy-share.dir/src/pprint.c.o [ 16%] Building C object CMakeFiles/tidy-share.dir/src/charsets.c.o [ 17%] Building C object CMakeFiles/tidy-share.dir/src/clean.c.o [ 19%] Building C object CMakeFiles/tidy-share.dir/src/message.c.o [ 21%] Building C object CMakeFiles/tidy-share.dir/src/config.c.o [ 23%] Building C object CMakeFiles/tidy-share.dir/src/alloc.c.o [ 25%] Building C object CMakeFiles/tidy-share.dir/src/attrdict.c.o [ 26%] Building C object CMakeFiles/tidy-share.dir/src/buffio.c.o [ 28%] Building C object CMakeFiles/tidy-share.dir/src/fileio.c.o [ 30%] Building C object CMakeFiles/tidy-share.dir/src/streamio.c.o [ 32%] Building C object CMakeFiles/tidy-share.dir/src/tagask.c.o [ 33%] Building C object CMakeFiles/tidy-share.dir/src/tmbstr.c.o [ 35%] Building C object CMakeFiles/tidy-share.dir/src/utf8.c.o [ 37%] Building C object CMakeFiles/tidy-share.dir/src/tidylib.c.o [ 39%] Building C object CMakeFiles/tidy-share.dir/src/mappedio.c.o [ 41%] Building C object CMakeFiles/tidy-share.dir/src/gdoc.c.o [ 42%] Building C object CMakeFiles/tidy-share.dir/src/language.c.o [ 44%] Building C object CMakeFiles/tidy-share.dir/src/messageobj.c.o [ 46%] Building C object CMakeFiles/tidy-share.dir/src/sprtf.c.o [ 48%] Linking C shared library cygtidy-5.dll [ 48%] Built target tidy-share Scanning dependencies of target tidy-static [ 50%] Building C object CMakeFiles/tidy-static.dir/src/access.c.o [ 51%] Building C object CMakeFiles/tidy-static.dir/src/attrs.c.o [ 53%] Building C object CMakeFiles/tidy-static.dir/src/istack.c.o [ 55%] Building C object CMakeFiles/tidy-static.dir/src/parser.c.o [ 57%] Building C object CMakeFiles/tidy-static.dir/src/tags.c.o [ 58%] Building C object CMakeFiles/tidy-static.dir/src/entities.c.o [ 60%] Building C object CMakeFiles/tidy-static.dir/src/lexer.c.o [ 62%] Building C object CMakeFiles/tidy-static.dir/src/pprint.c.o [ 64%] Building C object CMakeFiles/tidy-static.dir/src/charsets.c.o [ 66%] Building C object CMakeFiles/tidy-static.dir/src/clean.c.o [ 67%] Building C object CMakeFiles/tidy-static.dir/src/message.c.o [ 69%] Building C object CMakeFiles/tidy-static.dir/src/config.c.o [ 71%] Building C object CMakeFiles/tidy-static.dir/src/alloc.c.o [ 73%] Building C object CMakeFiles/tidy-static.dir/src/attrdict.c.o [ 75%] Building C object CMakeFiles/tidy-static.dir/src/buffio.c.o [ 76%] Building C object CMakeFiles/tidy-static.dir/src/fileio.c.o [ 78%] Building C object CMakeFiles/tidy-static.dir/src/streamio.c.o [ 80%] Building C object CMakeFiles/tidy-static.dir/src/tagask.c.o [ 82%] Building C object CMakeFiles/tidy-static.dir/src/tmbstr.c.o [ 83%]
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 18:34:59 -0700 > Brian Inglis wrote: >> Windows programs which emit (or use?) console ANSI escape sequences run >> from cmd >> (which by default switches off Virtual Terminal ANSI Escape Sequence >> handling >> for programs run from it) and which do not themselves set that console >> mode (or >> can not because they were written for earlier Windows which does not >> support >> that flag). > > I see. Since it appeared in the context of cygwin stability, > I thought it is a cygwin problem. It seems to be a cygwin problem; I've never seen anything like that with cmake before. & like I said earlier, this was from a mintty session started from a desktop shortcut I don't see that problem on my old PC $ uname -a CYGWIN_NT-10.0 i3668 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin Lee -- 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: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 20:48:17 -0500 > Lee wrote: >> On 2/20/20, Takashi Yano wrote: >> > On Thu, 20 Feb 2020 16:28:26 -0500 >> > Lee wrote: >> >> For whatever it's worth, the only problem I've noticed with 3.1.4 was >> >> ansi control character handling and that was fixed by importing this >> >> bit into the registry: >> >> >> >> - >> >> Windows Registry Editor Version 5.00 >> >> >> >> [HKEY_CURRENT_USER\Console] >> >> "VirtualTerminalLevel"=dword:0001 >> >> - >> > >> > In what situation is registry modification obove necessary? >> >> see http://cygwin.com/ml/cygwin/2020-01/msg00217.html > > I cannot reproduce that. Without setting VirtualTerminalLevel, > I got: > [yano@Express5800-S70 ~...build/cmake]$ cmake ../.. > -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local > -DBUILD_SHARED_LIB:BOOL=YES -DTIDY_RC_NUMBER=next.2020.01.24 > -- The C compiler identification is GNU 7.4.0 > -- The CXX compiler identification is GNU 7.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++.exe > -- Check for working CXX compiler: /usr/bin/c++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- *** Debug Logging is NOT enabled. > -- *** Building support for runtime configuration files. > -- *** Also building DLL library SHARED, version 5.7.28, date 2019.07.08 > -- *** Generating man tidy.1 custom commands... > -- Configuring done > -- Generating done > -- Build files have been written to: /home/yano/tidy/tidy-html5/build/cmake > [yano@Express5800-S70 ~...build/cmake]$ make > Scanning dependencies of target tidy-share > [ 1%] Building C object CMakeFiles/tidy-share.dir/src/access.c.o > [ 3%] Building C object CMakeFiles/tidy-share.dir/src/attrs.c.o > [ 5%] Building C object CMakeFiles/tidy-share.dir/src/istack.c.o > [ 7%] Building C object CMakeFiles/tidy-share.dir/src/parser.c.o > [ 8%] Building C object CMakeFiles/tidy-share.dir/src/tags.c.o > [ 10%] Building C object CMakeFiles/tidy-share.dir/src/entities.c.o > [ 12%] Building C object CMakeFiles/tidy-share.dir/src/lexer.c.o > [ 14%] Building C object CMakeFiles/tidy-share.dir/src/pprint.c.o > [ 16%] Building C object CMakeFiles/tidy-share.dir/src/charsets.c.o > [ 17%] Building C object CMakeFiles/tidy-share.dir/src/clean.c.o > [ 19%] Building C object CMakeFiles/tidy-share.dir/src/message.c.o > [ 21%] Building C object CMakeFiles/tidy-share.dir/src/config.c.o > [ 23%] Building C object CMakeFiles/tidy-share.dir/src/alloc.c.o > [ 25%] Building C object CMakeFiles/tidy-share.dir/src/attrdict.c.o > [ 26%] Building C object CMakeFiles/tidy-share.dir/src/buffio.c.o > [ 28%] Building C object CMakeFiles/tidy-share.dir/src/fileio.c.o > [ 30%] Building C object CMakeFiles/tidy-share.dir/src/streamio.c.o > [ 32%] Building C object CMakeFiles/tidy-share.dir/src/tagask.c.o > [ 33%] Building C object CMakeFiles/tidy-share.dir/src/tmbstr.c.o > [ 35%] Building C object CMakeFiles/tidy-share.dir/src/utf8.c.o > [ 37%] Building C object CMakeFiles/tidy-share.dir/src/tidylib.c.o > [ 39%] Building C object CMakeFiles/tidy-share.dir/src/mappedio.c.o > [ 41%] Building C object CMakeFiles/tidy-share.dir/src/gdoc.c.o > [ 42%] Building C object CMakeFiles/tidy-share.dir/src/language.c.o > [ 44%] Building C object CMakeFiles/tidy-share.dir/src/messageobj.c.o > [ 46%] Building C object CMakeFiles/tidy-share.dir/src/sprtf.c.o > [ 48%] Linking C shared library cygtidy-5.dll > [ 48%] Built target tidy-share > Scanning dependencies of target tidy-static > [ 50%] Building C object CMakeFiles/tidy-static.dir/src/access.c.o > [ 51%] Building C object CMakeFiles/tidy-static.dir/src/attrs.c.o > [ 53%] Building C object CMakeFiles/tidy-static.dir/src/istack.c.o > [ 55%] Building C object CMakeFiles/tidy-static.dir/src/parser.c.o > [ 57%] Building C object CMakeFiles/tidy-static.dir/src/tags.c.o > [ 58%] Building C object CMakeFiles/tidy-static.dir/src/entities.c.o > [ 60%] Building C object CMakeFiles/tidy-static.dir/src/lexer.c.o > [ 62%] Building C object CMakeFiles/tidy-static.dir/src/pprint.c.o > [ 64%] Building C object CMakeFiles/tidy-static.dir/src/charsets.c.o > [ 66%] Building C object CMakeFiles/tidy-static.dir/src/clean.c.o > [ 67%] Building C object CMakeFiles/tidy-static.dir/src/message.c.o > [ 69%] Building C object CMakeFiles/tidy-static.dir/src/config.c.o > [ 71%] Building C object CMakeFiles/tidy-static.dir/src/alloc.c.o > [ 73%] Building C object CMakeFiles/tidy-static.dir/src/attrdict.c.o > [ 75%] Building C object CMakeFiles/tidy-static.dir/src/buffio.c.o > [ 76%] Building C object CMakeFiles/tidy-static.dir/src/fileio.c.o > [ 78%] Buil
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Lee wrote: > I'll try backing out the registry change & see if it still happens. It doesn't happen now. I deleted HKEY_CURRENT_USER\Console\VirtualTerminalLevel rebooted deleted all the .o files under /source/tidy & rebuilt The output of cmake looks normal I updated cygwin this morning: 2020/02/20 07:49:28 Augmented Transaction List: 2020/02/20 07:49:280 install cygwin 3.1.4-1 2020/02/20 07:49:281 erase cygwin 3.1.2-1 2020/02/20 07:49:282 install cygwin-devel 3.1.4-1 2020/02/20 07:49:283 erase cygwin-devel 3.1.2-1 is it possible that fixed it? Lee -- 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
