> > [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 with some challenges p.s. We do have an open source product targeting the *nix-world as well and at the same time we're trying to make it runnable on Windows, so this is not just me be being stubborn d.s 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
