Re: 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 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. 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. 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 accept such a change? -- 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
Please add ftnchek package
Hi Cygwin, Ftnchek is very useful for updating "dusty-deck" fortran codes Some links to streamline your consideration. Thank you https://www.dsm.fordham.edu/~ftnchek/ https://linux.die.net/man/1/ftnchek https://sourceforge.net/projects/ftnchek/ http://www.softeng.rl.ac.uk/st/archive/SoftEng/SESP/html/SoftwareTools/ftnch ek.html -- 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 ftnchek package
On Mon, 23 Nov 2020 at 13:02, robhickey wrote: > Ftnchek is very useful for updating "dusty-deck" fortran codes > > Some links to streamline your consideration. Hi Rob, Are you proposing to maintain this package for Cygwin yourself? If so, the process is covered at https://cygwin.com/packaging-contributors-guide.html#submitting If you're not proposing to maintain the package yourself then, as with all open source projects, we have the issue that someone has to do it, and clearly nobody thus far has been sufficiently motivated to do the work themselves until now. Sometimes this sort of request will be sufficient for a volunteer to step forwards, but the best way to get something done is often to do it yourself… -- 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
Added to Mirror
Hi, Can you add our server to mirror list. Europe: France: mirrors.filigrane-technologie.fr(https) Cordialement, Geoffroy Van Elsuve 114, boulevard Haussmann 75008 Paris Tél:06 60 69 72 32 Penser à l'environnement avant d'imprimer ce document. -- 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
[ANNOUNCEMENT] Updated: units 2.21
The following package has been upgraded in the Cygwin distribution: * units 2.21 The Units program converts quantities expressed in various scales to to their equivalents in other scales. The units program can handle multiplicative scale changes as well as nonlinear conversions such as Fahrenheit to Celsius or wire gauge. Units comes with an annotated, extendable database defining over three and a half thousand units using ten systems of units including SI, 170 currencies, plus bitcoin and precious metals prices, which may be updated daily using the units_cur script. HTML (single and multi-page), Info, man, PDF, and txt format docs are all now included. GNU units NEWS - User visible changes. Version 2.21 - 12 November 2020 (bug fix release) * Fixed bug arising when $HOME or other environment variables are undefined, which primarily affects the Windows version * Improved error reporting when input files are missing or invalid -- 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 15:41, tealhill via Cygwin wrote: ### Summary Why should Cygwin add Sysnative to $PATH? As a workaround for Microsoft's failure to add Sysnative to %PATH%. ### 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. Adding sysnative, **incorrectly** would add 64-bit applications to a 32-bit path. You are asking a non-windows environment, Cygwin, that in order to be POSIX compatible, it should add a windows path? Name ONE other unix or posix platform that does this by default. -- 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
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. -- 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
