Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "linda w \(cyg\)" <cygwin AT tlinx DOT org>
To: <cygwin AT cygwin DOT com>
Cc: <perl5-porters AT perl DOT org>
Subject: RE: Repost, different list...File::Spec, cygwin, Syntactic vs.    Semantic path analysis
Date: Tue, 7 Jan 2003 19:44:42 -0800
Message-ID: <000001c2b6c8$479bea30$1403a8c0@sc.tlinx.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
In-Reply-To: <20030106180241.GL25858@redhat.com>
Importance: Normal
Content-Transfer-Encoding: 8bit


> From: Christopher Faylor
> I am not clear on why we are devoting so much time to what is
> required for a straight win32 environment in a cygwin mailing 
> list.  As odd as it sounds, this seems somewhat off-topic to 
> me.  Or at least uninteresting.
===
	I'm sorry.  I thought the cygwin project -- was to provide a Posix type
platform to [aid, assist, help] in porting *nix/gnu utils to the Win32
environment.  

	Might that not imply some minimal understanding of the Win32 environment
so as to integrate as seamlessly as possible with such?
If one wants a pure (well mostly) non-win32 environment, there is 
always Linux, but without some understanding of the Win32 environment,
some might consider it difficult to port tools to such an environment.

	The only reason this issue came up for me was in writing a perl util
that I could, transparently, use on either my linux or Win boxes.  It'd be nice
to start having more free tools on Win32 to replace dime and nickel utils that
do as little as rename files. But for that to be happen, the tools have to be
able to parse standard Win32 pathnames as well as posix-ish/*nix filenames.  

	If I give the utility to my mom, I don't want to have to try to
explain to her why she has to learn a whole different file syntax just
to use a freeware utility.  It won't happen.  It would hinder adoption and
acceptance of such utilities.

> You could take the radical approach of having a cygwin perl
> module reject backslashes and colons entirely.  
---
	IMO, that would defeat the purpose of cygwin.  
> Whatever you 
> do *please* do not make the mistake of converting slashes to 
> backslashes in anything that is seen by cygwin functions.
---
	And your reasoning not to convert a path that appears to be
a Win format: C:\foobar/smellypath/file or \\sysname\share/dir/subdir
to a standard winpath of all backslashes if the user asks for a 
canonical path?  You say:

>  If 
> you convert backslashes to slashes then you will be 
> introducing an inconsistency between the way cygwin handles 
> these types of paths and the way the perl module interprets 
> them.  Backslashes and colons in paths short-circuit mount 
> table operations in cygwin.  So, \usr\bin is not equivalent 
> to /usr/bin.
---
	So by that logic we should do...what?  If we convert from C:\foobar
to /cygdrive/c/foobar we are changing the semantics introduced via the
cygwin mounting system.

	I think we are in agreement on "/home/myhome\mybin\myfile" being
canonicalized to use all forward slashes.  I'm pretty stiff at this point,
though about converting C:/foo to C:\foo.  I'm a bit more torn on
the usage of "//host/share/dir/file" vs. "\\host\share\dir\file".
Just now, in trying to mount a cygwin virtual path on a remote // filesystem, it
didn't work.  I suspect that you cannot have a cygwin
file system mounted on a remote directory.  That would be "a" point in saying
that "//" should be canonicalized to "\\" since it can't be
a cygwin mounted fs, and truly is a Win32 path construct, thus, 
canonicalization to backslashes would be appropriate.

	
> I'd like to ignore this tempest in a teapot entirely but I
> sure don't want to see someone implement a perl module that 
> does the wrong thing for cygwin.
---
	"wrong thing" may depend on what one thinks cygwin is for.  It's
like the good vs. bad thing...good for what?  bad for who?  Hopefully
we arrive at an answer that is good for all.

	Someone mentioned a distaste for the idea of parsing unix
filesystems into the "volume" parameter, but that's exactly what
the "volume" parameter is for.  However, given that "cygdrive" is an
arbitrary default string that can be 'user changed', then cygdrive has
only a 'semantic' meaning, not 'syntactic'.  

	If File::Spec moves, in general, to being 'Syntax' only, then
has a different decompose function for Semantic analysis then the
default would not to treat /cygdrive/<drive> special unless one 
parsed for "semantic" analysis -- in which case, all mount points
should be broken apart with the right-most mount point being the
first 'device' name split off (with the possibility, with nested mounts, of
there being more calls to the semantic decompose function to get at all the
separate devices (if needed) -- though usually for rename/copy purposes one
wants the device the targe file/dir would be on, thus the right most
path component that is a file system.

	Is this making any sense yet?

Linda

p.s. -- Sometimes I wish _simple_ HTML would become more standardized for
email -- it could make some writing much easier to read and comprehend.

If only text-based email readers could do the 'lynx' thing with HTML 
content....


--
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/