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
Message-Id: <4.3.1.2.20030111143529.036c3f08@pop.rcn.com>
X-Sender: lhall AT pop DOT rcn DOT com
Date: Sat, 11 Jan 2003 14:56:21 -0500
To: "LA Walsh" <law AT tlinx DOT org>, <cygwin AT cygwin DOT com>
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject: RE: Repost, different list...File::Spec, cygwin, Syntactic vs.
   Semantic path analysis
In-Reply-To: <003501c2b8ff$89206c90$1403a8c0@sc.tlinx.org>
References: <3E1F113F DOT 1080002 AT cotagesoft DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I've found that it's always easy to look back at a previously made design
decision and question it, especially when one wasn't involved in the 
design discussion that weighed the current needs with the benefits and
detriments of possible implementations.  Rethinking a design decision 
isn't bad of course but it's always easier to see more alternatives in 
hindsight than it is at the time.  Some of the reason more options are 
generally 'obvious' in hindsight is because there is more infrastructure
in place that would support these options.  That's not always the case at
the time a feature is implemented.  Suffice it to say there was 
precedent for the '//<drive' syntax (I believe MKS did this or was it
O/S 2?) and pseudo device support was very much in it's infancy.  But these
are not the only reasons this syntax came into being.  The main reason was
because somebody wanted it and then implemented it.  It addressed the need
of being able to easily access all available drives without the user needing 
to explicitly set up mount entries.  Obviously, while folks using Cygwin in
general liked the notion of not having to mount drives explicitly, there were
enough who found the conflict with the '//<computer name>/<share>' syntax
of UNC paths a problem to prompt making a change to something that allowed 
both benefits (the current '/cygdrive/<drive letter>' convention).  You may 
be able to find some threads of this whole discussion and development in the 
email archives if you're interested in doing a little digging.  You might
find that it answers allot of questions you have about Cygwin path handling.
I'd start with 1997 though if you're looking to pick up any threads that were 
at least close to the opening discussions.

Larry


At 06:25 PM 1/10/2003, LA Walsh wrote:
>Interesting...wonder why they wouldn't just create pseudo devices
>in /dev and do the normal unix mount thing?  Seems odd to complicate the simple
>namespace model needlessly by adding a special syntax.
>
>Even still, just because one wants to have more traditional unix names doesn't
>preclude the possible design goal of backward compatibility with
>existing Win32 pathnames to aid in portable tool usage and design.
>
>Even a hard coded /smb/ or /smb:/ prefix on smb <host/sharename> shares would be
>a better choice that "//".  Why perpetuate the MS view of 
>SMB being 'special' vs. using an eventual mounting syntax that would
>allow it to coexist with /nfs/ type files?  If the mount system evolved
>enough in cygwin, then I could see mount allowing specification of
>'nfs' in a mount command -- either as a link to an MS-nfs method
>(assuming they were supply one) or cygwin-based NFS methods like the
>universal NFS server... 
>
>-linda
>
>
> > Cygwin predates RedHat. See http://cygwin.com/history.html  (the 
> > earliest date in the file is Dec 1995). RedHat bought Cygnus 
> > Solutions 
> > (which was a shop for commercial support for GNU software, especially 
> > GCC ports to obscure and new platforms), which did the 
> > original Cygwin work.
> > 
> > Anyone at RedHat from the original Cygwin team (the last 
> > warriors of the 
> > (in)famous "Beta 20" :-)?) wanna answer this?
> > 
> > There's an interesting line in the early changelogs:
> > 
> >     Release Beta 8
> >     [...]
> >     Much nicer way of describing paths, eg //c/foo is c:\foo.
> > 
> > Suggests that the early goal *was* to provide a POSIX-y view, and the 
> > exposing of Windows paths was added as a convenience..
> > 
> > 
>
>
>--
>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/


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