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/
