This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in cygwin_conv_to_posix_path() caused by period in win32 path

Corinna Vinschen wrote:
On Jul 12 21:01, Pavel Kudrna wrote:
After that change cygwin_conv_to_posix_path() treats all following paths in the same
c:\ /cygdrive/c
c: /cygdrive/c
c:\.\ /cygdrive/c/
c:\. /cygdrive/c
c:.\ /cygdrive/c/./
c:. /cygdrive/c/.
Before the suggested change last two items were slashified only.

C:. in DOS terms is *not* the same as /cygdrive/c/. C:. is something which has no meaning in the POSIX world. There is no such thing as a drive-relative current working directory [DCWD] in POSIX.
That is true. (and well understood as cgf mentioned).
The above conversion is plain wrong.
Maybe, but my point is if c: is /cygdrive/c than c:. is at least as good /cygdrive/c as that.
I don't see how converting a pure DOS-ism
into a wrong POSIX path is doing any good.
Novell client uses paths of type z:. as so called search drives. It is stupid because if works
only until you change current dir on that drive. It should use z:\ instead but we can't change it
and it works.
So the good is that it is possible to run novell netware utilities from cygwin bash etc.
As for the idea to use the environment variables storing the DCWD in
Cygwin, these variables are being created by CMD.EXE(*).
Are you sure they are created by cmd? Cgf already persuaded me about that, he said
"...any other windows application which tried hard enough can get to them."
But when I compile my envp.c example (see below) with -mno-cygwin no !x:
(or similar, I tried without if condition) variables are displayed. Cmd's set
command also doesn't show any.
What I am doing wrong (or not hard enough)?
So they don't
even exist if you start your shell without the detour of starting a
batch file.  They don't exist when you start your shell with a desktop
I tried it with my envp program (see below) and run it from Start menu ->Run, from shortcut
with Target: cmd /c envp.exe or with Target: envp.exe. The Start in: was
"C:\Program Files\cygwin\bin" because I don't have cygwin/bin in search path.
From cmd there are !S:, !T:, !U: and !Z: on my system (which are network drives) but
not !L: (which is subst drive). After L: and C: commands performed in cmd !L: appears.
!C: is present only with cmd /c.
To summarize: the logic of creating these !X: variables is not clear to me.
by starting rxvt, or by starting your shell through a remote
ssh session.  Trick question:  How is Cygwin supposed to convert C:.
correctly when there's no information about the DCWD for drive C?

The bottom line is, I don't think it makes sense to convert C:. into a
POSIX path at all.
It is not clear how to consistently interpret C: or C:. even with help of !X: variables
if there could be any help of them. It seems to be impossible as cgf wrote.

But now, if c: is interpreted as c:\ than c:. should too.
Current cygwin_conv_to_posix_path() behaviour i.e. leaving c:. unconverted and return
no error is bad and I think very difficult to defend.

(*) and, funny enough, there's no API call in Win32 to return a DCWD.
There's just a call GetCurrentDirectory() which returns *the* CWD.
Which makes sense, given that the RTL_USER_PROCESS_PARAMETERS can only
store one CWD per process.
Pavel Kudrna

/* gcc -o envp envp.c */
#include <stdio.h>
int main(int argc,char* argv[], char* envp[])
char **p;
 if (1|| **p=='!') printf( "%s\n", *p );
return 0;

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]