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
Content-Type: text/plain;
	charset="UTF-8"
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
Content-Transfer-Encoding: 8bit
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/