X-Spam-Check-By: sourceware.org
Message-ID: <46976DEE.2000004@mff.cuni.cz>
Date: Fri, 13 Jul 2007 14:19:58 +0200
From: Pavel Kudrna <Pavel DOT Kudrna AT mff DOT cuni DOT cz>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: bug in cygwin_conv_to_posix_path() caused by period in win32   path
References: <468A1024 DOT 8000007 AT mff DOT cuni DOT cz> <468A441A DOT 2000009 AT cygwin DOT com> <468B657B DOT 3050306 AT mff DOT cuni DOT cz> <20070704213927 DOT GC16838 AT trixie DOT casa DOT cgf DOT cx> <468D70E6 DOT 4070403 AT mff DOT cuni DOT cz> <468D75C5 DOT 5050507 AT cygwin DOT com> <20070706001522 DOT GB22578 AT ednor DOT casa DOT cgf DOT cx> <46967A99 DOT 5040208 AT mff DOT cuni DOT cz> <20070713073725 DOT GJ6851 AT calimero DOT vinschen DOT de>
In-Reply-To: <20070713073725.GJ6851@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/