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>, <perl5-porters AT perl DOT org>
Subject: RE: Repost, different list...File::Spec, cygwin, Syntactic vs.  Semantic path analysis
Date: Thu, 9 Jan 2003 14:20:37 -0800
Message-ID: <006c01c2b82d$55dd70d0$1403a8c0@sc.tlinx.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
In-Reply-To: <1042100310.8869.344.camel@lifelesslap>
Importance: Normal
Content-Transfer-Encoding: 8bit


> Cygwin targets POSIX compatibility wherever possible. Any 
> discussion about paths that ignores the POSIX standards will 
> need to be reviewed with POSIX in mind. It's easier to do 
> that up front.
---
	What were the _original_ design goals of Cygwin -- i.e. as 
sponsored by "RedHat"?

	If one claims that the original project pages are irrelevant or not
appropriate to use as a specification of the project intention, then I'd say
that Cygwin has been moved off of the original project goals and
is no longer "the same" project, but something else.  

	Changing the original goals to suit the aesthetic sensibilities of
project maintainers  is very different from creating a useful compatibility
layer for RedHat customers to port applications from Linux to the Win32
environment and use those applications and tools _seamlessly_ with *native*
Win32 applications.  Putting on an 'enterprise' hat, I don't want my Win32 or
Linux sys admins to have to learn to use separate path syntaxes depending on
which tool they are using in the Win32 environment.  A project goal/feature
that was listed was the ability to use Win32 tools intermixed with usage of
Unix [redhat linux] utils.

	Under any major, user-oriented version of Unix that I am aware
of, "//" is reduced to "/" by the *OS*.  This is perfectly POSIX compliant
behavior.  The restriction of non-assumptions of "//"=="/" are on _applications_
that desire to be POSIX compliant -- it is not a restriction on the OS.

	Many Unix programs -- written for Unix and with no intention or care
about "POSIX" compatibility make the choice to allow "//" to reduce to "/".
How many makefiles are written to install in ${ROOT}/pathname, that 
are *expected* to work when ${ROOT} = "/"?  POSIX does not require any
OS implementation to break this assumption.  To my knowledge, only 2
"Unix-like" OS's break this: "qnx" and "nto".  I've never heard of "nto",
but "qnx" isn't an OS that that most RedHat customers will have had extensive
experience with.  

If I want to take current Linux scripts and
utils -- like RPM, and have them run on Cygwin, then "//" _has_ to
break down to "/".  RPM runs scripts to install in root.  Those scripts
are passed in the ROOT to install in and the path.  If ROOT is set to
"/", then those scripts are going to see "//".  If you break Unix/linux
compatibility by interpreting "//" otherwise, you have failed one of the primary
goals of the original project.

In going through this exercise, I've become convinced that my original
thought of canonicalizing "//host/share/path" to \\host\share\path is
inadvisable and wouldn't be best for Linux or Unix compatibility.

For maximal compatibility, cygwin should behave like linux and as many unixes as
possible and map //usr/bin to /usr/bin.  

The only reason "//" was ever considered to be anything different is because the
underlying OS uses "\\" as a hostname lead-in.  It was a pure "ease
of use" issue because lazy folks don't want to have to put single quotes
around pathnames or escape backquotes.  But on Win32, one already has
to deal with spaces much of the time.

The behavior could be settable for early cygwin compatibility by a value
in the "CYGWIN"-options environment variable,  but to have fullest
linux and Unix compatibility canonicalization of forward slash paths
would be done in standard linux/Unix style while canonicalization of 
paths of the form "<drive><colon>..." or "<backquote><>..."
would be canonicalized into Win32 standard paths.  If you want to
only use Unix/linux style paths, then one would use _mount_ to mount
network file systems the same is the convention in Unix/linux.

This allows pre-existing scripts, RPM (I wondered why that wasn't used
to manage cygwin packages...), install and makefile tools to work under
cygwin identically as under linux/Unix.  If one chooses to use "win32"
style pathnames, one needs to be aware of the issues of "\" in pathnames
vs. "/" and be aware of the quoting issues.  This is already a requirement
on cygwin and would not be 'new' behavior -- nor would it break
compatibility with existing linux scripts.

Subnote:  Paths containing "/"  after a Win32 path classifier would be
canonicalized to "\" just as Win32 does.

Any other behavior will cause greater compatibility problems with pre-existing
Linux/Unix tools, scripts and makefiles.

I am aware this is not a Perl-only issue and would require cygwin.dll
semantic changes.  I'm also aware that this seems to be an emotional
issue with my own emotions coming through in, what I believe to be, a 'reactive
manner'.  

Emotional issues and egos aside (easier said than done), I'd like people to
consider the proposal "independent" of what "is".  I'm perfectly willing
to have my views changed, *again*, (I first thought //<share> should be
valid).  With discussion, I'm open to logical, non-dismissive and thought
out comments.  

I would be sad, though, if it comes to the conclusion that cygwin isn't
the project is started out to be, but is something else.  I don't know
that I would be capable of or want to sufficiently to undertake a spinning off
from the current project to go back to what I feel are original (and, IMO,
sound) project goals.

Having worked in the Unix and Linux fields since '89, I've gone through
(and still have) much anti-MS sentiment.  I'm still greatly angered by MS
decisions and domination -- but in being forced to adopt more MS usage
because of UI-RSI/usability issues, I've been forced to examine my own biases.
I've moved more toward the idea that everything MS is not bad and MS actually
has some good and sound ideas -- better, than some open
source options -- and not just because MS is "ahead".  I've witnessed,
first-hand, core Linux kernel people argue against features to allow needed and
useful features.  It's *their* pet project and some of them don't give a wit's
xxyz about usability or compatibility.  I've seen entire, working, CAPP
compliant auditing thrown out, years ago, on political issues and whims.  

It's not that Linux is 'behind' in some features because no one has written them
-- it's because the implementers didn't say "please" well enough to be allowed
to have them merged.  I've seen people shut out of Linux design summits on
political grounds -- not technical merit.  

Perhaps, to me, that is most galling, since for so long, I've had the
ideal that computer science and the computer/geek community was a
technocracy...where ideas were judged on technical merit, not political and
personal whim.  Maybe it was, at one point or maybe I was just naīve.  Whatever.
I'll probably still be so stupid on my 80th and 125th birthday to be the one in
the crowd that (rightly or wrongly) points out that it
really does seem to be the case that the emperor isn't wearing any clothes.

-Linda


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