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::pathHow 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 standardWhy 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 doCygwin (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 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
The C++ standard library APIs are wrappers around the Cygwin APIs like open(3) and write(3), so a Windows path there would still fail. Just because it comes from the C++ standard library, doesn't mean its magically separated from the underlying system.
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
No, Windows paths are not supported, merely working as a side effect. Are you going to demand POSIX compliant scripts to also handle Windows paths next?
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
But Cygwin is NOT Windows, you still refuse to accept this fact. Cygwin programs have no reason to act as Windows applications, Cygwin programs act like Cygwin programs.
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
