This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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
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/