> 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 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 ! 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
