bug in cygwin_conv_to_posix_path() caused by period in win32 path

[Pavel Kudrna]

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
>> way:
>> 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
> shortcut,
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.
> Corinna
>
> (*) 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;
 for(p=envp;*p;p++)
 {
  if (1|| **p=='!') printf( "%s\n", *p );
 }
 getc(stdin);
 return 0;
}


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/