Subject: Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis
From: Christopher Faylor <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 7 Jan 2003 23:56:16 -0500

On Tue, Jan 07, 2003 at 07:44:42PM -0800, linda w (cyg) wrote:
>> 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.

Cygwin's primary purpose is to provide a UNIX environment for Windows.
Although it can be used in other ways, the basic purpose is not to
provide a stepping stone to helping port programs to native Windows.
Things like Win32 path names and accommodating pure-win32 processes are
*always* of secondary importance wrt getting the UNIX bits right.

>Might that not imply some minimal understanding of the Win32
>environment so as to integrate as seamlessly as possible with such?

Nope.  It's supposed to isolate you from the windows environment.  In
theory, you shouldn't have to know or worry about the :\ nonsense.

I realize that really isn't possible, but spending countless messages
agonizing over the right way to deal with a backslash is really getting
far afield from the goals of the project.

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

Understanding that the OS uses :\ specially, and that the filenames are
case preserving but case insensitive, is, of course, necessary.
Understanding that double slashes at the beginning of a path are special
is good sense for any portable program.

Again, spending a lot of time worrying about what will happen when a user
types in a MS-DOS path name is uninteresting.  Document whatever warts
that Cygwin has and move on.  Or provide patches to rectify any egregious
behavior you find.  Just lets not spend too much time on this subject
in the cygwin mailing list.

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

Why?  Just use UNIX paths.

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

Maybe your mom is special.  My parents have little, if any, understanding
of slashes, so if I told to always type 'mv /cygdrive/c/foo /cygdrive/c/bar'
they would dutifully type that.  If I tried to explain how they could
type

  c:
  cd \foo
  d:
  c:
  pwd

and still be in c:\foo their eyes would glaze over.

It's hard to understand how this could be a really big issue for a naive
user anyway.

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

I said previously that if cygwin sees a path with a backslash or a colon
it is considered to be a windows path.  So, if you change /foo/bar to
\foo\bar or c:\foo\bar you will cause problems.  That is what I meant.
As far as cygwin is concerned, \foo/bar and \foo\bar are "equivalent",
however.  The presence of the backslash causes the file to be treated
as a windows path.

So, I don't want to see any of these conversions as part of a
canonicalization:

Path		Conversion
/foo\bar	/foo/bar
/foo/bar	\foo\bar
c:/foo/bar	/cygdrive/c/foo/bar
c:\foo/bar	/cygdrive/c/foo/bar
/cygdrive/c/foo	c:\foo

These are ok:

path		conversion
/foo\bar	\foo\bar
/foo/bar	/foo/bar
c:/foo/bar	c:\foo\bar
c:\foo/bar	c:\foo\bar
c:\foo\bar	c:/foo/bar	(presence of colon means win32)
/cygdrive/c/foo	/cygdrive/c/foo

>I think we are in agreement on "/home/myhome\mybin\myfile" being
>canonicalized to use all forward slashes.

We are not in agreement.  If cygwin sees a backslash it assumes it is a
windows path.

(Maybe I've repeated this enough now.  I think I'll stop)

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

Mounting remote shares works just fine.  I do it all of the time.  I'd
be lost if it wasn't possible.  Cygwin's mount table is just a
translation table.  There is no magic that would preclude using remote
paths.

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

Hmm.  I would think that my vote would count very highly in the
matter of what is right or wrong for cygwin.

>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'.

Any mount point can be "user changed".  /cygdrive is special in that
only a limited number of items are available underneath the mount
point.  It is, I believe, similar to linux's devfs in that regard.
Eventually, cygwin will have something similar to devfs, in fact.

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

If File::Spec deals with mount points then it should be able to handle
/cygdrive and the rest of the mount table just fine.  /cygdrive entries
show up in the mount table.  You are trying to move things into an
esoteric realm.  I'm trying to show where there is (unsurprisingly)
correspondence between UNIX and Cygwin.  So, whatever UNIX does with a
mount table should be more-or-less applicable to cygwin.  You can worry
about semantics and syntaxes over in the UNIX realm.  If the perl gods
decide to tweak something there, I'm happy to let cygwin hitch a ride on
their decision.

Anyway, I've said my piece here.  I'll sit back and watch what happens.
If the end result is something that breaks things and people start
complaining, we can always fix the problems and I can always say...
Nah.  I wouldn't do that.

cgf

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