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
