bug in cygwin_conv_to_posix_path() caused by period in win32 path
Fri Jul 13 12:20:00 GMT 2007
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.
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
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.
/* gcc -o envp envp.c */
int main(int argc,char* argv, char* envp)
if (1|| **p=='!') printf( "%s\n", *p );
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin