Re: Failed assertion dialog box ATTN: Takashi Yano
Am 20.11.2020 um 03:04 schrieb Duncan Roe: On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote: Hi all, On Fri, 20 Nov 2020 11:06:58 +1100 Duncan Roe wrote: On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: It does not seem to happen in xterm which is weird. It happens in an xterm for me. xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. So I think it has to be pseudo-console. (xterm has DISPLAY set to a Linux system but that shouldn't matter should it?) Could you please try latest cygwin snapshot? -- Takashi Yano Tried 20200909 - no popup Still interesting, though, is this observation: the message text in the popup is different from the text if it appears in the terminal, suggesting that cygwin function __assert_func (from winsup/cygwin/assert.cc) is somehow injected into the gcc runtime in the popup cases only, which raises the technical questions how it could be injected at all and why only in some cases. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote: > Hi all, > > On Fri, 20 Nov 2020 11:06:58 +1100 > Duncan Roe wrote: > > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > > > > > It does not seem to happen in xterm which is weird. > > > > It happens in an xterm for me. > > xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. > > So I think it has to be pseudo-console. > > (xterm has DISPLAY set to a Linux system but that shouldn't matter should > > it?) > > Could you please try latest cygwin snapshot? > > -- > Takashi Yano Tried 20200909 - no popup Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Fri, Nov 20, 2020 at 09:19:29AM +0900, cygwin wrote: > Hi all, > > On Fri, 20 Nov 2020 11:06:58 +1100 > Duncan Roe wrote: > > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > > > > > It does not seem to happen in xterm which is weird. > > > > It happens in an xterm for me. > > xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. > > So I think it has to be pseudo-console. > > (xterm has DISPLAY set to a Linux system but that shouldn't matter should > > it?) > > Could you please try latest cygwin snapshot? > > -- > Takashi Yano Never done that before. How do I get it? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
Hi all, On Fri, 20 Nov 2020 11:06:58 +1100 Duncan Roe wrote: > On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > > > It does not seem to happen in xterm which is weird. > > It happens in an xterm for me. > xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. > So I think it has to be pseudo-console. > (xterm has DISPLAY set to a Linux system but that shouldn't matter should it?) Could you please try latest cygwin snapshot? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
On Thu, Nov 19, 2020 at 07:30:20PM +0100, Thomas Wolff wrote: > > It does not seem to happen in xterm which is weird. It happens in an xterm for me. xterm is /dev/pty1 and mintty is /dev/pty0. They both do it. So I think it has to be pseudo-console. (xterm has DISPLAY set to a Linux system but that shouldn't matter should it?) > It does however also happen in rxvt-unicode, xfce4-terminal, and vte. > The message text of the popup can be easily found in cygwin code. > Thomas Cheers ... Duncan. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cmake-3.19.0-1 and related packages
Hi! Marco and Tony, cmake 3.19.0 has been released in the upstream. https://blog.kitware.com/cmake-3-19-0-available-for-download/ A new candidate cmake.cygport has been uploaded https://github.com/cygwin-lem/cygwin-pkg/blob/cmake_3.19.0-1/cmake/cmake.cygport , and pull-requested as https://github.com/matzeri/cygwin-pkg/pull/2 Former patches have been merged into upstream 3.19. Use default src_install(), still cmake-mode.el will be properly installed. Add new packages: bash-completion-cmake and vim-cmake. Add BUILD_REQUIRES list, but it might be insufficient. Generated packages except debuginfo have been uploaded to https://app.box.com/s/8q5mpv4kv080jxsyc5tbongrerwfzbuz Regards, Lem
Re: Failed assertion dialog box ATTN: Takashi Yano
De : Cygwin de la part de Thomas Wolff
Envoyé : 19 novembre 2020 13:30
À : cygwin@cygwin.com
Objet : Re: Failed assertion dialog box ATTN: Takashi Yano
---
Am 19.11.2020 um 15:21 schrieb André Bleau via Cygwin:
> ...
> Here's some more info:
>
> It seems the bug is related to pseudo-console support; that explains why it
> is Windows 10 specific.
>
> Experiment:
>
> CYGWIN=disable_pcon /usr/bin/mintty &
>
> In the newly created window:
>
> $ ./a.exe output.txt 2>&1
> Aborted (core dumped)
>
> No message box popup.
>
> $ cat output.txt
> assertion "false" failed: file "assert.cpp", line 3, function: int main()
>
> In the original mintty window, with empty CYGWIN env variable:
>
> $ ./a.exe output.txt 2>&1
> Aborted (core dumped)
>
> A message box pops
>
> AND:
>
> $ cat output.txt
>
> output.txt is empty
>
> So, 2 problems here.
>
> In a CMD Window:
>
> set path=%PATH%D:\Cygwin\bin;
> a.exe outcmd.txt 2>&1
> 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack
>trace to a.exe.stackdump
>
> type outcmd.txt
> assertion "false" failed: file "assert.cpp", line 3, function: int main()
> 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack
>trace to a.exe.stackdump
>
> The bug could be in cygwin or in mintty. Maybe this is something that Thomas
> Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would
> want to look at.
> ---
>
> OK, I opened an issue for mintty and it was quickly closed with that quote:
>
> "Quick generic answer: if it's caused by ConPTY support, it's not related to
> mintty; also mintty never shows any popups.
> Funny thing, though, but really: assert isn't handled by the terminal."
>
> So the issue can only be with pseudo-console support in cygwin.
It does not seem to happen in xterm which is weird.
It does however also happen in rxvt-unicode, xfce4-terminal, and vte.
The message text of the popup can be easily found in cygwin code.
Thomas
---
One more data point:
The following program:
$ cat stderr.c
#include
int main() {
fprintf(stdout, "To stdout\n");
fprintf(stderr, "To stderr\n");
return 0;
}
$ gcc stderr.c
$ ./a.exe output.txt 2>&1
Behaves normally, with either empty CYGWIN env variable or with
$ CYGWIN=disable_pcon /usr/bin/mintty &
So the problem is narrowly confined to how Cygwin handles assert when
pseudo-console is used and stdin, stdout, and stderr are redirected. Not in all
cases where pseudo-console is used and stdin, stdout, and stderr are
redirected.
- André Bleau
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: fhandler_fifo::cleanup_handlers: improve efficiency
Traverse the fifo_client_handler list from the top down to try to
avoid copying.
---
winsup/cygwin/fhandler_fifo.cc | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index eff05d242..8b67037cb 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -395,15 +395,10 @@ fhandler_fifo::delete_client_handler (int i)
void
fhandler_fifo::cleanup_handlers ()
{
- int i = 0;
-
- while (i < nhandlers)
-{
- if (fc_handler[i].get_state () < fc_connected)
- delete_client_handler (i);
- else
- i++;
-}
+ /* Work from the top down to try to avoid copying. */
+ for (int i = nhandlers - 1; i >= 0; --i)
+if (fc_handler[i].get_state () < fc_connected)
+ delete_client_handler (i);
}
/* Always called with fifo_client_lock in place. */
--
2.29.2
[ANNOUNCEMENT] Updated: wget 1.20.3-2
The following packages have been upgraded in the Cygwin distribution:
* wget 1.20.3-2
This release cleans up inconsistencies between x86 and x86_64 build outputs.
This will be the last release of wget, unless high priority security patches
are required. Future development will be against the successor project wget2.
GNU Wget is a file retrieval utility which can use the HTTP, HTTPS, or
FTP protocols. Wget features include the ability to work in the
background while you're logged out, recursive retrieval of directories,
file name wildcard matching, remote file timestamp storage and
comparison, use of Rest with FTP servers and Range with HTTP servers to
retrieve files over slow or unstable connections, support for Proxy
servers, and configurability.
For more information, please see the project home page.
https://www.gnu.org/software/wget/
Summary of changes since last release wget 1.19.1:
* clean up inconsistencies between x86 and x86_64 builds
* fix CVE-2018-0494, CVE-2017-13089, CVE-2017-13090
* fix multiple potential resource leaks, memory leaks, buffer and
integer overflows and segfaults
* fix --xattr issues
* support TLSv1.3 ciphers, libpcre2 regex pattern matching, HTTP 308
Permanent Redirect response
* improve IDNA 2003 compatibility
* NTLM authentication retry certain cases
* add new options --ciphers, --compression, --retry-on-host-error, add
--[no]-netrc to control .netrc parsing including GNU extensions, and
fix Windows .netrc detection
* decompress GZip'ed pages, and prevent erroneous decompression with
broken servers
* do not create an empty wget-log file when running with -q and -b
For more details see /usr/share/doc/wget/NEWS or below:
* Changes in Wget 1.20.3
-- Fixed a buffer overflow vulnerability
* Changes in Wget 1.20.2
-- NTLM authentication will retry under certain cases
* Changes in Wget 1.20.1
-- --xattr is no longer default since it introduces privacy issues.
-- --xattr saves the Referer as scheme/host/port, user/pw/path/query/fragment
are no longer saved to prevent privacy issues.
-- --xattr saves the Original URL without user/password to prevent
privacy issues.
* Changes in Wget 1.20
-- Add new option `--retry-on-host-error` to treat local errors as transient
and hence Wget will retry to download the file after a brief waiting period.
-- Fixed multiple potential resource leaks as found by static analysis
-- Wget will now not create an empty wget-log file when running with -q and -b
switches together
-- When compiled using the GnuTLS >= 3.6.3, Wget now has support for TLSv1.3
-- Now there is support for using libpcre2 for regex pattern matching
-- When downloading over FTP recursively, one can now use the
--{accept,reject}-regex switches to fine-tune the downloaded files
-- Building Wget from the git sources now requires autoconf 2.63 or above.
Building from the Tarballs works as it used to.
* Changes in Wget 1.19.5
-- Fix cookie injection (CVE-2018-0494)
-- Enable TLS1.3 with recent OpenSSL environment
-- New option --ciphers to set GnuTLS / OpenSSL ciphers directly
-- Updated CSS grammar to CSS 2.2
-- Fixed several memleaks found by OSS-Fuzz
-- Fixed several buffer overflows found by OSS-Fuzz
-- Fixed several integer overflows found by OSS-Fuzz
-- Several minor bug fixes
* Changes in Wget 1.19.4
-- A major bug that caused GZip'ed pages to never be decompressed has been
fixed
-- Support for Content-Encoding and Transfer-Encoding have been marked as
experimental and disabled by default
* Changes in Wget 1.19.3
-- Prevent erroneous decompression of .gz and .tgz files with broken servers
-- Added support for HTTP 308 Permanent Redirect response
-- Fix a segfault in some cases where the Content-Type header is not sent
-- Support OpenSSL 1.1 builds without using deprecated features
-- Fix netrc file detection on Windows
-- Several minor bug fixes
* Changes in Wget 1.19.2
-- Fix CVE-2017-13089 (Stack overflow in HTTP protocol handling)
-- Fix CVE-2017-13090 (Heap overflow in HTTP protocol handling)
-- New option --compression for gzip Content-Encoding
-- New option --[no]-netrc to control .netrc parsing
-- Added GNU extensions to .netrc parsing
-- Improved IDNA 2003 compatibility
-- Fix VPATH issues
-- Improved and extended the test suite
-- Support Wayback Machine's X-Archive-Orig-last-modified
-- Several bug fixes
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: wget 1.20.3-2
The following packages have been upgraded in the Cygwin distribution:
* wget 1.20.3-2
This release cleans up inconsistencies between x86 and x86_64 build outputs.
This will be the last release of wget, unless high priority security patches
are required. Future development will be against the successor project wget2.
GNU Wget is a file retrieval utility which can use the HTTP, HTTPS, or
FTP protocols. Wget features include the ability to work in the
background while you're logged out, recursive retrieval of directories,
file name wildcard matching, remote file timestamp storage and
comparison, use of Rest with FTP servers and Range with HTTP servers to
retrieve files over slow or unstable connections, support for Proxy
servers, and configurability.
For more information, please see the project home page.
https://www.gnu.org/software/wget/
Summary of changes since last release wget 1.19.1:
* clean up inconsistencies between x86 and x86_64 builds
* fix CVE-2018-0494, CVE-2017-13089, CVE-2017-13090
* fix multiple potential resource leaks, memory leaks, buffer and
integer overflows and segfaults
* fix --xattr issues
* support TLSv1.3 ciphers, libpcre2 regex pattern matching, HTTP 308
Permanent Redirect response
* improve IDNA 2003 compatibility
* NTLM authentication retry certain cases
* add new options --ciphers, --compression, --retry-on-host-error, add
--[no]-netrc to control .netrc parsing including GNU extensions, and
fix Windows .netrc detection
* decompress GZip'ed pages, and prevent erroneous decompression with
broken servers
* do not create an empty wget-log file when running with -q and -b
For more details see /usr/share/doc/wget/NEWS or below:
* Changes in Wget 1.20.3
-- Fixed a buffer overflow vulnerability
* Changes in Wget 1.20.2
-- NTLM authentication will retry under certain cases
* Changes in Wget 1.20.1
-- --xattr is no longer default since it introduces privacy issues.
-- --xattr saves the Referer as scheme/host/port, user/pw/path/query/fragment
are no longer saved to prevent privacy issues.
-- --xattr saves the Original URL without user/password to prevent
privacy issues.
* Changes in Wget 1.20
-- Add new option `--retry-on-host-error` to treat local errors as transient
and hence Wget will retry to download the file after a brief waiting period.
-- Fixed multiple potential resource leaks as found by static analysis
-- Wget will now not create an empty wget-log file when running with -q and -b
switches together
-- When compiled using the GnuTLS >= 3.6.3, Wget now has support for TLSv1.3
-- Now there is support for using libpcre2 for regex pattern matching
-- When downloading over FTP recursively, one can now use the
--{accept,reject}-regex switches to fine-tune the downloaded files
-- Building Wget from the git sources now requires autoconf 2.63 or above.
Building from the Tarballs works as it used to.
* Changes in Wget 1.19.5
-- Fix cookie injection (CVE-2018-0494)
-- Enable TLS1.3 with recent OpenSSL environment
-- New option --ciphers to set GnuTLS / OpenSSL ciphers directly
-- Updated CSS grammar to CSS 2.2
-- Fixed several memleaks found by OSS-Fuzz
-- Fixed several buffer overflows found by OSS-Fuzz
-- Fixed several integer overflows found by OSS-Fuzz
-- Several minor bug fixes
* Changes in Wget 1.19.4
-- A major bug that caused GZip'ed pages to never be decompressed has been
fixed
-- Support for Content-Encoding and Transfer-Encoding have been marked as
experimental and disabled by default
* Changes in Wget 1.19.3
-- Prevent erroneous decompression of .gz and .tgz files with broken servers
-- Added support for HTTP 308 Permanent Redirect response
-- Fix a segfault in some cases where the Content-Type header is not sent
-- Support OpenSSL 1.1 builds without using deprecated features
-- Fix netrc file detection on Windows
-- Several minor bug fixes
* Changes in Wget 1.19.2
-- Fix CVE-2017-13089 (Stack overflow in HTTP protocol handling)
-- Fix CVE-2017-13090 (Heap overflow in HTTP protocol handling)
-- New option --compression for gzip Content-Encoding
-- New option --[no]-netrc to control .netrc parsing
-- Added GNU extensions to .netrc parsing
-- Improved IDNA 2003 compatibility
-- Fix VPATH issues
-- Improved and extended the test suite
-- Support Wayback Machine's X-Archive-Orig-last-modified
-- Several bug fixes
Re: Failed assertion dialog box ATTN: Takashi Yano
Am 19.11.2020 um 15:21 schrieb André Bleau via Cygwin: ... Here's some more info: It seems the bug is related to pseudo-console support; that explains why it is Windows 10 specific. Experiment: CYGWIN=disable_pcon /usr/bin/mintty & In the newly created window: $ ./a.exe output.txt 2>&1 Aborted (core dumped) No message box popup. $ cat output.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() In the original mintty window, with empty CYGWIN env variable: $ ./a.exe output.txt 2>&1 Aborted (core dumped) A message box pops AND: $ cat output.txt output.txt is empty So, 2 problems here. In a CMD Window: set path=%PATH%D:\Cygwin\bin; a.exe outcmd.txt 2>&1 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump type outcmd.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump The bug could be in cygwin or in mintty. Maybe this is something that Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would want to look at. --- OK, I opened an issue for mintty and it was quickly closed with that quote: "Quick generic answer: if it's caused by ConPTY support, it's not related to mintty; also mintty never shows any popups. Funny thing, though, but really: assert isn't handled by the terminal." So the issue can only be with pseudo-console support in cygwin. It does not seem to happen in xterm which is weird. It does however also happen in rxvt-unicode, xfce4-terminal, and vte. The message text of the popup can be easily found in cygwin code. Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ssh-copy-id probem on 3.1.7(0.340/5/3)
On 2020-11-12 20:24:59, Bruno Iglesias wrote: Hi, When i try to copy a ssh key with ssh-copy-id receive this error and not copy de key: ssh-copy-id biglesias@pve1 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/bruno/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys /usr/bin/ssh-copy-id: línea 251: aviso: el documento-aquí en la línea 251 está delimitado por fin-de-fichero (se esperaba `EOF') /usr/bin/ssh-copy-id: línea 250: aviso: el documento-aquí en la línea 250 está delimitado por fin-de-fichero (se esperaba `EOF') /usr/bin/ssh-copy-id: línea 260: EOF: no se encontró la orden biglesias@pve1's password: Number of key(s) added: 1 The result of ssh -V is OpenSSH_8.4p1, OpenSSL 1.1.1f 31 Mar 2020 The same error is reported in redhat list: https://bugzilla.redhat.com/show_bug.cgi?id=1884231 and Clear Linux Project: https://github.com/clearlinux/distribution/issues/2166 I also have this problem. I noticed that it resulted in an authorized_keys file being installed in my *local* ~/.ssh/ directory instead of on the remote system. I worked around it by installing a copy of the old ssh-copy-id script in my personal bin directory. -- -Chad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Virtual Windows folders - make them visible?
One query. I can do `cd /c/Windows/Sysnative` in x86 cygwin. What's the point of having a virtual folder? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Virtual Windows folders - make them visible?
Greetings, Thomas Wolff! > Following up to a recent request about Windows/Sysnative, > I'd like to suggest to make Windows virtual folders visible in the > cygwin file system (if possible without continuous performance penalty...). There's one too many virtual folders, starting from %SystemRoot%\Sysnative and onward to control panel and other less-than-filesystem directories. Which of these you had in mind specifically? -- With best regards, Andrey Repin Thursday, November 19, 2020 19:12:39 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Please add /cygdrive/c/Windows/Sysnative to the default PATH
On 2020-11-17 16:41, tealhill via Cygwin wrote: On 2020-11-17 4:23 PM, Thomas Wolff wrote: Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin: >> Cygwin's /etc/profile sets the PATH. Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to the end of the PATH? > It doesn't add any other Windows folders so why this one. ### Summary Why should Cygwin add Sysnative to $PATH? As a workaround for Microsoft's failure to add Sysnative to %PATH%. You have the option to add SysNative to your system or user PATH under Windows, although that would best be done in your login script. ### Full explanation Cygwin imports the Windows %PATH% variable at startup. It would be ideal if Microsoft would add Sysnative to the default Windows %PATH%. Such a change would help Cygwin users and others. But I doubt that Microsoft will make this change. Therefore, I am suggesting that Cygwin work around Microsoft's omission. My suggested workaround is for Cygwin to add Sysnative to its own $PATH, automatically. Cygwin starts with Cygwin paths /usr/bin:/bin and everything else is up to you. You may add to your Cygwin PATH in your shell profile with code that switches depending on the existence of SysWOW64 and SysNative: cygpath -F 37 gives your application sysdir path, and cygpath -F 41 gives your x86 sysdir if there is one: https://docs.microsoft.com/en-ca/dotnet/api/system.environment.specialfolder?view=net-5.0 https://docs.microsoft.com/en-ca/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderidlist https://docs.microsoft.com/en-ca/windows/win32/shell/knownfolderid and please note that SysNative appears nowhere! -- 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. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: g++ and c++17 filesystem
Ok, first, I admit that I was not familiar with the details of std::filesystem. However, after looking at it, I remain unsurprised that the Cygwin and Mingw versions might be different. (I would also not be surprised if there is a real bug in there.) The behavior I would _expect_ is that the Cygwin version will work using Posix sorts of assumptions. While a root of C: (for example) _might_ work, /cygdrive/c is more normative on Cygwin. (I put a link to that in Cygwin's / called c, so that, for me, /c works.) Likewise, I would expect the normative path separator to be / not \, and an absolute path to start with /. Windows offers several kinds of symlinks, with varying semantics, so the detailed behavior of that would be affected by the settings in the CYGWIN environment variable. I would expect std::filesystem to present paths to construct paths to present to underlying library calls such as open ... and on Cygwin, open uses Posix style paths. I "get" that you want to write portable programs that use this interface, which is analogous to the Java file path classes. In terms of how this interface works, I would expect it to _claim_ that it is Posix, not Windows, because the paths Cygwin supports are Posix style (it _will_ recognize a few Windows idioms, but it is correct in not advertising itself as Windows). So it you want to do Windows-style (but abstracted with this library), I direct you to Mingw. Each has its place. Cygwin allows one to pretend, pretty successfully though with a few small rough edges, that one is on Linux, not Windows. That is its intent. Mingw gives you the gcc/gnu toolchain and libraries under Windows. I hope we're not still talking at cross purposes, though that it certainly possible! Best wishes - EM -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Sv: g++ and c++17 filesystem
On 2020-11-19 03:03, Kristian Ivarsson via Cygwin wrote: 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin : On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: The filesystem-library as a part of C++17 seems to have some defects and flaws in the cygwin-package and pretty much every lexical- and canonical operation works in mysterious ways (or not at all) https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 As stated earlier, it seems like using mingw g++/libstdc++ (from the cygwin-package-manager) it seems like it works better, but then you can’t mix with other posix/cygwin mechanism (that uses cygstdc++) without breaking ODR (and probably some memory models etc as well) so maybe someone do have some insightful info about this ? How “special” is cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in that library (cygstdc++) ? I might be totally wrong, so does anyone have any take on this ? Cygwin provides cross-tools like djgpp-gcc-core mingw64-i686-gcc-core, mingw64-x86_64-gcc-core, cygwin32-gcc-core, cygwin64-gcc-core, and djgpp-binutils, mingw64-i686-binutils, mingw64-x86_64-binutils, cygwin32-binutils, cygwin64-binutils so anyone has the freedom to choose to build DOS, Windows, or Cygwin apps targeting their respective APIs, under Cygwin, and also have the freedom to give away or sell those apps as long as they respect their licences. Cygwin's goal is to have everyone and everything believe it is running in a POSIX environment and provide interoperability within a Windows environment (including Wine) based on POSIX standards, system interfaces, toolchains, shells, utilities: https://pubs.opengroup.org/onlinepubs/9699919799/ system and network servers and services, plus GUI desktops (GNOME, KDE, LXDE, MATE, Plasma, Xfce desktops on X Window System), and apps (task and file managers, web browsers, PDF viewers and editors, graphics viewers and editors including GIMP). This is all ported and supported by volunteers who believe everyone should have a choice, even when for business or family reasons they use Windows. -- 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. [Data in binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Failed assertion dialog box ATTN: Takashi Yano
--- De : Cygwin de la part de André Bleau via Cygwin Envoyé : 15 novembre 2020 15:39 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box --- De : Cygwin de la part de André Bleau via Cygwin Envoyé : 15 novembre 2020 15:04 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box --- De : Cygwin de la part de William M. (Mike) Miller via Cygwin Envoyé : 15 novembre 2020 08:12 À : The Cygwin Mailing List Objet : Re: Failed assertion dialog box On Sat, Nov 14, 2020 at 11:49 PM Duncan Roe wrote: ... > > Sorry, should have mentioned running on Win7 Home. > > When I try it on my wife's Win10 system, I get the dialog box same as you. > That's disappointing. Thanks for the additional information, though. --- I would say we got some useful info: 1- The bug is OS specific; it occurs in Windows 10 2- Three persons were able to reproduce it on Windows 10, which improves the probability of getting fixed. - André Bleau --- Here's some more info: It seems the bug is related to pseudo-console support; that explains why it is Windows 10 specific. Experiment: CYGWIN=disable_pcon /usr/bin/mintty & In the newly created window: $ ./a.exe output.txt 2>&1 Aborted (core dumped) No message box popup. $ cat output.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() In the original mintty window, with empty CYGWIN env variable: $ ./a.exe output.txt 2>&1 Aborted (core dumped) A message box pops AND: $ cat output.txt output.txt is empty So, 2 problems here. In a CMD Window: set path=%PATH%D:\Cygwin\bin; a.exe outcmd.txt 2>&1 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump type outcmd.txt assertion "false" failed: file "assert.cpp", line 3, function: int main() 1 [main] a 759 cygwin_exception::open_stackdumpfile: Dumping stack trace to a.exe.stackdump The bug could be in cygwin or in mintty. Maybe this is something that Thomas Wolff (mintty author) or Takashi Yano (pseudo-console support expert) would want to look at. --- OK, I opened an issue for mintty and it was quickly closed with that quote: "Quick generic answer: if it's caused by ConPTY support, it's not related to mintty; also mintty never shows any popups. Funny thing, though, but really: assert isn't handled by the terminal." So the issue can only be with pseudo-console support in cygwin. - André Bleau - André Bleau -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Virtual Windows folders - make them visible?
Following up to a recent request about Windows/Sysnative, I'd like to suggest to make Windows virtual folders visible in the cygwin file system (if possible without continuous performance penalty...). Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Sv: g++ and c++17 filesystem
> > 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin : > > > > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: > > > On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: > >>> > The filesystem-library as a part of C++17 seems to have some > defects and flaws in the cygwin-package and pretty much every > lexical- and canonical operation works in mysterious ways (or not > at all) > >>> [snip] > >>> > >>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 [snip] > As stated earlier, it seems like using mingw g++/libstdc++ (from the > cygwin-package-manager) it seems like it works better, but then you can’t > mix with other posix/cygwin mechanism (that uses cygstdc++) without > breaking ODR (and probably some memory models etc as well) so maybe > someone do have some insightful info about this ? How “special” is > cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in that > library (cygstdc++) ? I think the problem can be viewed in /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/bits/fs_path.h and ... #if defined(_WIN32) && !defined(__CYGWIN__) # define _GLIBCXX_FILESYSTEM_IS_WINDOWS 1 # include #endif ... that when build in CYGWIN will make the stdc++ think it is not on Windows (and I guess cygstdc++-6.dll will be built without _GLIBCXX_FILESYSTEM_IS_WINDOWS implicitly), thus, the std::filesystem-library will act as it is on a Posix-system, but it is not and thus it makes wrong assumptions It seems like the (ordinary) MinGW-shipping includes these directives (!defined(__CYGWIN__)) as well and my naive take on this is that it is a (the) mistake The underlaying filesystem IS Windows and NOT Posix, but my guess is that (some) Posix-system-calls and/or assuming Posix-style-paths are invoked when _GLIBCXX_FILESYSTEM_IS_WINDOWS is not set I guess the correct way would be to let _GLIBCXX_FILESYSTEM_IS_WINDOWS and maybe just have a #ifdef (__CYGWIN__) as an extra option ONLY when handling lexical stuff, i.e. it allows both Windows- and Posix-styles but the system calls should always be Windows calls (and I guess this would imply better performance as well to not need to walk through the whole Cygwin-posix-abstraction) I might be totally wrong, so does anyone have any take on this ? Best regards, Kristian > Best regards, > Kristian [snip] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Please add /cygdrive/c/Windows/Sysnative to the default PATH
Greetings, tealhill! > On 2020-11-17 4:23 PM, Thomas Wolff wrote: >> Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin: >>> >>> Cygwin's /etc/profile sets the PATH. >>> >>> Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to >>> the end of the PATH? >> >> It doesn't add any other Windows folders so why this one. > ### Summary > Why should Cygwin add Sysnative to $PATH? As a workaround for > Microsoft's failure to add Sysnative to %PATH%. It was never a failure. And if you use proper platform tools, it's not an issue either. > ### Full explanation > Cygwin imports the Windows %PATH% variable at startup. Not necessarily. Depends on your .profile configuration. > It would be ideal if Microsoft would add Sysnative to the default > Windows %PATH%. No, that would be a disaster. > Such a change would help Cygwin users and others. But > I doubt that Microsoft will make this change. > Therefore, I am suggesting that Cygwin work around Microsoft's omission. > My suggested workaround is for Cygwin to add Sysnative to its own > $PATH, automatically. I'm suggesting you install 64-bit Cygwin already. 32-bit Cygwin is rapidly running out of its usefulness. -- With best regards, Andrey Repin Thursday, November 19, 2020 12:13:58 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock"
-Original Message- From: Cygwin On Behalf Of rt...@sciencetools.com Sent: 18 November 2020 22:03 To: cygwin@cygwin.com Subject: Trouble with starting XWin, "(EE) Can't read lock file /tmp/.XO-lock" Hey everyone, SUPER long time Cygwin user, seldom need help, and my versions are all ancient now and I can't upgrade, I don't think. I'm on Windows 7 and am stuck there. Other version data follows. Everything had been working fine for years, then I had a system crash and on restart, this is the only error I can find. When run from the Cygwin shell command line, it goes like this: $ XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.19.2.0 OS: CYGWIN_NT-6.1 Okrasa 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.19.2-1 built 2017-03-09 XWin was started with the following command line: XWin :0 -multiwindow -clipboard -wgl -ac -listen tcp (EE) Fatal server error: (EE) Could not create lock file in /tmp/.tX0-lock winDeinitMultiWindowWM - Noting shutdown in progress $ I tried with window IDs 1 and 2 instead of zero but these didn't work either. Later, while busy with other things, there was a power failure for the facility and when the power came back on, of course the system had rebooted so I tried again and got the same thing. ...Somehow early in my testing to get this going, without intentionally doing anything else, I noticed the error changed from "Could not create lock file in", to "Can't read lock file /tmp/.X0-lock". Looking for the directory previously mentioned, it wasn't there so I decided to try and create that directory. When I do that, the error goes back to "Could not create lockfile in". ... I wonder if I created it with the right ownership and permissions, so I tried several things with no success. ...I'm rather desperate to fix this as this feature has become a key tool for this particular system. Ideas? Help? Thanks, RT Also a long-time W7 user: try deleting everything X-relevant under /tmp/ (in my case .X11-unix/ and its contents) and then $ run XWin -clipboard -nolock -multiwindow I know, simpler than yours - but this has evolved over the years, replacing earlier more complex command lines which suddenly broke, usually after some relevant update. Any good? BUT NB I am Cygwin-current - what's your difficulty with updating? Fergus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Sv: g++ and c++17 filesystem
> >> I would agree that if you want an executable that acts and feels more > like a Windows native application, then mingw is probably what you want. > Cygwin is if you want something that acts and feels more like a Posix > thing ... which means it will be oriented to Posix style paths. > > To be able to use mingw all the code have to be ported to use Windows > > native mechanisms and then we might just use MSVC instead > > > > We don’t want (either) Windows-style-paths or Posix-style-paths, we > > want A path and expect it to work equally regardless of what platform > > is used in regards to std::filesystem > > > > As far as I see, very few applications do form their own - and/or have > > hard-coded absolute paths and instead they are usually input data > > (through UI, configuration, OS, environment or such) > > IN this context, I would say "Which std::filesystem? The Cygwin Posix- > like one or the mingw Windows-like one?" If you want uniformity, I'd go > with Cygwin; it you want platform-like behavior, then mingw. I'm referring to std::filesystem as a part of the C++17 standard (https://en.cppreference.com/w/cpp/filesystem) that is pretty well defined and quite agnostic to what "style" of path used as our application are and as I said, we don't care (we don't ever inspect them) what "style" of paths we're using but we expect a deterministic behaviour from that library regardless of operating system, such as and absolute path should be an absolute path regardless That's the sole purpose of std::filesystem, i.e. to be platform independent (though all file-features is not applicable on all operating systems, but at least you can ask the library for those attributes) GCC/MinGW support platform-INDEPENDENT-behaviour because gcc/g++ works equally regardless if Linux or Windows in regards to std::filesystem Best regards, Kristian > Best wishes - EM > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
