Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
From:	"LA Walsh" <law AT tlinx DOT org>
To:	"'Hack Kampbjorn'" <cygwin AT hack DOT kampbjorn DOT com>
Cc:	<cygwin AT cygwin DOT com>
Subject:	RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis
Date:	Mon, 6 Jan 2003 01:52:18 -0800
Message-ID:	<000e01c2b569$4d0d0e50$1403a8c0@sc.tlinx.org>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
In-Reply-To:	<3E18D5A7.3050707@hack.kampbjorn.com>
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1106
Importance:	Normal
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id h069r0p25341

> -----Original Message-----
> From: Hack Kampbjorn [mailto:cygwin AT hack DOT kampbjorn DOT com] 

> > Cygwin, and possibly, the Win32 module, are inconsistent in 
> handling 
> > the differences between i:/foobar/ and i:.  On one hand i: is 
> > considered a 'volume' but on the other hand i:/ seems to 
> evaluate to 
> > the same, incorrect, value. In "Win32", each 'fs' of form 
> "<x>:', x of 
> > class <[:alpha:]>, there is a process-specific "current 
> directory".  
> > This can be seen by:
> > 
> In the old DOS days yes, but in Win32 there is only one current 
> directory. The illusion of having a current directory per 
> drive and an 
> active drive is maintained in cmd.exe (or is it in the MS C 
> runtime?). 

====
	Most programs seem to recognize this convention, for example, "notepad.exe",  "win32-GVIM", Adobe Acrobat, vbs scripts.  

	Do you know of any programs that don't behave this way?

> As cygwin doesn't use it, i:foobar and i:/foobar is always the same.
---
	Always?  Like when 'foobar' = '*'?

law> echo z:*
z:*
law> echo z:/*
z:/Content.IE5 z:/OLKAD7 z:/desktop.ini z:/foo z:/stardock_activedesktop.pdf z:/
which.txt


	IMO, this is "wrong" behavior:

1)
C:\>dir /a /b z:
foo.txt
foobar.txt
foobar.txt.000
stardock_activedesktop.pdf

C:\>ls z:
Content.IE5  OLKAD7  desktop.ini  foo  stardock_activedesktop.pdf

2) Take your pick -- if I launch bash from the above CMD.EXE -- bash
will ignore win32's curdir for Z:, but if then launch a win32 app like
Gvim, directly from bash and write a file "z:new", then when I exit gvim 
and do an "ls z:" the file isn't there.  That's inconsistent with the underlying
OS's concept of a current dir/drive.  It's not just in 'cmd.exe' -- more likely
in USER.DLL or some such, which pretty much makes it a part of the OS.


law> /c/Program\ Files/Vim/vim61/gvim.exe (write out blank file to "z:new")
law> ls z:
Content.IE5/  OLKAD7/  desktop.ini  foo/  stardock_activedesktop.pdf  which.txt
law> ls z:foo
foo.txt     foobar.txt.000  new.000                     which.txt
foobar.txt  new             stardock_activedesktop.pdf
law>

	Do you think this is proper behavior?  Do you think a win32 person being
introduced to posix/gnu utils would find this beneficial?  Do you think
a linux person who uses some combination of cygwin and Win utils would find
this beneficial?  

-l




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -