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
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%]
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 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%]
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 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
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, 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 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 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: 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 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: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: 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: 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
[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
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.
RE: updated SSH key
Thanks! I was just sitting here thinking about the merits of verifying a new key request like that by some kind of secure signature system, versus just posting the request on a public mailing list, and having a human acknowledge to the developer's previously known email address. I have to say, I can't see much more security benefit from the first method, that would justify the extra hassle. The second method is pleasantly simple. Andrew E. Schulman Office of Compliance U.S. Environmental Protection Agency 202-564-5244 -Original Message- From: Jon Turney Sent: Thursday, February 20, 2020 4:32 PM To: cygwin-apps@cygwin.com Cc: Schulman, Andrew Subject: Re: updated SSH key On 20/02/2020 19:37, Andrew Schulman via cygwin-apps wrote: > Name: Andrew Schulman Done.
Re: updated SSH key
On 20/02/2020 19:37, Andrew Schulman via cygwin-apps wrote: Name: Andrew Schulman Done.
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
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
updated SSH key
Name: Andrew Schulman Package: screen BEGIN SSH2 PUBLIC KEY E2VjZHNhLXNoYTItbmlzdHAzODQIbmlzdHAzODQAAABhBIh5WtQRqhzLyhiCds BhExlJjXY+NeKxt7tp3l4ViEOwGAPmiMp9keikNzVrpBy2poorumkZDCJrCxx3855UxdnV E51GAO7toxiCMM8BNHX3fnDj6rgydpjCNRStBQUqWQ== END SSH2 PUBLIC KEY
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
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: [PATCH] Cygwin: console: Ignore 0x00 on write().
JFYI:
Both 0x00 (NUL) and 0x7F (DEL) used to be the filler characters, and were
ignored by most (hardware) terminals from the very early days.
HTH,
Anton
> -Original Message-
> From: cygwin-patches-ow...@cygwin.com On
> Behalf Of Takashi Yano
> Sent: Thursday, February 20, 2020 6:52 AM
> To: cygwin-patches@cygwin.com
> Cc: Takashi Yano
> Subject: [PATCH] Cygwin: console: Ignore 0x00 on write().
>
> - In xterm compatible mode, 0x00 on write() behaves incompatible
> with real xterm. In xterm, 0x00 completely ignored. Therefore,
> 0x00 is ignored by console with this patch.
> ---
> winsup/cygwin/fhandler_console.cc | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/winsup/cygwin/fhandler_console.cc
> b/winsup/cygwin/fhandler_console.cc
> index 66e645aa1..705ce696e 100644
> --- a/winsup/cygwin/fhandler_console.cc
> +++ b/winsup/cygwin/fhandler_console.cc
> @@ -1794,6 +1794,16 @@ bool fhandler_console::write_console (PWCHAR buf,
> DWORD len, DWORD& done)
> len -= 4;
> }
> }
> + /* Workaround for ^@ (0x00) handling in xterm compatible mode. */
> + if (wincap.has_con_24bit_colors () && !con_is_legacy)
> +{
> + WCHAR *p = buf;
> + while ((p = wmemchr (p, L'\0', len - (p - buf
> + {
> + memmove (p, p+1, (len - (p+1 - buf))*sizeof (WCHAR));
> + len --;
> + }
> +}
>
>if (con.iso_2022_G1
> ? con.vt100_graphics_mode_G1
> --
> 2.21.0
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Feb 20 17:22, Thomas Wolff wrote: > On 20.02.2020 17:04, Corinna Vinschen wrote: > > On Feb 20 23:49, Takashi Yano wrote: > > > On Thu, 20 Feb 2020 15:22:45 +0100 > > > Corinna Vinschen wrote: > > > > On Feb 20 23:13, Takashi Yano wrote: > > > > > On Thu, 20 Feb 2020 14:44:59 +0100 > > > > > Corinna Vinschen wrote: > > > > > > But, here's a question: Why do we move the cursor to the right at > > > > > > all? > > > > > > I assume this is compatible with legacy mode, right? > > > > > Hmm. This may be a bug of legacy console. > > > > > https://en.wikipedia.org/wiki/Null_character > > > > > says > > > > > (some terminals, however, incorrectly display it as space) > > > > > > > > > > What about ignoring NUL in legacy mode too? > > > > I'd like that, but this may be a problem in terms of backward > > > > compatibility. The behaviour is so old, it actually precedes even the > > > > import of Cygwin code into the original CVS repository, 20 years ago... > > > If so, can't we say it is the *specification* of TERM=cygwin > > > that NUL moves the cursor right? > > Good point. Yes, in that case it's "working as designed" and > > we just leave it as is. I push my patch. > See `man 5 terminfo`: if NUL does anything else than just padding, the > terminfo entry must contain a pad or npc entry, which it doesn't. > Trouble to be expected. I'd rather suggest to align the design with > applications' expectations. Is that the cygwin terminfo or the xterm terminfo you're talking about? In case of the cygwin terminfo, that would mean the cygwin terminal emulation behaves differently from the terminfo for ages. I guess you're right then, we should fix this in the cygwin terminal emulation to make sure it behaves as descibed in its terminfo. In case of the xterm terminfo, that would be no problem because my patch drops the cursor movement for NUL. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On 20.02.2020 17:04, Corinna Vinschen wrote: On Feb 20 23:49, Takashi Yano wrote: On Thu, 20 Feb 2020 15:22:45 +0100 Corinna Vinschen wrote: On Feb 20 23:13, Takashi Yano wrote: On Thu, 20 Feb 2020 14:44:59 +0100 Corinna Vinschen wrote: On Feb 20 14:35, Corinna Vinschen wrote: On Feb 20 20:51, Takashi Yano wrote: - In xterm compatible mode, 0x00 on write() behaves incompatible with real xterm. In xterm, 0x00 completely ignored. Therefore, 0x00 is ignored by console with this patch. --- winsup/cygwin/fhandler_console.cc | 10 ++ 1 file changed, 10 insertions(+) [...] Counter-proposal: diff --git a/winsup/cygwin/fhandler_console.cc b/winsup/cygwin/fhandler_console.cc index 66e645aa1774..1b3aa0f34aa6 100644 --- a/winsup/cygwin/fhandler_console.cc +++ b/winsup/cygwin/fhandler_console.cc [...] Btw., I tested this with write (1, "A\0B\0C\0D", 7); it turned out that this results in broken output even with your patch. The reason is that a NUL byte must not (cannot) be evaluated by dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't handle embedded NUL bytes gracefully. Indeed. Your patch is much better. On Thu, 20 Feb 2020 14:35:31 +0100 Corinna Vinschen wrote: But, here's a question: Why do we move the cursor to the right at all? I assume this is compatible with legacy mode, right? Hmm. This may be a bug of legacy console. https://en.wikipedia.org/wiki/Null_character says (some terminals, however, incorrectly display it as space) What about ignoring NUL in legacy mode too? I'd like that, but this may be a problem in terms of backward compatibility. The behaviour is so old, it actually precedes even the import of Cygwin code into the original CVS repository, 20 years ago... If so, can't we say it is the *specification* of TERM=cygwin that NUL moves the cursor right? Good point. Yes, in that case it's "working as designed" and we just leave it as is. I push my patch. See `man 5 terminfo`: if NUL does anything else than just padding, the terminfo entry must contain a pad or npc entry, which it doesn't. Trouble to be expected. I'd rather suggest to align the design with applications' expectations.
[newlib-cygwin] Cygwin: console: ignore NUL byte on write in xterm emulation mode as well
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=c9f153580bfb4db4f9ef023b99360d7a746bd450
commit c9f153580bfb4db4f9ef023b99360d7a746bd450
Author: Corinna Vinschen
Date: Thu Feb 20 14:48:03 2020 +0100
Cygwin: console: ignore NUL byte on write in xterm emulation mode as well
A NUL byte in the output stream got accidentally not handled as IGN char
in xterm console mode. The internal mbtowc conversion doesn't handle
embedded NUL values gracefully, it always stops converting at NUL bytes.
This broke the output of strings with embedded NUL bytes.
Fix this by always skipping IGN chars in the "normal char output loop"
and make sure not to move the cursor one position to the right, as in
legacy console mode.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/fhandler_console.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 66e645a..c062fd7 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -2641,6 +2641,7 @@ fhandler_console::write_normal (const unsigned char *src,
memset (, 0, sizeof ps);
while (found < end
&& found - src < CONVERT_LIMIT
+&& base_chars[*found] != IGN
&& ((wincap.has_con_24bit_colors () && !con_is_legacy)
|| base_chars[*found] == NOR) )
{
@@ -2732,7 +2733,8 @@ do_print:
cursor_rel (-1, 0);
break;
case IGN:
- cursor_rel (1, 0);
+if (!wincap.has_con_24bit_colors () || con_is_legacy)
+ cursor_rel (1, 0);
break;
case CR:
cursor_get (, );
[newlib-cygwin] Cygwin: fhandler_console.cc: fix minor style issues
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=4ec2e5e1c2d9bfdb742386a43a9d27aec4d74523
commit 4ec2e5e1c2d9bfdb742386a43a9d27aec4d74523
Author: Corinna Vinschen
Date: Thu Feb 20 14:57:26 2020 +0100
Cygwin: fhandler_console.cc: fix minor style issues
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/fhandler_console.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index c062fd7..f7044c8 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -1774,8 +1774,8 @@ static const wchar_t __vt100_conv[31] = {
0x00B7, /* Middle Dot */
};
-inline
-bool fhandler_console::write_console (PWCHAR buf, DWORD len, DWORD& done)
+inline bool
+fhandler_console::write_console (PWCHAR buf, DWORD len, DWORD& done)
{
bool need_fix_tab_position = false;
/* Check if screen will be alternated. */
@@ -2643,7 +2643,7 @@ fhandler_console::write_normal (const unsigned char *src,
&& found - src < CONVERT_LIMIT
&& base_chars[*found] != IGN
&& ((wincap.has_con_24bit_colors () && !con_is_legacy)
-|| base_chars[*found] == NOR) )
+|| base_chars[*found] == NOR))
{
switch (ret = f_mbtowc (_REENT, NULL, (const char *) found,
end - found, ))
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Feb 20 23:49, Takashi Yano wrote: > On Thu, 20 Feb 2020 15:22:45 +0100 > Corinna Vinschen wrote: > > On Feb 20 23:13, Takashi Yano wrote: > > > On Thu, 20 Feb 2020 14:44:59 +0100 > > > Corinna Vinschen wrote: > > > > On Feb 20 14:35, Corinna Vinschen wrote: > > > > > On Feb 20 20:51, Takashi Yano wrote: > > > > > > - In xterm compatible mode, 0x00 on write() behaves incompatible > > > > > > with real xterm. In xterm, 0x00 completely ignored. Therefore, > > > > > > 0x00 is ignored by console with this patch. > > > > > > --- > > > > > > winsup/cygwin/fhandler_console.cc | 10 ++ > > > > > > 1 file changed, 10 insertions(+) > > > > > > [...] > > > > > > > > > > Counter-proposal: > > > > > > > > > > diff --git a/winsup/cygwin/fhandler_console.cc > > > > > b/winsup/cygwin/fhandler_console.cc > > > > > index 66e645aa1774..1b3aa0f34aa6 100644 > > > > > --- a/winsup/cygwin/fhandler_console.cc > > > > > +++ b/winsup/cygwin/fhandler_console.cc > > > > > [...] > > > > > > > > Btw., I tested this with > > > > > > > > write (1, "A\0B\0C\0D", 7); > > > > > > > > it turned out that this results in broken output even with your patch. > > > > The reason is that a NUL byte must not (cannot) be evaluated by > > > > dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't > > > > handle embedded NUL bytes gracefully. > > > > > > Indeed. Your patch is much better. > > > > > > On Thu, 20 Feb 2020 14:35:31 +0100 > > > Corinna Vinschen wrote: > > > > But, here's a question: Why do we move the cursor to the right at all? > > > > I assume this is compatible with legacy mode, right? > > > > > > Hmm. This may be a bug of legacy console. > > > https://en.wikipedia.org/wiki/Null_character > > > says > > > (some terminals, however, incorrectly display it as space) > > > > > > What about ignoring NUL in legacy mode too? > > > > I'd like that, but this may be a problem in terms of backward > > compatibility. The behaviour is so old, it actually precedes even the > > import of Cygwin code into the original CVS repository, 20 years ago... > > If so, can't we say it is the *specification* of TERM=cygwin > that NUL moves the cursor right? Good point. Yes, in that case it's "working as designed" and we just leave it as is. I push my patch. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [Attn. Maintainers] perl-5.30.1 -- prepare for release
On 19/02/2020 23:41, Alexey Sokolov wrote: 19.02.2020 17:44, Jon Turney пишет: On 18/02/2020 19:53, Marco Atzeri wrote: Am 16.02.2020 um 16:30 schrieb Jon Turney: On 16/02/2020 08:08, Marco Atzeri wrote: Am 16.02.2020 um 07:55 schrieb ASSI: Marco Atzeri writes: Perhaps I should just extend the list of special users who are allowed to upload orphaned packages to include all uploaders who also have a sourceware shell account. (since they can upload anything by just moving it directly into the relarea, anyhow) let me know if you implement it, I see a bit too many potentially broken packages by the Perl update I have made an update to calm which should extend the list of people who can upload any orphan package to include everyone who currently: * has a sourceware shell account * that account is a member of the cygwin group * is currently a package maintainer That list of people is: Corinna Vinschen Eric Blake Jon Turney Ken Brown Marco Atzeri Yaakov Selkowitz Is this list maintained manually (hardcoded), or automatically by calm based on the criteria you described above? Unfortunately, I had to generate this list manually (There's not really a programmatic way to map between a Cygwin uploader name (as it appears in cygwin-pkg-maint) and a sourceware account name). I used those criteria as it seemed a reasonable way to identify people who already have necessary access and possible interest in making those uploads. I'm not suggesting that we should use those criteria in future. If someone has something useful they could do, requiring that kind of access, they should ask for it (although I think it would be better to actually adopt packages, or reach a consensus that they should be removed).
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Thu, 20 Feb 2020 15:22:45 +0100 Corinna Vinschen wrote: > On Feb 20 23:13, Takashi Yano wrote: > > On Thu, 20 Feb 2020 14:44:59 +0100 > > Corinna Vinschen wrote: > > > On Feb 20 14:35, Corinna Vinschen wrote: > > > > On Feb 20 20:51, Takashi Yano wrote: > > > > > - In xterm compatible mode, 0x00 on write() behaves incompatible > > > > > with real xterm. In xterm, 0x00 completely ignored. Therefore, > > > > > 0x00 is ignored by console with this patch. > > > > > --- > > > > > winsup/cygwin/fhandler_console.cc | 10 ++ > > > > > 1 file changed, 10 insertions(+) > > > > > [...] > > > > > > > > Counter-proposal: > > > > > > > > diff --git a/winsup/cygwin/fhandler_console.cc > > > > b/winsup/cygwin/fhandler_console.cc > > > > index 66e645aa1774..1b3aa0f34aa6 100644 > > > > --- a/winsup/cygwin/fhandler_console.cc > > > > +++ b/winsup/cygwin/fhandler_console.cc > > > > [...] > > > > > > Btw., I tested this with > > > > > > write (1, "A\0B\0C\0D", 7); > > > > > > it turned out that this results in broken output even with your patch. > > > The reason is that a NUL byte must not (cannot) be evaluated by > > > dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't > > > handle embedded NUL bytes gracefully. > > > > Indeed. Your patch is much better. > > > > On Thu, 20 Feb 2020 14:35:31 +0100 > > Corinna Vinschen wrote: > > > But, here's a question: Why do we move the cursor to the right at all? > > > I assume this is compatible with legacy mode, right? > > > > Hmm. This may be a bug of legacy console. > > https://en.wikipedia.org/wiki/Null_character > > says > > (some terminals, however, incorrectly display it as space) > > > > What about ignoring NUL in legacy mode too? > > I'd like that, but this may be a problem in terms of backward > compatibility. The behaviour is so old, it actually precedes even the > import of Cygwin code into the original CVS repository, 20 years ago... If so, can't we say it is the *specification* of TERM=cygwin that NUL moves the cursor right? -- Takashi Yano
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: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Feb 20 23:13, Takashi Yano wrote: > On Thu, 20 Feb 2020 14:44:59 +0100 > Corinna Vinschen wrote: > > On Feb 20 14:35, Corinna Vinschen wrote: > > > On Feb 20 20:51, Takashi Yano wrote: > > > > - In xterm compatible mode, 0x00 on write() behaves incompatible > > > > with real xterm. In xterm, 0x00 completely ignored. Therefore, > > > > 0x00 is ignored by console with this patch. > > > > --- > > > > winsup/cygwin/fhandler_console.cc | 10 ++ > > > > 1 file changed, 10 insertions(+) > > > > [...] > > > > > > Counter-proposal: > > > > > > diff --git a/winsup/cygwin/fhandler_console.cc > > > b/winsup/cygwin/fhandler_console.cc > > > index 66e645aa1774..1b3aa0f34aa6 100644 > > > --- a/winsup/cygwin/fhandler_console.cc > > > +++ b/winsup/cygwin/fhandler_console.cc > > > [...] > > > > Btw., I tested this with > > > > write (1, "A\0B\0C\0D", 7); > > > > it turned out that this results in broken output even with your patch. > > The reason is that a NUL byte must not (cannot) be evaluated by > > dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't > > handle embedded NUL bytes gracefully. > > Indeed. Your patch is much better. > > On Thu, 20 Feb 2020 14:35:31 +0100 > Corinna Vinschen wrote: > > But, here's a question: Why do we move the cursor to the right at all? > > I assume this is compatible with legacy mode, right? > > Hmm. This may be a bug of legacy console. > https://en.wikipedia.org/wiki/Null_character > says > (some terminals, however, incorrectly display it as space) > > What about ignoring NUL in legacy mode too? I'd like that, but this may be a problem in terms of backward compatibility. The behaviour is so old, it actually precedes even the import of Cygwin code into the original CVS repository, 20 years ago... Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Thu, 20 Feb 2020 14:44:59 +0100 Corinna Vinschen wrote: > On Feb 20 14:35, Corinna Vinschen wrote: > > On Feb 20 20:51, Takashi Yano wrote: > > > - In xterm compatible mode, 0x00 on write() behaves incompatible > > > with real xterm. In xterm, 0x00 completely ignored. Therefore, > > > 0x00 is ignored by console with this patch. > > > --- > > > winsup/cygwin/fhandler_console.cc | 10 ++ > > > 1 file changed, 10 insertions(+) > > > [...] > > > > Counter-proposal: > > > > diff --git a/winsup/cygwin/fhandler_console.cc > > b/winsup/cygwin/fhandler_console.cc > > index 66e645aa1774..1b3aa0f34aa6 100644 > > --- a/winsup/cygwin/fhandler_console.cc > > +++ b/winsup/cygwin/fhandler_console.cc > > [...] > > Btw., I tested this with > > write (1, "A\0B\0C\0D", 7); > > it turned out that this results in broken output even with your patch. > The reason is that a NUL byte must not (cannot) be evaluated by > dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't > handle embedded NUL bytes gracefully. Indeed. Your patch is much better. On Thu, 20 Feb 2020 14:35:31 +0100 Corinna Vinschen wrote: > But, here's a question: Why do we move the cursor to the right at all? > I assume this is compatible with legacy mode, right? Hmm. This may be a bug of legacy console. https://en.wikipedia.org/wiki/Null_character says (some terminals, however, incorrectly display it as space) What about ignoring NUL in legacy mode too? -- Takashi Yano
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: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Feb 20 14:35, Corinna Vinschen wrote: > On Feb 20 20:51, Takashi Yano wrote: > > - In xterm compatible mode, 0x00 on write() behaves incompatible > > with real xterm. In xterm, 0x00 completely ignored. Therefore, > > 0x00 is ignored by console with this patch. > > --- > > winsup/cygwin/fhandler_console.cc | 10 ++ > > 1 file changed, 10 insertions(+) > > [...] > > Counter-proposal: > > diff --git a/winsup/cygwin/fhandler_console.cc > b/winsup/cygwin/fhandler_console.cc > index 66e645aa1774..1b3aa0f34aa6 100644 > --- a/winsup/cygwin/fhandler_console.cc > +++ b/winsup/cygwin/fhandler_console.cc > [...] Btw., I tested this with write (1, "A\0B\0C\0D", 7); it turned out that this results in broken output even with your patch. The reason is that a NUL byte must not (cannot) be evaluated by dev_console::str_to_con() -> sys_cp_mbstowcs(). The latter doesn't handle embedded NUL bytes gracefully. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: console: Ignore 0x00 on write().
On Feb 20 20:51, Takashi Yano wrote:
> - In xterm compatible mode, 0x00 on write() behaves incompatible
> with real xterm. In xterm, 0x00 completely ignored. Therefore,
> 0x00 is ignored by console with this patch.
> ---
> winsup/cygwin/fhandler_console.cc | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/winsup/cygwin/fhandler_console.cc
> b/winsup/cygwin/fhandler_console.cc
> index 66e645aa1..705ce696e 100644
> --- a/winsup/cygwin/fhandler_console.cc
> +++ b/winsup/cygwin/fhandler_console.cc
> @@ -1794,6 +1794,16 @@ bool fhandler_console::write_console (PWCHAR buf,
> DWORD len, DWORD& done)
> len -= 4;
> }
> }
> + /* Workaround for ^@ (0x00) handling in xterm compatible mode. */
> + if (wincap.has_con_24bit_colors () && !con_is_legacy)
> +{
> + WCHAR *p = buf;
> + while ((p = wmemchr (p, L'\0', len - (p - buf
> + {
> + memmove (p, p+1, (len - (p+1 - buf))*sizeof (WCHAR));
> + len --;
> + }
> +}
>
>if (con.iso_2022_G1
> ? con.vt100_graphics_mode_G1
> --
> 2.21.0
Counter-proposal:
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 66e645aa1774..1b3aa0f34aa6 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -2641,8 +2641,9 @@ fhandler_console::write_normal (const unsigned char *src,
memset (, 0, sizeof ps);
while (found < end
&& found - src < CONVERT_LIMIT
+&& base_chars[*found] != IGN
&& ((wincap.has_con_24bit_colors () && !con_is_legacy)
-|| base_chars[*found] == NOR) )
+|| base_chars[*found] == NOR))
{
switch (ret = f_mbtowc (_REENT, NULL, (const char *) found,
end - found, ))
@@ -2732,7 +2733,8 @@ do_print:
cursor_rel (-1, 0);
break;
case IGN:
- cursor_rel (1, 0);
+if (!wincap.has_con_24bit_colors () || con_is_legacy)
+ cursor_rel (1, 0);
break;
case CR:
cursor_get (, );
But, here's a question: Why do we move the cursor to the right at all?
I assume this is compatible with legacy mode, right?
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
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
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
[PATCH] Cygwin: console: Ignore 0x00 on write().
- In xterm compatible mode, 0x00 on write() behaves incompatible
with real xterm. In xterm, 0x00 completely ignored. Therefore,
0x00 is ignored by console with this patch.
---
winsup/cygwin/fhandler_console.cc | 10 ++
1 file changed, 10 insertions(+)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 66e645aa1..705ce696e 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -1794,6 +1794,16 @@ bool fhandler_console::write_console (PWCHAR buf, DWORD
len, DWORD& done)
len -= 4;
}
}
+ /* Workaround for ^@ (0x00) handling in xterm compatible mode. */
+ if (wincap.has_con_24bit_colors () && !con_is_legacy)
+{
+ WCHAR *p = buf;
+ while ((p = wmemchr (p, L'\0', len - (p - buf
+ {
+ memmove (p, p+1, (len - (p+1 - buf))*sizeof (WCHAR));
+ len --;
+ }
+}
if (con.iso_2022_G1
? con.vt100_graphics_mode_G1
--
2.21.0
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?
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
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?
> > 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 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: 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
