> >>> all the std::filesystem implementations I've seen for Windows
> >>
> >> The implementation on top of Cygwin is not "for Windows", it's "for
> >> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to
> do.
> >> And that's where we keep talking at cross purposes.
>
> > Maybe
Thanx for the insightful thoughts Ken
See more below
> >>> all the std::filesystem implementations I've seen for Windows
> >>
> >> The implementation on top of Cygwin is not "for Windows", it's "for
> >> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to
> do.
> >> And that's
> For the specific case C:\Temp, I found this:
>
> cygpath -ua 'C:\Temp'
>
>-> /cygdrive/c/Temp
>
> cygpath -ua /cygdrive/c/Temp
>
>-> /cygdrive/c/Temp
>
> cygpath -ua '\Temp'
>
>-> /cygdrive/c/Temp
>
> cygpath -ua '/Temp'
>
>-> /Temp
>
> Now Cygwin is open source, so you,
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?
On 2020-11-24 07:31, Kristian Ivarsson via Cygwin wrote:
On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
all the std::filesystem implementations I've seen for Windows
The implementation on top of Cygwin is not "for Windows", it's "for
Cygwin", i.e., "for Posix". And for Cygwin
For the specific case C:\Temp, I found this:
cygpath -ua 'C:\Temp'
-> /cygdrive/c/Temp
cygpath -ua /cygdrive/c/Temp
-> /cygdrive/c/Temp
cygpath -ua '\Temp'
-> /cygdrive/c/Temp
cygpath -ua '/Temp'
-> /Temp
Now Cygwin is open source, so you, too, could grab the code in cygpath and
On 11/24/2020 9:31 AM, Kristian Ivarsson via Cygwin wrote:
On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
all the std::filesystem implementations I've seen for Windows
The implementation on top of Cygwin is not "for Windows", it's "for
Cygwin", i.e., "for Posix". And for Cygwin
> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
>
> > all the std::filesystem implementations I've seen for Windows
>
> The implementation on top of Cygwin is not "for Windows", it's "for
> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do.
> And that's where
> > [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
On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
all the std::filesystem implementations I've seen for Windows
The implementation on top of Cygwin is not "for Windows", it's "for Cygwin", i.e., "for Posix". And
for Cygwin that's the right thing to do. And that's where we keep
On 11/24/20 11:35 AM, 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?
[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
On 11/24/20 9:32 AM, sten.kristian.ivars...@gmail.com wrote:
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
> 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
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,
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
[snip]
> > Applications might wanna extract type, name, parent-folder, etc but do
> > rarely care about what kind of separator it has (/ or \) and the style
> > of the root directory etc and it would be very neat if the cygwin
> > std::filesystem-library became more agnostic in these regards
>
On 2020-11-20 02:37, Kristian Ivarsson via Cygwin wrote:
[snip]
As stated earlier, it seems like using mingw g++/libstdc++ (from the
cygwin-package-manager) it seems like it works better, but then you
can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
without breaking ODR (and
[snip]
> >> As stated earlier, it seems like using mingw g++/libstdc++ (from the
> >> cygwin-package-manager) it seems like it works better, but then you
> >> can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
> >> without breaking ODR (and probably some memory models etc as well)
> Ok, first, I admit that I was not familiar with the details of
> std::filesystem. However, after looking at it, I remain unsurprised that
> the Cygwin and Mingw versions might be different. (I would also not be
> surprised if there is a real bug in there.)
At least semantic bugs considering
Ok, first, I admit that I was not familiar with the details of std::filesystem. However, after
looking at it, I remain unsurprised that the Cygwin and Mingw versions might be different. (I would
also not be surprised if there is a real bug in there.) The behavior I would _expect_ is that the
On 2020-11-19 03:03, Kristian Ivarsson via Cygwin wrote:
18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin :
On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
The filesystem-library as a part of C++17 seems to have some
> > 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin :
> >
> > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
> >
> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
> >>>
> The filesystem-library as a part of C++17 seems to have some
> defects and flaws in
> >> I would agree that if you want an executable that acts and feels more
> like a Windows native application, then mingw is probably what you want.
> Cygwin is if you want something that acts and feels more like a Posix
> thing ... which means it will be oriented to Posix style paths.
> > To be
On 2020-11-18 17:08, Doug Henderson via Cygwin wrote:
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson wrote:
The only purpose CYGWIN have is to make/build posix-applications runnable
on Windows and applications usually have user defined input, such as paths
etc, and on Windows that input is
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson via Cygwin
wrote:
>
>
> The only purpose CYGWIN have is to make/build posix-applications runnable on
> Windows and applications usually have user defined input, such as paths etc,
> and on Windows that input is usually Windows-native-paths unless
On 11/18/2020 4:18 PM, Kristian Ivarsson wrote:
I would agree that if you want an executable that acts and feels more like a
Windows native application, then mingw is probably what you want. Cygwin is if
you want something that acts and feels more like a Posix thing ... which means
it
On 11/18/2020 3:46 PM, Kristian Ivarsson via Cygwin wrote:
Is there any other use cases for CYGWIN than to build applications running in
Windows ? Do people use CYGWIN (shell) to operate or monitor their applications
? For all other use cases than the development (the shell) I cannot see why
> I would agree that if you want an executable that acts and feels more like a
> Windows native application, then mingw is probably what you want. Cygwin is
> if you want something that acts and feels more like a Posix thing ... which
> means it will be oriented to Posix style paths.
To be
I would agree that if you want an executable that acts and feels more like a Windows native
application, then mingw is probably what you want. Cygwin is if you want something that acts and
feels more like a Posix thing ... which means it will be oriented to Posix style paths.
EM
--
Problem
> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin :
>
> On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
>
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
>>>
The filesystem-library as a part of C++17 seems to have some defects
and flaws in the
On 11/18/2020 11:24 AM, René Berber via Cygwin wrote:
Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.
End of story.
And I'll add, this is by design: Cygwin's goal is to provide a programming (and command line)
environment as much like Posix
On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
The filesystem-library as a part of C++17 seems to have some defects
and flaws in the cygwin-package and pretty much every lexical- and
canonical operation works in mysterious
> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
>
> > The filesystem-library as a part of C++17 seems to have some defects
> > and flaws in the cygwin-package and pretty much every lexical- and
> > canonical operation works in mysterious ways (or not at all)
> [snip]
>
>
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)
[snip]
Hi folks
The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)
Following output with g++cygwin
$ uname -a
CYGWIN_NT-10.0 JOKK 3.1.7(0.340/5/3)
36 matches
Mail list logo
