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 variableAll 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 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.
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.As stated earlier, we're using Cygwin to be able to keep some kind of cross platform code base and Cygwin offers non-cross-platform-standardized libraries/api:s (i.e. posix) to be executable without having to #ifdef the code base to be buildable and executable on Windows but MinGW doesn't supply those posix libraries on Windows (maybe a few), so using GCC/MinGW is not an option and I guess we'd go with MSVC if we wanted to port our code completely
If you use Cygwin, you are expected to use *nix paths, not Windows paths. Windows paths may work but are not supported overall, as Windows is not POSIX. If you want Windows, then use mingw or MSVC. Since you mentioned it is not possible to use mingw, then that will leave you with only MSVC, your only possible choice is now clear.
std::filesystem is supposed to be cross-platform (and easier to use than various posix-library-C-functions) though and it is cross-platform per definition but, then again, not when using Cygwin
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.
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
