cygwin@cygwin.com
On 2020-11-25 16:13, Stephen Carrier wrote:
From an e-mail reply that was not posted to the list:
On Wed, Nov 18, 2020 at 04:04:40PM -0700, Keith Christian wrote:
On Mon, Nov 16, 2020 at 1:49 PM Stephen Carrier wrote:
On Mon, Nov 16, 2020 at 12:44:33PM -0800, Stephen Carrier wrote:
On Sun, Nov 15, 2020 at 02:03:28PM -0700, Keith Christian via Cygwin wrote:
Cygwin people,
Running with this version of Cygwin.
CYGWIN_NT-10.0 DESKTOP-ASERVER 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
Windows info:
$ /lib/csih/winProductName.exeMicrosoft Windows 10 Professional,
64-bit (build 18363)
I installed using cron-config, and created the cyg_server user.cron
starts OK, but does not appear to execute the crontabs.
No messages or errors in /var/log/cron.log.
$ cygrunsrv -Q cron
Service : cron
Display name: Cron daemon
Current State : Running
Controls Accepted : Stop
Command : /usr/sbin/cron -n
What's the output of "cygrunsrv -V -Q cron"?
What are the file permissions on /var/log/cron.log? ("ls -l
/var/log/cron.log"). The uid running cron needs write permission there.
I run cron from the Local System account, which can setuid to other users.
I don't know the circumstances where one should still use a non-SYSTEM
account with Windows 10, but they aren't mine and I recommend running
as SYSTEM if possible.
Stephen
I have also found the output of "cronevents" helpful.
Stephen,
Thanks very much for the reply.
The README file may be accurate, but mentions adding users to
/etc/passwd, which we left behind a long time ago.
$ ls -l /usr/share/doc/Cygwin/cron-4.1-65.README
-rwxr-xr-x 1 keith keith 5304 Feb 15 2010
/usr/share/doc/Cygwin/cron-4.1-65.README
Here is the diagnostic output;
$ cygrunsrv -V -Q cron
Service : cron
Display name: Cron daemon
Current State : Running
Controls Accepted : Stop
Command : /usr/sbin/cron -n
stdin path : /dev/null
stdout path : /var/log/cron.log
stderr path : /var/log/cron.log
Environment : CYGWIN=" " TMP="/tmp" TEMP="/tmp"
Process Type: Own Process
Startup : Automatic
Account : .\cyg_server
This looks OK and verfies that the service is running under 'cyg_server'
which is not the Local System account. As I would have expected from
your description.
$ ls -l /var/log/cron.log
-rw-r--r-- 1 cyg_server None 0 Nov 15 11:11 /var/log/cron.log
Nothing has been logged, but the service should be able to log here if
it has anything to say, since cyg_server has write-permission.
$ cronevents | grep error | tail
2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10382:
(CRON) error (can't switch user context)
2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10384:
(CRON) error (can't switch user context)
2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10387:
(CRON) error (can't switch user context)
2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10388:
(CRON) error (can't switch user context)
"Can't switch user context" means cyg_server can't change its user id.
This is exactly what I suspected. The service would try to change
user id to the user that submitted the cron job so it can run with the
privileges of that user.
(simplifying a bit) In UNIX the user that can change to another uid
is root. For windows the SYSTEM user has that ability so running
services as the SYSTEM user is the easiest thing to do for a service
(like cron or sshd) that needs to change uid.
For ancient versions of Windows this was not the case and it was necessary
to create a special user to own the service, then grant that special
user special privileges. The setup script supports that and takes care
of the details.
My best recollection is that the setup script will ask if you want to
create the special user, and if you decline, the script will run the
service as SYSTEM user. So what I suggest you try is to uninstall cron,
and install it again without creating a special account. See if that
works better.
I ask the community at large if the cron configuration script should
detect whether the SYSTEM user will work and then just set it up that way.
I think trouble is caused by asking users to decide questions if they
don't understand the implications of the answer.
Alternatively, the script could explain that SYSTEM is preferable if
it will work, along with a brief description of when choosing a special
user is desirable.
I'll wait for your reply before reconfiguring CRON.
Please don't put me in that position. I have benefitted from the help of
others on this list many times, so I try to helpful when I'm in position
to do so. I was not and am not the only person who can help you here,
You might have had a reply sooner if
cygwin@cygwin.com
>From an e-mail reply that was not posted to the list:
On Wed, Nov 18, 2020 at 04:04:40PM -0700, Keith Christian wrote:
> On Mon, Nov 16, 2020 at 1:49 PM Stephen Carrier wrote:
> >
> > On Mon, Nov 16, 2020 at 12:44:33PM -0800, Stephen Carrier wrote:
> > > On Sun, Nov 15, 2020 at 02:03:28PM -0700, Keith Christian via Cygwin
> > > wrote:
> > > > Cygwin people,
> > > >
> > > > Running with this version of Cygwin.
> > > > CYGWIN_NT-10.0 DESKTOP-ASERVER 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
> > > > Cygwin
> > > >
> > > > Windows info:
> > > > $ /lib/csih/winProductName.exeMicrosoft Windows 10 Professional,
> > > > 64-bit (build 18363)
> > > >
> > > > I installed using cron-config, and created the cyg_server user.cron
> > > > starts OK, but does not appear to execute the crontabs.
> > > > No messages or errors in /var/log/cron.log.
> > > >
> > > > $ cygrunsrv -Q cron
> > > > Service : cron
> > > > Display name: Cron daemon
> > > > Current State : Running
> > > > Controls Accepted : Stop
> > > > Command : /usr/sbin/cron -n
> > >
> > > What's the output of "cygrunsrv -V -Q cron"?
> > >
> > > What are the file permissions on /var/log/cron.log? ("ls -l
> > > /var/log/cron.log"). The uid running cron needs write permission there.
> > >
> > > I run cron from the Local System account, which can setuid to other users.
> > > I don't know the circumstances where one should still use a non-SYSTEM
> > > account with Windows 10, but they aren't mine and I recommend running
> > > as SYSTEM if possible.
> > >
> > > Stephen
> >
> > I have also found the output of "cronevents" helpful.
>
> Stephen,
>
> Thanks very much for the reply.
>
> The README file may be accurate, but mentions adding users to
> /etc/passwd, which we left behind a long time ago.
>
> $ ls -l /usr/share/doc/Cygwin/cron-4.1-65.README
> -rwxr-xr-x 1 keith keith 5304 Feb 15 2010
> /usr/share/doc/Cygwin/cron-4.1-65.README
>
> Here is the diagnostic output;
>
> $ cygrunsrv -V -Q cron
> Service : cron
> Display name: Cron daemon
> Current State : Running
> Controls Accepted : Stop
> Command : /usr/sbin/cron -n
> stdin path : /dev/null
> stdout path : /var/log/cron.log
> stderr path : /var/log/cron.log
> Environment : CYGWIN=" " TMP="/tmp" TEMP="/tmp"
> Process Type: Own Process
> Startup : Automatic
> Account : .\cyg_server
This looks OK and verfies that the service is running under 'cyg_server'
which is not the Local System account. As I would have expected from
your description.
> $ ls -l /var/log/cron.log
> -rw-r--r-- 1 cyg_server None 0 Nov 15 11:11 /var/log/cron.log
Nothing has been logged, but the service should be able to log here if
it has anything to say, since cyg_server has write-permission.
> $ cronevents | grep error | tail
> 2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10382:
> (CRON) error (can't switch user context)
> 2020/11/18 15:50:01 [cyg_server] /usr/sbin/cron: PID 10384:
> (CRON) error (can't switch user context)
> 2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10387:
> (CRON) error (can't switch user context)
> 2020/11/18 15:51:02 [cyg_server] /usr/sbin/cron: PID 10388:
> (CRON) error (can't switch user context)
"Can't switch user context" means cyg_server can't change its user id.
This is exactly what I suspected. The service would try to change
user id to the user that submitted the cron job so it can run with the
privileges of that user.
(simplifying a bit) In UNIX the user that can change to another uid
is root. For windows the SYSTEM user has that ability so running
services as the SYSTEM user is the easiest thing to do for a service
(like cron or sshd) that needs to change uid.
For ancient versions of Windows this was not the case and it was necessary
to create a special user to own the service, then grant that special
user special privileges. The setup script supports that and takes care
of the details.
My best recollection is that the setup script will ask if you want to
create the special user, and if you decline, the script will run the
service as SYSTEM user. So what I suggest you try is to uninstall cron,
and install it again without creating a special account. See if that
works better.
I ask the community at large if the cron configuration script should
detect whether the SYSTEM user will work and then just set it up that way.
I think trouble is caused by asking users to decide questions if they
don't understand the implications of the answer.
Alternatively, the script could explain that SYSTEM is preferable if
it will work, along with a brief description of when choosing a special
user is desirable.
> I'll wait for your reply before reconfiguring CRON.
Pleas
Re: Unix Domain Socket Limitation?
On 11/25/2020 4:47 PM, Norton Allen wrote: In my recent tests, it appears as though it is not possible to successfully connect via two Unix Domain sockets from one client application to one server application. Specifically, if I create a server which listens on a Unix Domain socket and a client, which attempts to connect() twice, both seem to lock up. This is not the behavior under Linux. I will be happy to work up a minimal example if it is helpful in tracking this down. I wanted to start by asking whether this is a known limitation and/or if there is something about the Cygwin implementation that makes this sort of thing very difficult. A minimal example would be extremely helpful. Corinna can answer questions about limitations in the current implementation. But there is a new implementation under development. It's in the topic/af_unix branch of the Cygwin git repository if you're interested in looking at it. Corinna began working on this a couple years ago, and I've recently been trying to finish it. I've made quite a bit of progress, but there's still more to do and undoubtedly many bugs. So any test cases you have would be very useful. Ken -- 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
Unix Domain Socket Limitation?
In my recent tests, it appears as though it is not possible to successfully connect via two Unix Domain sockets from one client application to one server application. Specifically, if I create a server which listens on a Unix Domain socket and a client, which attempts to connect() twice, both seem to lock up. This is not the behavior under Linux. I will be happy to work up a minimal example if it is helpful in tracking this down. I wanted to start by asking whether this is a known limitation and/or if there is something about the Cygwin implementation that makes this sort of thing very difficult. -- 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
Re: Cygwin mount option -s is not supported
On 2020-11-25 11:26, Vlado via Cygwin wrote:
On 25.11.2020 15:18, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
Mount -s was removed in 2008:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=5f853b3fc5277da8cb5ba3ac7406447fe82e65de
three months after it was set to be ignored.
if [ -n "`uname -s |grep -i cygwin_`" ]; then
# If we are on an new version of Cygnus we need to turn :/ in
# the path to/cygdrive//
Use of 'Cygnus' refers to 20+ years ago when Cygwin was a product.
CYGDRIVE=`mount -p | tail -1 | awk '{print $1}' | sed -e 's%/$%%'`
WL_HOME_CYGWIN=`echo $WL_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
ANT_HOME_CYGWIN=`echo $ANT_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
PATCH_PATH_CYGWIN=`echo $PATCH_PATH | sed
"s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JAVA_HOME_CYGWIN=`echo $JAVA_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JRE_HOME_CYGWIN=`echo $JRE_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
Hard to say why Oracle's script is written this way. Standard Cygwin tool for
file names conversion is cygpath. Instead of using sed, one can write
WL_HOME_CYGWIN=`cygpath -u $WL_HOME`
- simpler and the result will be more consistent. Example
$ WL_HOME='C:\some\dir\subdir' # Windows path
$ echo "$WL_HOME" | sed "s#\([a-zA-Z]\):#/cygdrive/c/\1#g"
/cygdrive/c/C\some\dir\subdir # mixed forward and back slashes
$ cygpath -u "$WL_HOME"
/cygdrive/c/some/dir/subdir # pretty Cygwin path
Especially note the cygpath -U -> /proc/cygdrive/, -a -> /..., and -p path
conversion options should be used as appropriate: try all three!
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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
Re: Cygwin mount option -s is not supported
On 25.11.2020 15:18, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
-
if [ -n "`uname -s |grep -i cygwin_`" ]; then
# If we are on an new version of Cygnus we need to turn :/ in
# the path to/cygdrive//
CYGDRIVE=`mount -p | tail -1 | awk '{print $1}' | sed -e 's%/$%%'`
WL_HOME_CYGWIN=`echo $WL_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
ANT_HOME_CYGWIN=`echo $ANT_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
PATCH_PATH_CYGWIN=`echo $PATCH_PATH | sed
"s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JAVA_HOME_CYGWIN=`echo $JAVA_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JRE_HOME_CYGWIN=`echo $JRE_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
Hi.
Hard to say why Oracle's script is written this way. Standard Cygwin
tool for file names conversion is cygpath. Instead of using sed, one can
write
WL_HOME_CYGWIN=`cygpath -u $WL_HOME`
- simpler and the result will be more consistent. Example
$ WL_HOME='C:\some\dir\subdir' # Windows path
$ echo "$WL_HOME" | sed "s#\([a-zA-Z]\):#/cygdrive/c/\1#g"
/cygdrive/c/C\some\dir\subdir # mixed forward and back slashes
$ cygpath -u "$WL_HOME"
/cygdrive/c/some/dir/subdir # pretty Cygwin path
Vlado
--
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
Cygwin mount option -s is not supported
Hello,
I am trying to make "config.sh" of Weblogic 12c Release 2 (v12.2.1.4.201001)
working under Cygwin. After having fixed with dos2unix all the broken shell
scripts that were full of MS-DOS CRLF, my attempt to create a Weblogic domain
has failed again by running:
-
$ ./oracle_common/common/bin/config.sh
mount: unknown option -- s
Try `mount --help' for more information.
Error: Could not find or load main class com.oracle.cie.wizard.WizardController
-
The problem is located in the following script:
oracle_common/common/bin/commBaseEnv.sh:
-
if [ -n "`uname -s |grep -i cygwin_`" ]; then
# If we are on an new version of Cygnus we need to turn :/ in
# the path to /cygdrive//
CYGDRIVE=`mount -p | tail -1 | awk '{print $1}' | sed -e 's%/$%%'`
WL_HOME_CYGWIN=`echo $WL_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
ANT_HOME_CYGWIN=`echo $ANT_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
PATCH_PATH_CYGWIN=`echo $PATCH_PATH | sed
"s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JAVA_HOME_CYGWIN=`echo $JAVA_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
JRE_HOME_CYGWIN=`echo $JRE_HOME | sed "s#\([a-zA-Z]\):#${CYGDRIVE}/\1#g"`
-
>From Linux mount:
-
-s Tolerate sloppy mount options rather than failing. This will ignore
mount options not supported by a filesystem type. Not all filesystems support
this option. This option exists for support of the Linux autofs-based
automounter.
-
But it seems that the "mount" command of Cygwin does not support that option.
Was that option ever supported in previous versions? Is it going to be
supported? Do they know something more in Oracle that have used it in their
scripts?
I know that this is not an issue of Cygwin and it should be reported to Oracle
support. I just want to check all the necessary information first. I think it
was working in the past (previous versions of Weblogic and/or Cygwin). The
mystery must be resolved.
Panos Kavalagios
Application Architect
CONSULIAT (under contract with the EEAS)
BA.BS.3.IS
_
Office: EEAS B100 Floor 5 Area 048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017
--
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
Sv: g++ and c++17 filesystem
> >>> 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 it is the right thing to do, but what is your take of why it > > must be so (all the way) ? > > Nobody is interested in doing the work to submit and modify patches to get > them accepted and change it from the way it is. I totally understand that it might be a big task, but (as I said) I cannot understand the reluctancy of even wanting the feature (as far as I experience;-) One might ask what the use case for Cygwin is ? We don't need to go into this rabbit hole though ;-) See more below > > I also do understand that it have several advantages in the > > implementation of std::filesystem but it also imply an extra layer of > > abstraction to the underlaying platform, but to just remove the > > _CYGWIN_ macro when building it would make std::filesystem to not > > understand /cygdrive at all (and I guess that would confuse other > > users;-) so I guess it would require some more sophisticated > > implementation (or extend the number of exceptions already existing in > > the underlaying Cygwin-Posix-implementation) > If you only use POSIX compliant Cygwin or UNC (//) paths, all your > programs built under Cygwin should run successfully under Windows or Wine. > Otherwise if you built under Cygwin, you can overload your directory and > file path methods so if a path contains : or \\ you call > cygwin_conv_path() with appropriate flags to fix your path before using > it Thanx for the tip, maybe I'll look into that, but I guess we need to have our own distro of Cygwin then (or could this be set for changing the behaviour for own built applications) ? > Or build with Mingw or MSVC++ and use whatever those allow. > > Cygwin is an open source project maintained solely by volunteer > contributors in their spare time, and its focus is on working around > Windows limitations to provide a POSIX standard environment and > experience, supporting more POSIX features as Windows limitations are > removed. I'm aware of that and I'm asking these question because I'm working on an open source project as well (so this is pure voluntarily as well:-), targeting *nix-system, but we have a task to make it working on Windows as well and we were hoping to not have the need to add platform specific code (to "clean up" input paths that are perfectly normal for users using Windows) > Other projects gcc-g++, libstdc++ may have sponsored or employed > contributors. > They all have their respective standards focus and are uninterested in > non-standard-compliant changes and any non-POSIX build changes. > But they build and run just fine under Cygwin. Yeah, I discovered that the _CYGWIN_ defines actually were in the (real) libstdc++-distro, so I totally understand that > Feel free to make the appropriate patches to the components and submit the > patches to the upstream projects. > But be prepared for the upstream projects to reject the patches if they > break some standard or compliant test case or use case. > Note that it has taken Intel and then MS five years to get FSGSBASE > support patches accepted in Linux. Thanx for the more concrete tips and maybe I'll do that some day > If you are unprepared to do the necessary work, you still get a lot more > than what you paid for. ;^> Ha haa, you're probably right, but I can tap myself on the shoulder and feel that I made the world a bit better I'm totally used to have pull-requests and enhancement-issues to open source projects laying around for ages before approved Thanx Brian Best regards, Kristian > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains too much > technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.] > -- > 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 -- 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
Re: Can't start a cygwin terminal(mintty) as admin
Am 25.11.2020 um 08:43 schrieb Kevin Schnitzius: On Tuesday, November 24, 2020, 03:59:19 PM EST, Thomas Wolff wrote: Am 24.11.2020 um 21:22 schrieb Kevin Schnitzius via Cygwin: >> Ctrl-c is broken on mintty. > This is a wrong statement. For a terminal, Ctrl+c is just a control > character, nothing else. It's the pty device, shell or application that > may, or may not, associate it with specific handling like interruption. D:\cygwin64\bin\mintty.exe -o "KeyFunctions=A+F5:break" - alt-F5 is a break that works on both Cygwin and non-Cygwin processes. D:\cygwin64\bin\mintty.exe -o "KeyFunctions=C+c:break" - Ctrl-c is a break that works on Cygwin processes only. That configuration would assign the break function to Shift+Ctrl+c, not just Ctrl+c, so with Ctrl+c you still just send a ^C character while in the other case mintty would invoke a BRK signal. So try Shift+Ctrl+c. This C+c used to work in both cases... I think we've been over this before and the problem very well may be in the pty break handling. Kevin -- 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
Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
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 where we keep talking at cross purposes. > > > > > > Maybe it is the right thing to do, but what is your take of why it must > be so (all the way) ? > > > > I also do understand that it have several advantages in the > > implementation of std::filesystem but it also imply an extra layer of > > abstraction to the underlaying platform, but to just remove the > > _CYGWIN_ macro when building it would make std::filesystem to not > > understand /cygdrive at all (and I guess that would confuse other > > users;-) so I guess it would require some more sophisticated > > implementation (or extend the number of exceptions already existing in > > the underlaying Cygwin-Posix-implementation) > > I'd like to try to make this discussion more concrete by looking at what's > actually going on in the test program main.cpp that you posted at the > beginning of that thread. (I ran it under strace and gdb to see this for > myself.) > > First, your program calls std::filesystem::exists, which ultimately calls > stat(2) in the Cygwin DLL. The work for this is done in the > path_conv::check function and various functions that it calls. These > functions have code that recognizes Win32 paths like C:\Temp, and > std::filesystem::exists therefore reports "true". This is consistent with > the statement at > https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 about how the > Cygwin DLL treats Win32 paths. > > Next, your program calls std::filesystem::canonical. This calls > std::filesystem::absolute, which reports that C:\Temp is not an absolute > path. > It therefore tries to treat it as a relative path and fails with "No such > file or directory" because /C:\Temp does not exist. > Note that the Cygwin DLL never sees the original path C:\Temp in this > case. Again, this is consistent with the statement in the documentation > that Cygwin applications do not necessarily recognize Win32 paths. > > You say this is a bug, because first you're told that C:\Temp exists and > then you're told it doesn't. But I think it just illustrates the hazards > of using > Win32 paths in Cygwin, which tries hard to emulate Posix. Sometimes you > can get away with using Win32 paths and sometimes you can't, depending on > how and when the Cygwin DLL is involved. Well, to call it a bug in this context was maybe wrong, but in a ISO-standard perspective it would be considered a bug ;-) > I don't see a good way to avoid this inconsistency. We could change > Cygwin so that it rigidly recognizes only Posix paths. Cygwin would then > be consistent, but we would be removing a feature that many users have > become accustomed to I guess so too, but they are already there for some reason I don't expect that the posix-functions should accept any non-posix-paths but it would be nice to have the platform independent std::filesystem to work transparently but I guess, since the cygstdc++-library uses the underlaying posix-functions the only reasonable way to accomplish this is to extend the list of features that already exists The sole reason for std::filesystem was to avoid platform dependent code So I guess in practical, it is up to the community of how well motivated they are to extend those Posix-functions but my take in this thread is that many rather would like it to become more ... like an emulator > And it wouldn't help you. Or we could ask all Cygwin package maintainers > to try to patch their packages so that they recognize Win32 paths, but > that's simply not feasible, nor would many package maintainers be willing > to invest the required time. I'm not sure what package maintainers you're referring to here now ? Applications ? Cygwin ? GCC ? > I tried it once with emacs, which I maintain, in response to a user > request. I failed miserably. Every change I made broke something else, > and I finally gave up. > > I don't think g++ will be any easier than emacs, and I don't think you can > expect the g++ maintainer to work on this. Yeah, I noticed that the _CYGWIN_ macro actually was a part of the real libstdc++-distro Thanx Ken and keep up the good work Kristian > Ken -- 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
Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem
> 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 > call it as a subroutine, maybe, to try to canonicalize a wider range of > paths. Yeah, thanx for the tip, but this functionality won't be available on other *nix-platforms, so some kind of #ifdef is required > Note the interesting difference between the \Temp and /Temp cases. > cygpath is processing \Temp as a Windows-like thing, and thus interpreting > it according the the Windows root for the current drive. However, it > processes /Temp and a Posix-like path, which will be in term of the > _Cygwin_ root, generally the CYgwin install directory. > > Still, if you did this canonicalization first, maybe you would get more > what you're looking for? I'm not sure it would be a good idea to insert > this generally into the Cygwin library stack. Others more familiar with > the fine details can probably elaborate why. I experimented by fiddling around with making the path canonical and as you say, maybe we will be more successful and that could still be a part of our code that is not platform dependant I guess we need to go out of std::filesystem::canonical though because that is what fails (and unfortunately I guess there's a real bug in the (real) g++ distro of because the std::filesystem::path::generic-functions doesn't work as the standard mandates either) Once again, thanx for the tips Best regards, Kristian > Regards - Eliot Moss > -- > 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 -- 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
