Re: Can't start a cygwin terminal(mintty) as admin
On Tuesday, November 24, 2020, 03:59:19 PM EST, Thomas Wolff wrote: Am 24.11.2020 um 21:22 schrieb Kevin Schnitzius via Cygwin: >> Ctrl-c is broken on mintty. > This is a wrong statement. For a terminal, Ctrl+c is just a control > character, nothing else. It's the pty device, shell or application that > may, or may not, associate it with specific handling like interruption. D:\cygwin64\bin\mintty.exe -o "KeyFunctions=A+F5:break" - alt-F5 is a break that works on both Cygwin and non-Cygwin processes. D:\cygwin64\bin\mintty.exe -o "KeyFunctions=C+c:break" - Ctrl-c is a break that works on Cygwin processes only. This C+c used to work in both cases... I think we've been over this before andthe problem very well may be in the pty break handling. Kevin -- 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 v2 1/2] specialnames.xml: add proc(5) Cygwin man page
--- winsup/doc/specialnames.xml | 2094 +++ 1 file changed, 2094 insertions(+) diff --git a/winsup/doc/specialnames.xml b/winsup/doc/specialnames.xml index a1f7401e16b9..a1f9d3f5e806 100644 --- a/winsup/doc/specialnames.xml +++ b/winsup/doc/specialnames.xml @@ -486,6 +486,2100 @@ one in Linux, but it provides significant capabilities. The procps package contains several utilities that use it. + + + + + + + + + + + + + 2020-11-24 + Cygwin Project + + + proc + 5 + 2020-11-24 + Cygwin + Cygwin User's Manual + + + + proc + process and system information pseudo-filesystem + + + + Description + The proc filesystem is a pseudo-filesystem + which provides an interface to Cygwin data structures. + It is commonly mounted at /proc. + Typically, it is mounted automatically by the system. + + + + Overview + Underneath /proc, there are the following + general groups of files and subdirectories: + + + + + /proc/[pid] subdirectories + + Each one of these subdirectories contains files and + subdirectories exposing information about the process with the + corresponding process id. + + + The /proc/[pid] subdirectories are + visible when iterating through /proc with + + readdir2 + + (and thus are visible when one uses + + ls1 + + to view the contents of /proc). + + + + + + /proc/self + + When a process accesses this magic symbolic link, it resolves + to the process's own /proc/[pid] directory. + + + + + + /proc/[a-z]* + + Various other files and subdirectories under + /proc expose system-wide information. + + + + + + + All of the above are described in more detail below. + + + + + + Files and directories + + The following list provides details of many of the files + and directories under the /proc hierarchy. + + + + + /proc/[pid] + + + There is a numerical subdirectory for each running + process; the subdirectory is named by the process id. + Each /proc/[pid] subdirectory + contains the pseudo-files and directories described below. + + + The files inside each /proc/[pid] + directory are normally owned by the effective user and + effective group id of the process. + + + + + + /proc/[pid]/cmdline + + This read-only file holds the complete command line for the + process, unless the process is a zombie. + In the latter case, there is nothing in this file: that is, a + read on this file will return 0 characters. + The command-line arguments appear in this file as a set of + strings followed by null bytes (0). + + + + + + /proc/[pid]/ctty + + + This read-only file holds the name of the console or control + terminal device for the process, unless the process is detached + from any terminal. + In the latter case, there is only a newline in this file. + + + + + + /proc/[pid]/cwd + + + This is a symbolic link to the current working directory of the + process. + To find out the current working directory of process 20, for + instance, you can do this: + + + $ cd /proc/20/cwd; /bin/pwd + + + + Note that the pwd command + is often a shell built-in, and might not work properly. In + + bash1 + , + you may use pwd-P. + + + + + /proc/[pid]/environ + + + This read-only file contains the current environment that may + have been changed by the currently executing program. + The entries are separated by null bytes (0), + and there may be a null byte at the end. + Thus, to print out the environment of process 1, you would do: + + + $ cat -A /proc/1/environ + + + + If, after an + + execve2 + , + the process modifies its environment (e.g., by calling + functions such as + + putenv3 + + or modifying the + + environ7 + + variable directly), this file will reflect those changes. + That may not be the case on other systems such as Linux. + + + + + /proc/[pid]/exe + + + This file is a symbolic link containing the actual pathname of + the executed command. + This symbolic link can be dereferenced normally; attempting to + open it will open the executable. + You can even type /proc/[pid]/exe + to run another copy of the same executable that is being run by + process [pid]. + /proc/[pid]/exe is a pointer to + the binary which was executed, and appears as a symbolic link. + + + + + + /proc/[pid]/exename + + +
[PATCH v2 2/2] winsup/doc/Makefile.in: create man5 dir and install proc.5
--- winsup/doc/Makefile.in | 4 1 file changed, 4 insertions(+) diff --git a/winsup/doc/Makefile.in b/winsup/doc/Makefile.in index cc4a1bec305b..f2a838a5dcf7 100644 --- a/winsup/doc/Makefile.in +++ b/winsup/doc/Makefile.in @@ -17,6 +17,7 @@ htmldir = @htmldir@ mandir = @mandir@ man1dir = $(mandir)/man1 man3dir = $(mandir)/man3 +man5dir = $(mandir)/man5 infodir:=@infodir@ sysconfdir:=@sysconfdir@ @@ -61,6 +62,7 @@ clean: rm -f api2man.stamp intro2man.stamp utils2man.stamp rm -f *.1 rm -f *.3 + rm -f *.5 rm -f *.info* charmap install: install-all @@ -86,6 +88,8 @@ install-man: utils2man.stamp api2man.stamp intro2man.stamp $(INSTALL_DATA) *.1 $(DESTDIR)$(man1dir) @$(MKDIRP) $(DESTDIR)$(man3dir) $(INSTALL_DATA) *.3 $(DESTDIR)$(man3dir) + @$(MKDIRP) $(DESTDIR)$(man5dir) + $(INSTALL_DATA) *.5 $(DESTDIR)$(man5dir) install-info: cygwin-ug-net.info cygwin-api.info $(MKDIRP) $(DESTDIR)$(infodir)
Re: Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
On 11/24/20 2:01 PM, sten.kristian.ivars...@gmail.com wrote: [snip] std::filesystem POSIX mode is common to all POSIX platforms where backslashes are NOT directory separators. How do you make them accept your demands? How are you going to force POSIX platforms allow Windows specific code? I've been trying to say over and over again that our code doesn't handle any Windows specific stuff and not anywhere have I claimed that anyone else need to handle Windows specific stuff either (except for the internals of Cygwin of which Windows specific logic is already present) I repeat; I don't expect any of the Cygwin-Posix-functions to accept any Windows-style-paths (though some of them, as I repeatedly have said, already does so) and I only expect that I can operate according to the C++-standard on an instantiated std::filesystem::path How do you expect std::filesystem to do that when Windows paths are not even accepted in API calls? What API-calls ? Cygwin-Posix-API-calls ? If so, you assume that std::filesystem in Cygwin must be implemented using the underlaying Cygwin-Posix-API and maybe it must be of some reason, but I guess it even would be possible to make it the other way around, i.e. quite a bunch of the Cygwin-Posix-file-API-functions could be implemented by using some native std::filesystem-implementation such as MinGW but I guess that not the whole Cygwin-Posix-file-API could be implemented that way and it would probably be some quite substantial rewrite of things that probably is not worth the effort, but what I'm trying to say is that std::filesystem shipped with Cygwin not necessarily have to be implemented totally with the underlaying Cygwin-Posix-API. It could be a mix to use whatever is appropriate and in some circumstances some logic is needed to understand both kind of paths See more below No, std::filesystem runs on top of Cygwin, not under it, it would have to use POSIX APIs to get anything done. GCC is not the platform system library. Make it try to enter subdirectories every time std::filesystem is called? You refuse to understand that Cygwin is NOT Windows, it is a POSIX platform. Using Cygwin means complying with POSIX expectations and standards. I don't see how this conversation can continue if you still refuse to see Cygwin as something separate from Windows. Besides, you have already answered your question by ruling out MinGW, so Microsoft Visual Studio it is. I repeat (again); neither MinGW/MSVS is an option because we're trying to use Posix and C++ Just to be clear: - Our code DOESN'T handle Windows-style-paths explicitly in any way - We DON'T expect Cygwin-Posix-file-related-functions to accept Windows-style-paths - We WOULD like std::filesystem to work according to the C++ ISO standard Why would std::filesystem be an exception? How would it know if a backslash is part of a name and not a separator? How does it know when to apply exceptions? What about mixed paths? As I've said before, there are already exceptions. Some Cygwin-Posix-mechanisms already understands both kinds of path's today How are '\' handled as part of the name today ? I works perfectly well in many circumstances, so I guess that there are quite a few exceptions already Its not able to read your mind to find out your intentions, especially when it comes to ambiguous strings like UNC or SMB paths, none of these are remotely POSIX compliant. The C++ standard mentions separators, not specific characters, and the forward slash is used under Cygwin, not the Windows backslash. Exactly, I haven't stated anything else So use the forward slash, not backslash. The bigger question would be how would you expect a Cygwin application to even accept a Windows paths. It should use *nix paths, as all Cygwin programs do Cygwin (and thus applications build within Cygwin) already do accept Windows paths here and there as well as std::filesystem It does not. There are giant warnings telling you not to rely on it. Applications don't have control of all the input that could come from UI, environment, configuration, etc Garbage in, garbage out. The warnings tell you to use Unix paths. What I'm trying to make a point of is that wouldn't it be good if applications didn't have to care about that, because that is what libraries/frameworks are for, to give an abstraction ? Otherwise every application have to do something like where ever it handles some path #ifdef _CYGWIN_ // fix the path-representation to something with /cygdrive or such ... #endif Why? Cygwin is a POSIX system. The prefix isn't even necessarily /cygdrive and you're just introducing more complications that falls apart the moment the defaults change. This is what we're hoping to avoid to do and that it could be done in the library we're using The exact details of how to implement this and what challenges that would be is uninteresting before it could be settled as "Yeah, it
Re: g++ and c++17 filesystem
On 2020-11-24 07:31, Kristian Ivarsson via Cygwin wrote: On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: all the std::filesystem implementations I've seen for Windows The implementation on top of Cygwin is not "for Windows", it's "for Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do. And that's where we keep talking at cross purposes. Maybe it is the right thing to do, but what is your take of why it must be so (all the way) ? Nobody is interested in doing the work to submit and modify patches to get them accepted and change it from the way it is. I also do understand that it have several advantages in the implementation of std::filesystem but it also imply an extra layer of abstraction to the underlaying platform, but to just remove the _CYGWIN_ macro when building it would make std::filesystem to not understand /cygdrive at all (and I guess that would confuse other users;-) so I guess it would require some more sophisticated implementation (or extend the number of exceptions already existing in the underlaying Cygwin-Posix-implementation) If you only use POSIX compliant Cygwin or UNC (//) paths, all your programs built under Cygwin should run successfully under Windows or Wine. Otherwise if you built under Cygwin, you can overload your directory and file path methods so if a path contains : or \\ you call cygwin_conv_path() with appropriate flags to fix your path before using it. Or build with Mingw or MSVC++ and use whatever those allow. Cygwin is an open source project maintained solely by volunteer contributors in their spare time, and its focus is on working around Windows limitations to provide a POSIX standard environment and experience, supporting more POSIX features as Windows limitations are removed. Other projects gcc-g++, libstdc++ may have sponsored or employed contributors. They all have their respective standards focus and are uninterested in non-standard-compliant changes and any non-POSIX build changes. But they build and run just fine under Cygwin. Feel free to make the appropriate patches to the components and submit the patches to the upstream projects. But be prepared for the upstream projects to reject the patches if they break some standard or compliant test case or use case. Note that it has taken Intel and then MS five years to get FSGSBASE support patches accepted in Linux. If you are unprepared to do the necessary work, you still get a lot more than what you paid for. ;^> -- 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: Can't start a cygwin terminal(mintty) as admin
On Tue, 24 Nov 2020 13:51:59 +0100 (CET) > QUESTION 1 : HOW TO NOW HANDLE CTRL-C in a multi threaded cygwin application > regarless of terminal Could you provide simple test case which can reproduce your problem? > QUESTION 2 : HOW TO LAUNCH A MINTTY SESSION AS ADMIN In my environment, "Run as administrator" menu on mouse-right-click works. -- 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: Please add /cygdrive/c/Windows/Sysnative to the default PATH
On 2020-11-24 00:24, Thomas Wolff wrote: Am 19.11.2020 um 16:57 schrieb Brian Inglis: 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! That's because Sysnative is not a known folder. It is rather unknown just because it is virtual :) And that is the problem I tried to address. In cygwin32, you can `cd $WINDIR/Sysnative` but you wouldn't see the folder. For tools like ls or find it simply does not exist, while obviously it exists somehow and can be used in PATH. It is visible to find and ls when explicitly specified as /proc/cygdrive/c/Windows/SysNative/ so the contents can be listed and searched, but you have to know to do so, as it does not appear to be derivable from Windows information like other folders. -- 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
[ITP] wget2
On 2020-07-08 14:05, Brian Inglis wrote: wget2 is the successor of wget supplying a shared library API like curl to build a modern, fast, multi-threaded, parallel downloader using HTTP/2, HTTP compression and If-Modified-Since headers; see: https://gitlab.com/gnuwget/wget2 It is currently available on Arch, Debian/Ubuntu, openSUSE, Slackware; see: https://repology.org/project/wget2/versions Thanks for help getting here and also the upstream folks! Please review wget2 repackaged into subpackages available under: https://drive.google.com/drive/folders/1VVuC14KuB6uShm4FQL9BuXH0hpLYnIcJ?usp=sharing Appveyor CI playground repo wget2 jobs: https://cygwin.com/cgi-bin2/jobs.cgi?id=1308 I have been dogfooding wget2 instead of wget in commands and cron jobs and it appears considerably faster, but does not support FTP or other protocols supported by curl or wget, and does not support wget --retr-symlinks=no option which retrieves symlink contents verbatim for analysis with readlink e.g. wget ...-latest... and see if it points to the previous or a newer version. For more compatibility info see: https://gitlab.com/gnuwget/wget2/-/wikis/home -- 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.]
Re: [PATCH 1/2] specialnames.xml: add proc(5) Cygwin man page
On 2020-11-24 07:48, Jon Turney wrote: On 23/11/2020 22:11, Brian Inglis wrote: --- winsup/doc/specialnames.xml | 2100 +++ 1 file changed, 2100 insertions(+) I'm not sure how you generated this email. But sending the patch inline (using 'git-send-email'?), rather than as an attachment makes it a lot easier to make review comments inline. It's right from git send-email which creates the MIME sections in the patches: " ... X-Mailer: git-send-email 2.29.2 ... This is a multi-part message in MIME format. --2.29.2 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit --- winsup/doc/specialnames.xml | 2100 +++ 1 file changed, 2100 insertions(+) --2.29.2 Content-Type: text/x-patch; name="0001-specialnames.xml-add-proc-5-Cygwin-man- page.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-specialnames.xml-add-proc-5-Cygwin-man-page.patch" ..." so it may be down to how your MUA displays those, and we are running the same release of TB, which on mine shows the patch "inline" after a filename separator like any other text attachment. Ctrl-U displays email source including headers; search for 'User-Agent:' or 'Mailer:' in headers. A few lines have trailing whitespace, which should be removed. Not in the patched lines, which appear in *RED* in git diff, and I just rechecked that they are in context lines, so I left them alone for separate cleanup, as I have been chastised on previous occasions. ;^> diff --git a/winsup/doc/specialnames.xml b/winsup/doc/specialnames.xml index a1f7401e16b9..6b86187f39e9 100644 --- a/winsup/doc/specialnames.xml +++ b/winsup/doc/specialnames.xml @@ -486,6 +486,2106 @@ one in Linux, but it provides significant capabilities. The procps package contains several utilities that use it. + +
Re: Can't start a cygwin terminal(mintty) as admin
Am 24.11.2020 um 21:22 schrieb Kevin Schnitzius via Cygwin: On Tuesday, November 24, 2020, 07:52:11 AM EST, aki...@free.fr wrote: QUESTION 1 : HOW TO NOW HANDLE CTRL-C in a multi threaded cygwin application regarless of terminal Ctrl-c is broken on mintty. This is a wrong statement. For a terminal, Ctrl+c is just a control character, nothing else. It's the pty device, shell or application that may, or may not, associate it with specific handling like interruption. I use this: D:\cygwin64\bin\mintty.exe -o "KeyFunctions=A+F5:break" - And use alt-F5 as a break that works on both Cygwin and non-Cygwin processes. QUESTION 2 : HOW TO LAUNCH A MINTTY SESSION AS ADMIN cygstart --action=runas mintty.exe Kevin -- 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
Re: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
For the specific case C:\Temp, I found this: cygpath -ua 'C:\Temp' -> /cygdrive/c/Temp cygpath -ua /cygdrive/c/Temp -> /cygdrive/c/Temp cygpath -ua '\Temp' -> /cygdrive/c/Temp cygpath -ua '/Temp' -> /Temp Now Cygwin is open source, so you, too, could grab the code in cygpath and call it as a subroutine, maybe, to try to canonicalize a wider range of paths. Note the interesting difference between the \Temp and /Temp cases. cygpath is processing \Temp as a Windows-like thing, and thus interpreting it according the the Windows root for the current drive. However, it processes /Temp and a Posix-like path, which will be in term of the _Cygwin_ root, generally the CYgwin install directory. Still, if you did this canonicalization first, maybe you would get more what you're looking for? I'm not sure it would be a good idea to insert this generally into the Cygwin library stack. Others more familiar with the fine details can probably elaborate why. Regards - Eliot Moss -- 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: Can't start a cygwin terminal(mintty) as admin
On Tuesday, November 24, 2020, 07:52:11 AM EST, aki...@free.fr wrote: > QUESTION 1 : HOW TO NOW HANDLE CTRL-C in a multi threaded cygwin application >regarless of terminal Ctrl-c is broken on mintty. I use this: D:\cygwin64\bin\mintty.exe -o "KeyFunctions=A+F5:break" - And use alt-F5 as a break that works on both Cygwin and non-Cygwin processes. > QUESTION 2 : HOW TO LAUNCH A MINTTY SESSION AS ADMIN cygstart --action=runas mintty.exe Kevin -- 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: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
On 11/24/2020 9:31 AM, Kristian Ivarsson via Cygwin wrote: On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: all the std::filesystem implementations I've seen for Windows The implementation on top of Cygwin is not "for Windows", it's "for Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do. And that's where we keep talking at cross purposes. Maybe it is the right thing to do, but what is your take of why it must be so (all the way) ? I also do understand that it have several advantages in the implementation of std::filesystem but it also imply an extra layer of abstraction to the underlaying platform, but to just remove the _CYGWIN_ macro when building it would make std::filesystem to not understand /cygdrive at all (and I guess that would confuse other users;-) so I guess it would require some more sophisticated implementation (or extend the number of exceptions already existing in the underlaying Cygwin-Posix-implementation) I'd like to try to make this discussion more concrete by looking at what's actually going on in the test program main.cpp that you posted at the beginning of that thread. (I ran it under strace and gdb to see this for myself.) First, your program calls std::filesystem::exists, which ultimately calls stat(2) in the Cygwin DLL. The work for this is done in the path_conv::check function and various functions that it calls. These functions have code that recognizes Win32 paths like C:\Temp, and std::filesystem::exists therefore reports "true". This is consistent with the statement at https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 about how the Cygwin DLL treats Win32 paths. Next, your program calls std::filesystem::canonical. This calls std::filesystem::absolute, which reports that C:\Temp is not an absolute path. It therefore tries to treat it as a relative path and fails with "No such file or directory" because /C:\Temp does not exist. Note that the Cygwin DLL never sees the original path C:\Temp in this case. Again, this is consistent with the statement in the documentation that Cygwin applications do not necessarily recognize Win32 paths. You say this is a bug, because first you're told that C:\Temp exists and then you're told it doesn't. But I think it just illustrates the hazards of using Win32 paths in Cygwin, which tries hard to emulate Posix. Sometimes you can get away with using Win32 paths and sometimes you can't, depending on how and when the Cygwin DLL is involved. I don't see a good way to avoid this inconsistency. We could change Cygwin so that it rigidly recognizes only Posix paths. Cygwin would then be consistent, but we would be removing a feature that many users have become accustomed to. And it wouldn't help you. Or we could ask all Cygwin package maintainers to try to patch their packages so that they recognize Win32 paths, but that's simply not feasible, nor would many package maintainers be willing to invest the required time. I tried it once with emacs, which I maintain, in response to a user request. I failed miserably. Every change I made broke something else, and I finally gave up. I don't think g++ will be any easier than emacs, and I don't think you can expect the g++ maintainer to work on this. Ken -- 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: [ITA] wxWidgets3.0
On 24/11/2020 10:43, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Ignore that message, I made a silly mistake.
>
> On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> Well, something's gone wrong with my Cygwin install I think, because
>> even with previously working cygport recipes, I can no longer produce a
>> working build.
>>
>> The samples tend to either exit immediately or segfault, and trying to
>> use wxPython yields:
>>
>> "
>>
>> Traceback (most recent call last):
>>
>> File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
>>
>> "__main__", mod_spec)
>>
>> File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
>>
>> exec(code, run_globals)
>>
>> File "./demo/__main__.py", line 5, in
>>
>> import Main
>>
>> File "./demo/Main.py", line 61, in
>>
>> import wx
>>
>> File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in
>>
>>
>> from wx.core import *
>>
>> File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in
>>
>> from ._core import *
>>
>> ImportError: No such process
>>
>>
>> "
>>
>> I did try a rebase as well, but it doesn't seem to help. This looks like
>> an issue I had right when I first tried to compile wxPython, and it
>> mysteriously went away at some point. Does anyone know why this might be
>> happening? Maybe I need to reinstall Cygwin, but I haven't done anything
>> with it between the successful build of wxWidgets and the failed ones,
>> so it's not making a whole lot of sense.
>>
>> Hamish
Okay, so attached is my latest cygport file. I'm still building for
32-bit, so I'll upload and link to the new packages tomorrow.
Changes:
- Split BUILD_REQUIRES across two lines for definitely build time and
probably only runtime deps.
- Use system regex library explicitly.
- Removed obsolete --without-gnomeprint option.
- Use gnomevfs (old bug no longer seems to apply).
I tried using the STL, but it results in libraries that don't work as:
#1: the wxwidgets demos either segfault instantly or just exit instantly.
#2: wxpython no longer works and returns the No such process error above.
Hamish
NAME="wxWidgets3.0"
VERSION=3.0.5.1
RELEASE=1
CATEGORY="Libs"
SUMMARY="wxWidgets C++ application framework"
DESCRIPTION="wxWidgets is a set of libraries that allows C++ applications to
compile and run on several different types of computer, with minimal source
code changes. There is one library per supported GUI. As well as providing a
common API for GUI functionality, it provides functionality for accessing some
commonly-used operating system facilities, from copying and deleting files to
socket and thread support."
HOMEPAGE="http://wxwidgets.org/;
SRC_URI="https://github.com/wxWidgets/wxWidgets/releases/download/v${VERSION}/wxWidgets-${VERSION}.tar.bz2;
SRC_DIR="wxWidgets-${VERSION}"
#Just for building:
BUILD_REQUIRES="make cppunit graphviz autoconf pkg-config gcc-core gcc-g++
doxygen libX11-devel libgtk2.0-devel libgtk3-devel libwebkitgtk1.0-devel
libwebkitgtk3.0-devel libpng-devel libjpeg-devel libexpat-devel libiconv-devel
libmspack-devel libnotify-devel libtiff-devel libXpm-devel libcogl-devel
libEGL-devel libGL-devel libGLU-devel libSDL2-devel libSDL2_image-devel
libSDL2_mixer-devel libSDL2_net-devel libSDL2_ttf-devel zlib-devel"
#For running unit tests/runtime (currently disabled because they don't work).
#Still needed for manual testing though, so leaving in here.
BUILD_REQUIRES="$BUILD_REQUIRES xclock libwebkitgtk1.0_0 libwebkitgtk3.0_0
libpng16 libjpeg8 libexpat1 libiconv libiconv2 libmspack0 libnotify libnotify4
libtiff6 libXpm4 libcogl20 libEGL1 libGL1 libGLU1 libSDL2_2.0_0
libSDL2_image2.0_0 libSDL2_mixer2.0_0 libSDL2_net2.0_0 libSDL2_ttf2.0_0 zlib"
PATCH_URI="
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/wxGTK3-3.0.3-abicheck.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-filename-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/fix-vararg-test.patch
https://src.fedoraproject.org/rpms/wxGTK3/raw/master/f/force-x11-for-wxgl.patch
wxGTK3-3.0.5.1-collision.patch
3.0.2-cygwin-auto-import.patch
3.0.2-cygwin-dlopen.patch
3.0.2-cygwin-unix.patch
3.0.2-cygwin-gcc5.patch
3.0.3-autoreconf.patch
3.0.3-cygwin-ftm.patch
0007-Fix-video-sink-fallback-in-wxMediaCtrl-when-xvimages.patch
"
slot=${PV_MAJ_MIN}
PKG_NAMES="libwx_baseu3.0_0 libwx_baseu3.0-devel ${NAME}-doc
libwx_gtk2u3.0_0 libwx_gtk2u3.0-devel
libwx_gtk3u3.0_0 libwx_gtk3u3.0-devel"
libwx_baseu3_0_0_SUMMARY="${SUMMARY} (base unicode runtime)"
libwx_baseu3_0_0_CONTENTS="
--exclude=html
usr/bin/cygwx_baseu*-3.0-0.dll
usr/share/doc/${NAME}/
usr/share/locale/*/LC_MESSAGES/wxstd30.mo
"
libwx_baseu3_0_devel_REQUIRES="libexpat-devel libiconv-devel zlib-devel"
libwx_baseu3_0_devel_CONTENTS="
usr/bin/wxrc-3.0.exe
Re: Added to Mirror
Sorry for the missing information. https://mirrors.filigrane-technologie.fr/cygwin/x86_64/setup.ini Actually indexing is disable on the configuration, if you need it, i can enable it if necessary. Cordialement, Geoffroy Van Elsuve 114, boulevard Haussmann 75008 Paris Tél:06 60 69 72 32 Penser à l'environnement avant d'imprimer ce document. Cordialement, Geoffroy Van Elsuve 114, boulevard Haussmann 75008 Paris Tél:06 60 69 72 32 Penser à l'environnement avant d'imprimer ce document. Le mar. 24 nov. 2020 à 15:53, Jon Turney a écrit : > > On 23/11/2020 17:35, Geoffroy Van Elsuve wrote: > > Hi, > > > > Can you add our server to mirror list. > > > > Europe: > > France: mirrors.filigrane-technologie.fr(https) > > To add this mirror, I need the URL at which Cygwin files can be accessed. > > 'https://mirrors.filigrane-technologie.fr/' itself just gives '403 > Forbidden', so there's no way for me to discover this myself. > > Thanks. -- 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 24/11/2020 14:52, Bill Stewart wrote: > On Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote: > >>> and please note that SysNative appears nowhere! >> That's because Sysnative is not a known folder. It is rather unknown >> just because it is virtual :) >> And that is the problem I tried to address. In cygwin32, you can `cd >> $WINDIR/Sysnative` but you wouldn't see the folder. For tools like ls or >> find it simply does not exist, while obviously it exists somehow and can >> be used in PATH. > For the benefit of other readers regarding the Sysnative virtual directory: > > https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector > > The other links on the Microsoft documentation page regarding WoW64 > are also quite helpful. > > Bill Thanks for the link, it does help my understanding for sure. I was following along with moderate interest but now I understand better what the problem is and find it less confusing. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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 Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote: > > and please note that SysNative appears nowhere! > > That's because Sysnative is not a known folder. It is rather unknown > just because it is virtual :) > And that is the problem I tried to address. In cygwin32, you can `cd > $WINDIR/Sysnative` but you wouldn't see the folder. For tools like ls or > find it simply does not exist, while obviously it exists somehow and can > be used in PATH. For the benefit of other readers regarding the Sysnative virtual directory: https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector The other links on the Microsoft documentation page regarding WoW64 are also quite helpful. Bill -- 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: Added to Mirror
On 23/11/2020 17:35, Geoffroy Van Elsuve wrote: Hi, Can you add our server to mirror list. Europe: France: mirrors.filigrane-technologie.fr(https) To add this mirror, I need the URL at which Cygwin files can be accessed. 'https://mirrors.filigrane-technologie.fr/' itself just gives '403 Forbidden', so there's no way for me to discover this myself. Thanks. -- 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: [PATCH 1/2] specialnames.xml: add proc(5) Cygwin man page
On 23/11/2020 22:11, Brian Inglis wrote: --- winsup/doc/specialnames.xml | 2100 +++ 1 file changed, 2100 insertions(+) I'm not sure how you generated this email. But sending the patch inline (using 'git-send-email'?), rather than as an attachment makes it a lot easier to make review comments inline. A few lines have trailing whitespace, which should be removed. diff --git a/winsup/doc/specialnames.xml b/winsup/doc/specialnames.xml index a1f7401e16b9..6b86187f39e9 100644 --- a/winsup/doc/specialnames.xml +++ b/winsup/doc/specialnames.xml @@ -486,6 +486,2106 @@ one in Linux, but it provides significant capabilities. The procps package contains several utilities that use it. + +
Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: > > > all the std::filesystem implementations I've seen for Windows > > The implementation on top of Cygwin is not "for Windows", it's "for > Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do. > And that's where we keep talking at cross purposes. Maybe it is the right thing to do, but what is your take of why it must be so (all the way) ? I also do understand that it have several advantages in the implementation of std::filesystem but it also imply an extra layer of abstraction to the underlaying platform, but to just remove the _CYGWIN_ macro when building it would make std::filesystem to not understand /cygdrive at all (and I guess that would confuse other users;-) so I guess it would require some more sophisticated implementation (or extend the number of exceptions already existing in the underlaying Cygwin-Posix-implementation) Best regards, Kristian > Best wishes - Eliot Moss -- 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: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
> > [snip] > > > >> std::filesystem POSIX mode is common to all POSIX platforms where > >> backslashes are NOT directory separators. How do you make them accept > >> your demands? How are you going to force POSIX platforms allow > >> Windows specific code? > > > > I've been trying to say over and over again that our code doesn't > > handle any Windows specific stuff and not anywhere have I claimed that > > anyone else need to handle Windows specific stuff either (except for > > the internals of Cygwin of which Windows specific logic is already > > present) > > > > I repeat; I don't expect any of the Cygwin-Posix-functions to accept > > any Windows-style-paths (though some of them, as I repeatedly have > > said, already does so) and I only expect that I can operate according > > to the C++-standard on an instantiated std::filesystem::path > > > > How do you expect std::filesystem to do that when Windows paths are not > even accepted in API calls? What API-calls ? Cygwin-Posix-API-calls ? If so, you assume that std::filesystem in Cygwin must be implemented using the underlaying Cygwin-Posix-API and maybe it must be of some reason, but I guess it even would be possible to make it the other way around, i.e. quite a bunch of the Cygwin-Posix-file-API-functions could be implemented by using some native std::filesystem-implementation such as MinGW but I guess that not the whole Cygwin-Posix-file-API could be implemented that way and it would probably be some quite substantial rewrite of things that probably is not worth the effort, but what I'm trying to say is that std::filesystem shipped with Cygwin not necessarily have to be implemented totally with the underlaying Cygwin-Posix-API. It could be a mix to use whatever is appropriate and in some circumstances some logic is needed to understand both kind of paths See more below > >> Make it try to enter subdirectories every time std::filesystem is > >> called? > >> > >> You refuse to understand that Cygwin is NOT Windows, it is a POSIX > >> platform. Using Cygwin means complying with POSIX expectations and > >> standards. > >> > >> I don't see how this conversation can continue if you still refuse to > >> see Cygwin as something separate from Windows. Besides, you have > >> already answered your question by ruling out MinGW, so Microsoft > >> Visual Studio it is. > > > > I repeat (again); neither MinGW/MSVS is an option because we're trying > > to use Posix and C++ > > > > Just to be clear: > > > > - Our code DOESN'T handle Windows-style-paths explicitly in any way > > - We DON'T expect Cygwin-Posix-file-related-functions to accept > > Windows-style-paths > > - We WOULD like std::filesystem to work according to the C++ ISO > > standard > > Why would std::filesystem be an exception? How would it know if a > backslash is part of a name and not a separator? How does it know when to > apply exceptions? What about mixed paths? As I've said before, there are already exceptions. Some Cygwin-Posix-mechanisms already understands both kinds of path's today How are '\' handled as part of the name today ? I works perfectly well in many circumstances, so I guess that there are quite a few exceptions already > The C++ standard mentions separators, not specific characters, and the > forward slash is used under Cygwin, not the Windows backslash. Exactly, I haven't stated anything else > The bigger question would be how would you expect a Cygwin application to > even accept a Windows paths. It should use *nix paths, as all Cygwin > programs do Cygwin (and thus applications build within Cygwin) already do accept Windows paths here and there as well as std::filesystem Applications don't have control of all the input that could come from UI, environment, configuration, etc What I'm trying to make a point of is that wouldn't it be good if applications didn't have to care about that, because that is what libraries/frameworks are for, to give an abstraction ? Otherwise every application have to do something like where ever it handles some path #ifdef _CYGWIN_ // fix the path-representation to something with /cygdrive or such ... #endif This is what we're hoping to avoid to do and that it could be done in the library we're using The exact details of how to implement this and what challenges that would be is uninteresting before it could be settled as "Yeah, it would be a good feature to let std::filesystem to be path-style-agnostic" C++ applications do mostly use std::filesystem, std::ofstream, std::ifstream and do not mix that with Posix-file-mechanisms, but for Cygwin, /cygdrive/... in std::filesystem must of course be a valid path as well I can't stress this enough and point out that this community have already decided to here and there make Cygwin be Windows-style-paths-aware, so I cannot see that it would be that of a bad idea if it became even more agnostic to what kind of path is used, but of course I understand it comes
[PATCH] Use automake (v3)
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
v2:
* Include tzmap.h in BUILT_SOURCES
* Make per-file flags appear after user-supplied CXXFLAGS, so they can
override optimization level.
* Correct .o files used to define symbols exported by libm.a
* Drop gcrt0.o mistakenly incuded in libgmon.a
* Add missing line continuations in GMON_FILES value
v3:
* use per-file flags for .c compilation
* override C{XX,}FLAGS, as they are set on the command line by top-level make
---
winsup/Makefile.am | 19 +
winsup/Makefile.am.common | 15 +
winsup/Makefile.common | 51 --
winsup/autogen.sh | 1 +
winsup/configure.ac| 21 +-
winsup/cygserver/Makefile.am | 58 ++
winsup/cygwin/Makefile.am | 769 +
winsup/cygwin/config.h.in | 2 +-
winsup/doc/Makefile.am | 155 +
winsup/testsuite/Makefile.am | 64 ++
winsup/testsuite/config/default.exp| 4 +-
winsup/testsuite/cygrun/Makefile.am| 21 +
winsup/testsuite/winsup.api/winsup.exp | 6 +-
winsup/utils/Makefile.am | 81 +++
winsup/utils/mingw/Makefile.am | 50 ++
15 files changed, 1258 insertions(+), 59 deletions(-)
create mode 100644 winsup/Makefile.am
create mode 100644 winsup/Makefile.am.common
delete mode 100644 winsup/Makefile.common
create mode 100644 winsup/cygserver/Makefile.am
create mode 100644 winsup/cygwin/Makefile.am
create mode 100644 winsup/doc/Makefile.am
create mode 100644 winsup/testsuite/Makefile.am
create mode 100644 winsup/testsuite/cygrun/Makefile.am
create mode 100644 winsup/utils/Makefile.am
create mode 100644 winsup/utils/mingw/Makefile.am
diff --git a/winsup/Makefile.am b/winsup/Makefile.am
new file mode 100644
index 0..067f74688
--- /dev/null
+++ b/winsup/Makefile.am
@@ -0,0 +1,19 @@
+# Makefile.am for winsup stuff
+#
+# This file is part of Cygwin.
+#
+# This software is a copyrighted work licensed under the terms of the
+# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
+# details.
+
+# This makefile requires GNU make.
+
+cygdocdir = $(datarootdir)/doc/Cygwin
+
+cygdoc_DATA = \
+ CYGWIN_LICENSE \
+ COPYING
+
+SUBDIRS = cygwin cygserver doc utils testsuite
+
+cygserver utils testsuite: cygwin
diff --git a/winsup/Makefile.am.common b/winsup/Makefile.am.common
new file mode 100644
index 0..884194df2
--- /dev/null
+++ b/winsup/Makefile.am.common
@@ -0,0 +1,15 @@
+# Makefile.am.common - common definitions for the winsup directory
+#
+# This file is part of Cygwin.
+#
+# This software is a copyrighted work licensed under the terms of the
+# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
+# details.
+
+flags_common=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe
-fbuiltin -fmessage-length=0
+
+# compiler flags commonly used (but not for MinGW compilation, because they
+# include the Cygwin header paths via @INCLUDES@)
+
+cxxflags_common=$(INCLUDES) -fno-rtti -fno-exceptions -fno-use-cxa-atexit
$(flags_common)
+cflags_common=$(INCLUDES) $(flags_common)
diff --git a/winsup/Makefile.common b/winsup/Makefile.common
deleted file mode 100644
index 3141bd111..0
--- a/winsup/Makefile.common
+++ /dev/null
@@ -1,51 +0,0 @@
-# Makefile.common - common definitions for the winsup directory
-#
-# This file is part of Cygwin.
-#
-# This software is a copyrighted work licensed under the terms of the
-# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
-# details.
-
-define justdir
-$(patsubst %/,%,$(dir $1))
-endef
-
-define libname
-$(realpath $(shell ${CC} --print-file-name=$1 $2))
-endef
-
-export PATH:=${winsup_srcdir}:${PATH}
-
-# Allow CFLAGS=-O,-g to control CXXFLAGS too
-opt=$(filter -O%,${CFLAGS}) $(filter -g%,${CFLAGS})
-override CXXFLAGS:=${filter-out -g%,$(filter-out -O%,${CXXFLAGS})} ${opt}
-
-cflags_common:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe
-fbuiltin -fmessage-length=0
-COMPILE.cc=${CXX} ${INCLUDES} ${CXXFLAGS} -fno-rtti -fno-exceptions
-fno-use-cxa-atexit ${cflags_common}
-COMPILE.c=${CC} ${INCLUDES} ${CFLAGS} ${cflags_common}
-
-top_srcdir:=$(call justdir,${winsup_srcdir})
-top_builddir:=$(call justdir,${target_builddir})
-
-cygwin_build:=${target_builddir}/winsup/cygwin
-newlib_build:=${target_builddir}/newlib
-
-VPATH:=${srcdir}
-
-.SUFFIXES:
-.SUFFIXES: .c .cc .def .S .a .o .d .s .E
-
-%.o: %.cc
- $(strip ${COMPILE.cc} -c -o $@ $<)
-
-%.o: %.c
- $(strip ${COMPILE.c} -c -o $@ $<)
-
-%.E: %.cc
- $(strip ${COMPILE.cc} -E -dD -o $@ $<)
-
-%.E: %.c
- $(strip ${COMPILE.c} -E -dD -o $@ $<)
-
-%.o: %.S
- $(strip ${COMPILE.S} -c -o $@ $<)
diff --git a/winsup/autogen.sh b/winsup/autogen.sh
index 4a60ef39f..1db91add9 100755
--- a/winsup/autogen.sh
+++ b/winsup/autogen.sh
@@ -1,3 +1,4 @@
/usr/bin/aclocal --force
Re: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: all the std::filesystem implementations I've seen for Windows The implementation on top of Cygwin is not "for Windows", it's "for Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do. And that's where we keep talking at cross purposes. Best wishes - Eliot Moss -- 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
Can't start a cygwin terminal(mintty) as admin
>From some months, use of a terminal with cygwin is changing and changing but >for me with more and more difficult to use. Prior to 3.1 version of the cygwin package, I could use two kinds of terminals bash and mintty. I like the bash version because I can launch with it an admin session, simply in telling to shortcut "exec as admin". But with the pty support provided by the new cygwin package, the bash terminal behavior has changed, relatively to Ctrl-C support. I have a curses application to launch bash scripts applications through a MMI interface presenting several choices of them. Before 3.1, for mintty and bash terminals, on a ctrl-C, my application MMI and bash script were stopped cleanly. But now for a bash terminal, a Ctrl-C quits the curses application in leaving the shell script to continue in background. To day, I don't know how write one C application with ncurses being compatible with bash and mintty terminals as yesterday. QUESTION 1 : HOW TO NOW HANDLE CTRL-C in a multi threaded cygwin application regarless of terminal As I am obliged to use mintty, now I can't launch a mintty terminal session as admin, I don't understand why. QUESTION 2 : HOW TO LAUNCH A MINTTY SESSION AS ADMIN My questions with last package versions (or not) for cygwin and mintty. Thanks for your help -- 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: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
On 11/24/20 11:35 AM, sten.kristian.ivars...@gmail.com wrote: [snip] std::filesystem POSIX mode is common to all POSIX platforms where backslashes are NOT directory separators. How do you make them accept your demands? How are you going to force POSIX platforms allow Windows specific code? I've been trying to say over and over again that our code doesn't handle any Windows specific stuff and not anywhere have I claimed that anyone else need to handle Windows specific stuff either (except for the internals of Cygwin of which Windows specific logic is already present) I repeat; I don't expect any of the Cygwin-Posix-functions to accept any Windows-style-paths (though some of them, as I repeatedly have said, already does so) and I only expect that I can operate according to the C++-standard on an instantiated std::filesystem::path How do you expect std::filesystem to do that when Windows paths are not even accepted in API calls? Make it try to enter subdirectories every time std::filesystem is called? You refuse to understand that Cygwin is NOT Windows, it is a POSIX platform. Using Cygwin means complying with POSIX expectations and standards. I don't see how this conversation can continue if you still refuse to see Cygwin as something separate from Windows. Besides, you have already answered your question by ruling out MinGW, so Microsoft Visual Studio it is. I repeat (again); neither MinGW/MSVS is an option because we're trying to use Posix and C++ Just to be clear: - Our code DOESN'T handle Windows-style-paths explicitly in any way - We DON'T expect Cygwin-Posix-file-related-functions to accept Windows-style-paths - We WOULD like std::filesystem to work according to the C++ ISO standard Why would std::filesystem be an exception? How would it know if a backslash is part of a name and not a separator? How does it know when to apply exceptions? What about mixed paths? The C++ standard mentions separators, not specific characters, and the forward slash is used under Cygwin, not the Windows backslash. The bigger question would be how would you expect a Cygwin application to even accept a Windows paths. It should use *nix paths, as all Cygwin programs do. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature -- 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: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
[snip] > std::filesystem POSIX mode is common to all POSIX platforms where > backslashes are NOT directory separators. How do you make them accept your > demands? How are you going to force POSIX platforms allow Windows specific > code? I've been trying to say over and over again that our code doesn't handle any Windows specific stuff and not anywhere have I claimed that anyone else need to handle Windows specific stuff either (except for the internals of Cygwin of which Windows specific logic is already present) I repeat; I don't expect any of the Cygwin-Posix-functions to accept any Windows-style-paths (though some of them, as I repeatedly have said, already does so) and I only expect that I can operate according to the C++-standard on an instantiated std::filesystem::path > Make it try to enter subdirectories every time std::filesystem is > called? > > You refuse to understand that Cygwin is NOT Windows, it is a POSIX > platform. Using Cygwin means complying with POSIX expectations and > standards. > > I don't see how this conversation can continue if you still refuse to see > Cygwin as something separate from Windows. Besides, you have already > answered your question by ruling out MinGW, so Microsoft Visual Studio it > is. I repeat (again); neither MinGW/MSVS is an option because we're trying to use Posix and C++ Just to be clear: - Our code DOESN'T handle Windows-style-paths explicitly in any way - We DON'T expect Cygwin-Posix-file-related-functions to accept Windows-style-paths - We WOULD like std::filesystem to work according to the C++ ISO standard Does that make any sense ? Kristian -- 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: [PATCH 0/2] winsup/doc/: add proc(5) man page
On Nov 23 15:10, Brian Inglis wrote: > Hacked a Cygwin proc.5 man page, by combing through fhandler_proc..., > converted to proc-5.xml using doclifter, included after pathnames-proc > before pathnames-proc-registry sections in specialnames.xml, and > modified to match and create a refentry to generate proc(5) man page. > > One of the issues with the xml input is that formatting wide screen > displays as if at .in 0 appears to be impossible, or at least not in > evidence in any of the other inputs or outputs, which don't include such > heavily indented lists of lists, and ending and restarting heavy > indenting context appears ugly. > > Brian Inglis (2): > specialnames.xml: add proc(5) Cygwin man page > winsup/doc/Makefile.in: create man5 dir and install generated proc.5 > > winsup/doc/Makefile.in |4 + > winsup/doc/specialnames.xml | 2100 +++ > 2 files changed, 2104 insertions(+) > > -- > 2.29.2 LGTM. Jon, can you take a look, too, please? Thanks, Corinna
Re: [ITA] wxWidgets3.0
Ignore that message, I made a silly mistake. On 24/11/2020 10:15, Hamish McIntyre-Bhatty via Cygwin-apps wrote: > Well, something's gone wrong with my Cygwin install I think, because > even with previously working cygport recipes, I can no longer produce a > working build. > > The samples tend to either exit immediately or segfault, and trying to > use wxPython yields: > > " > > Traceback (most recent call last): > > File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main > > "__main__", mod_spec) > > File "/usr/lib/python3.6/runpy.py", line 85, in _run_code > > exec(code, run_globals) > > File "./demo/__main__.py", line 5, in > > import Main > > File "./demo/Main.py", line 61, in > > import wx > > File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in > > > from wx.core import * > > File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in > > from ._core import * > > ImportError: No such process > > > " > > I did try a rebase as well, but it doesn't seem to help. This looks like > an issue I had right when I first tried to compile wxPython, and it > mysteriously went away at some point. Does anyone know why this might be > happening? Maybe I need to reinstall Cygwin, but I haven't done anything > with it between the successful build of wxWidgets and the failed ones, > so it's not making a whole lot of sense. > > Hamish > 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
On 11/24/20 9:32 AM, sten.kristian.ivars...@gmail.com wrote: That's not what Cygwin is for, you ignore everything while conveniently claiming to be looking for "insightful thoughts". You still haven't answered where is it in the POSIX standard requires backslashes to be used as separator or how are you going to make other *nix platforms accept such a change? Did I get a question about where I think that POSIX requires backslashes or did I make such claim ? If one of them, I have missed that question and I have certainly not made any such claim All I'm saying is that I'd like std::filesystem in Cygwin to work properly and I still cannot see why that cannot happen ? What would the drawbacks be if std::filesystem worked more transparent (i.e. correct) and made Cygwin more useful ? I don't think the community would shrink ! There's that proverbial wider audience nonsense. "Sure is nice if Cygwin emulates NTVDM too, I don't the community would shrink!" You wanted to make std::filesystem accept backslashes as separators, this is NOT POSIX compliant, it is contrary to the goal of Cygwin. std::filesystem POSIX mode is common to all POSIX platforms where backslashes are NOT directory separators. How do you make them accept your demands? How are you going to force POSIX platforms allow Windows specific code? Make it try to enter subdirectories every time std::filesystem is called? You refuse to understand that Cygwin is NOT Windows, it is a POSIX platform. Using Cygwin means complying with POSIX expectations and standards. I don't see how this conversation can continue if you still refuse to see Cygwin as something separate from Windows. Besides, you have already answered your question by ruling out MinGW, so Microsoft Visual Studio it is. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature -- 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: [ITA] wxWidgets3.0
Well, something's gone wrong with my Cygwin install I think, because even with previously working cygport recipes, I can no longer produce a working build. The samples tend to either exit immediately or segfault, and trying to use wxPython yields: " Traceback (most recent call last): File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "./demo/__main__.py", line 5, in import Main File "./demo/Main.py", line 61, in import wx File "/usr/lib/python3.6/site-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib/python3.6/site-packages/wx/core.py", line 12, in from ._core import * ImportError: No such process " I did try a rebase as well, but it doesn't seem to help. This looks like an issue I had right when I first tried to compile wxPython, and it mysteriously went away at some point. Does anyone know why this might be happening? Maybe I need to reinstall Cygwin, but I haven't done anything with it between the successful build of wxWidgets and the failed ones, so it's not making a whole lot of sense. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Sv: Sv: Sv: Sv: g++ and c++17 filesystem
> On 11/23/20 8:35 AM, sten.kristian.ivars...@gmail.com wrote: > >> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote: > 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 > >>> > >>> All the implementations of std::filesystem I've seen so far, is > >>> agnostic to whether / or \ is used as a path separator (but the > >>> generic form is '/' and a fun fact, the MSVC-implementation of > >>> std::filesystem handles the generic > >>> (posix) form more close to the standard specification than GCC) > >>> > >> > >> That is not correct, \ is a valid filename under *nix, but not on > Windows. > >> I don't think the standards specify what filenames or character sets > >> are valid. Cygwin strives for *nix compatibility, anything else is > secondary. > > > > > > I should have made my point clear; "All the implementations of > std::filesystem for Windows ..." > > > > > > That is an incorrect understanding, Cygwin is NOT Windows, it is its own > platform, you should not consider it even Windows unless you are working > on Cygwin internals. I beg to differ. My claim was that all the std::filesystem implementations I've seen for Windows, except Cygwin, handles both '\' and '/' and that was my point (Cygwin handles it in some circumstances) so that point is perfectly valid I'm not considering either '/' or '\' in the code. I'm working with a path. I don't care what kind of separators the path handled to the application have. I want std::filesystem to work properly even if the folder-separator in current platform is ¤#¤#¤#¤ > 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 consider that to be a mistake in the implementation of > >>> std::filesystem, because on Windows the preferred style would be smt > >>> like C:/ and then as an opt-out it would consider /cygdrive/c (or > >>> such) as a valid thing as well > >>> > >> > >> Cygwin is not Windows, it runs on Windows, but it is not Windows. You > >> should use mingw if you want Windows style paths. There isn't a > >> magical tool that allows you to have it both ways. > > > > As I'm trying to say, Cygwin already accepts Windows-style-paths in some > circumstances and thus it have SOME magic, so why not extend that and thus > make it easier to use Cygwin on its target platform, i.e. Windows ? > > > > Because libstdc++ is not part of Cygwin, it is part of the GCC project, > developed by completely different developers. GCC runs on Cygwin, so it is > expected to use standard *nix API, not windows. Windows path conversions > are entirely unreliable, see the mess that is MSYS, when Windows and *nix > paths collide. I think you have misunderstood my point completely. I know that they are unreliable and that's what I'm trying to have a discussion about, because I cannot see why it has to be unreliable and how it not could be fixed > > As I've said, to use MinGW along with Cygwin would be very tricky > > without bumping into ODR/memory issues > > > > I don't think MinGW alone give us enough support alone to keep our > > code base non platform specific (*nix+windows) > > > > > > If you are on Cygwin, use *nix APIs and paths, that's the end to it. You > should not mix Cygwin compiled code with MinGW. About the code, that's exactly as I stated > >> > >> Yes, cross platform, you can use std::filesystem on Linux, Cygwin, > >> Windows, Macs, but it certainly cannot do anything that can't be > >> handled for the underlying platform. For Cygwin, it means using *nix > >> paths, not Windows. > > > > Exactly, so why obfuscate the underlaying platform with a Posix-layer > that also can do exactly just what the underlaying platform can and then > back to some standard interface again (i.e. std::filesystem) which make a > roundtrip that only can result in loss of information/functionality ? > > > > Because Cygwin is exactly that, to emulate POSIX layer on Windows, if > POSIX mandates exposing Windows paths, then you would see Cygwin reworked > to support it. > > > I rather have a dialogue of how that that could be done rather than > "Cygwin is *nix, deal with it" or at least it would be nice to hear if > someone do have some insightful thoughts of why it must the way it is or > why it would be so hard to make parts (e.g. std::filesystem) more useful ? > > > > > > That's not what Cygwin is for, you ignore everything while conveniently > claiming to be looking for "insightful thoughts". You still haven't > answered where is it in the POSIX standard requires backslashes to be used > as separator or how are you going to make other *nix platforms
S.E.O. for cygwin.com
Dear cygwin.com Team, I went to your Site cygwin.com and wanted to shoot you a quick note. If you want I can make a few changes (aesthetically and/or SEO-wise) to make your site convert more visitors into leads and to get it placed higher in the organic search for a few of the select terms. This is NOT like one of those foreign emails you probably get in your inbox every day. Just to be upfront we have 50+ agents that work for development /SEO. I would just need to know which (if not both) services you're open to checking out information about, either web design or SEO. Would you be open to seeing more brief info / quote for what I would like to accomplish? Internet Marketing Experts - We know how to make Google Happy. If you are not on Google page 1, your website is a waste. Getting your site on Google 1st page GUARANTEED. All the techniques used are ethical and proprietary. Please reply back to get the *Website Audit Report* we have done. Best Regards, Shane Bell : DM Expert Caution: This is our marketing strategy that we use the Gmail. If you want to receive detailed plan of action, please feel free to reply Yes, We will get back to you with Details. [image: beacon] -- 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
