RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Thu, 2003-01-09 at 19:08, LA Walsh wrote:


> 	Ok, did I mention POSIX?  Posix != Unix.  So what's your point?

Cygwin targets POSIX compatability wherever posible. 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.


> 
> > > Dogma is an anesthetization of "critical thinking".
> > 
> > Just curious, if that is the case, why do you make vehement 
> > assertions of your own?
> ---
> 	For the same reason I do yoga?  
> 	Thinking of the founding fathers of the US, can one believe they did not engage in critical thinking or that they were not vehement in their assertions against unjust leadership?  
> 	And the meaning of your statement?  Could you be more clear?  I
> don't understand.

It seemed somewhat hypocritical to refute Chris' argument on the basis
of vehement assertions, and then make ones of your own.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Hindsite, moving forward, concepts...?

[Larry Hall (RFK Partners, Inc)]

At 05:07 PM 1/11/2003, linda w \(cyg\) wrote:

<snip>

>         However the good news is that with the emphasis on applications maintaining POSIX compatibility -- no one
>should be *relying* on "//" having a special meaning.  


If you mean programmatically, I'd say that's probably true.  Some may
have created scripts that make this assumption but I don't see that
as a major issue.



>That being the case, one could choose, in the present, to do a
>simple hack (in the minimal case) to change the smb-share prefix
>from "//<host/share>" to "/smb/<host/share>".  Theoretically, this
>should break nothing. unless they have hard-coded paths.


Right, 'theoretically'.



>If transitioning of current CYGWIN customers who may have
>hardcoded paths is a concern, then a transition plan could be
>put into effect (dates TBD):
>1) string in envvar CYGWIN, maybe, 'SMB_PRFX="//"'.
>    This could be added to any "update" if not defined, or 
>    set as 'SMB_PRFX="/smb/"' in new installs or set
>    to SMB_PRFX="" by users who want to do their own mounting.
>2) When automounting SMB shares is available, then can 
>    default SMB PRFX="" in new installs.  Warning in console
>    login shells of "SMB_PRFX" being deprecated in favor of
>    automount usage.
>3) Base install includes smb-automount setup. Usage of SMB_PRFX 
>    generates warning about being ignored/obsolete and to use
>    automount for smb references (with default "/smb").
>4) ...after a few years...remove check for SMB_PRFX...


Right.  This could be a way to phase out the UNC path convention if
this was desirable.


>Steps can be skipped/merged; it may be decided that it is a non-issue and just do it.
>
>For Win32 paths -- again, going with full Win32 compatibility
>seems logical since it is the only standard that assigns
>meanings to ":\" usage in the Win32 world.  Again, if *really*
>needed, one could use a similar transition plan to allow
>conversion of apps that make assumptions about C:foobar not
>having the standard Win32 meaning (as previously shown, this
>is not a property of CMD, and is 'honored' (wherever it is 
>implemented) in, AFAIK,  all of MS's programs.
>
>Any issues only affecting Win32 path usage would be unlikely
>to affect POSIX-compliant programs using preferred-character-set filenames.
>
>Logical?  Not asking, necessarily, that anyone implement it --
>I'm only engaging in a concept discussion.  Actual implementation --
>well that may never happen, or may -- may be done by someone
>expert in the various areas affected, or done by me (in all my loads of spare time...*cough-cough*).


Logical, yes, in terms of reaching your stated goal.  Whether that goal is
desirable as a whole measured by the community's usage preferences, patterns, 
and needs, that wouldn't be for me to say. ;-)  Of course, the real hitch
is the resource to implement, which you acknowledge.  As you know, lot's 
of things can sound reasonable, logical, and even compelling in theory 
and yet still be abysmal failures once implemented.  But having something
implemented gives the entire community a concrete item to review, reform, 
critique, and accept/reject.  It's generally a very successful route to 
getting new functionality in Cygwin.  I recommend it if you're motivated 
to implement some functionality.


>I'm trying to focus on what I believe would be useful for the
>Cygwin toolset to allow for gnu-linux tool porting for the
>purpose of using them interactively/transparently in a win32
>environment _and_ providing a *nix-POSIX compatibility layer.


I understand.  I'm not sure that I concur with your assessment the current
needs for this work but I'm quite willing to evaluate it based on the 
merits of it's implementation.  Not to 'scare' you of course but changing
behavior of the Cygwin path handling code is not a task to be undertaken
lightly.  This area has allot of logic to parse the various path forms
already handled plus POSIXy emulations.  Any changes there must be rigorously
tested for correctness and performance (i.e. no worse performance than now).
But if that doesn't scare you ( :-) ) then I'd recommend you take the next
step and start poking around in the code.  It really is the best way to 
understand the details of what's there and formulate a real plan of attack.

Good luck,



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[LA Walsh]

> From: Robert Collins [mailto:rbcollins@cygwin.com] 
> > 	There you go again, making relative assertions about "good/bad" 
> > again.  It's common practice to define a $(ROOT)/foobar 
> underwhich to 
> > build or install a program.  It is common to have ROOT=/ 
> when you want 
> > to install it on a live machine.  It is *expected* that 
> double slashes 
> > "//" will be treated as "/".  Thinking "//" is special only 
> shows the 
> > corrupting influence Win32 has had on your thinking.  If 
> you grew up 
> > on unix, you'd know that "//" = "/".
> 
> Whoa. POSIX uses // as a imeplementation specific prefix for 
> network paths. The posix 'dirname' algorithm EXPLICITLY 
> leaves the use of // as implementation specific. Go check it 
> up you want proof.
===
	Ok, did I mention POSIX?  Posix != Unix.  So what's your point?
	I've been on multiple unices [bogus latinization, but unix's doesn't roll of the tongue nearly so well]: sun, hp, sgi, linux, xenix, sco, 
others I don't remember.  I don't recall "//" being anything other than
"/" on any of them, though my memory is most accurate for linux/SGI and
I'm fairly sure about sun.  But any OS is subject to change over the years.
So who knows what is true now.  But just because it is Posix doesn't
mean its true for Unix.

> Growing up on unix does NOT mean // == /. If you assume that 
> *anywhere* you will limit your programs portability 
> (specifically, you are IMMEDIATELY non-posix).
---
	That may very well be correct -- can you name some large user-base
unix's that I might encounter where "//" != "/"?  I'm not saying they
don't exist, I just would like to know which of the larger vendors have
a unix that functions that way.  If none of them do, then my statement
of 'growing up on unix' would still have most people with an experience
of "//" reducing to "/".  But POSIXly speaking, I cannot and do not
refute what you claim.

> > Dogma is an anesthetization of "critical thinking".
> 
> Just curious, if that is the case, why do you make vehement 
> assertions of your own?
---
	For the same reason I do yoga?  
	Thinking of the founding fathers of the US, can one believe they did not engage in critical thinking or that they were not vehement in their assertions against unjust leadership?  
	And the meaning of your statement?  Could you be more clear?  I
don't understand.

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

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[linda w (cyg)]

> 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

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[LA Walsh]

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

Hindsite, moving forward, concepts...?

[linda w (cyg)]

> From: Larry Hall (RFK Partners, Inc) [mailto:lhall@rfk.com] 

> 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. 
---
	At the time one makes decisions one cannot know what one will know in 5,2,1 years or 4 months time. At my last company,
large group made decision to go w 1 vendor out of 2 for a feature we
needed.  Logically, choice #2 was better, though for some intangible reason (that I couldn't justify) I felt safer with choice #1
even
though the facts didn't stack up in their favor.  The group decided
to go with choice 2.  Five months later, choice2 announced a law
suit with one of their suppliers that had been ongoing for about 6-8 months (i.e. they knew they were in trouble when negotiating
with
us but were hoping to get our money to tide them through the financial rough waters until they could legally force their supplier to
live up to expectations...).  It killed the project for our company -- the other company got wind of our deal and now had almost
doubled the price and the critical product timing window would be
about 80% closed by the time we'd be able to get a release from 
company #1.

	In retrospect, I can see more logically, why I felt the way
I did -- we had more experience and work history with #1 even though they had some known and recurrent issues.  I felt more
comfortable with the known 'evil' that I felt we could safeguard against vs. the unknown "snake-oil" sales people from company #2.
Also #2 had a
*very* polished marketing pitch, while company #1 had virtually no marketing -- almost all engineers.  That also figured into my
"feeling": if you have two small companies, both have limited 
resources to produce the same product and prices are in the same
range.  Then if one has really snazzy presentations vs. the
others have more raw presentations looking like engineer written
documentation (vs. tech pubs), which company do you think is 
more likely to have resources to complete an engineering project?


> 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.
---
	Absolutely...just the idea of mentioning 'mount' or even
the idea of NFS or an 'automounter' -- they aren't the first things one would be thinking about in an environment where you don't
even have a self-hosted, compiler yet.

	That's one reason I think long term project planning is
a waste to devote *too* much detail towards.  You don't know
what the state of the art will be in 2 years -- or what new tools will be available, or whatever.  You just do the best you can
at the time -- designing things as modularly and bullet proof
as you can so you can more easily re-use code with minimal
changes in new features in un-anticipated ways.  Using the reasoning "well it wasn't designed for that" doesn't help you alot when
all you wanted to do was write an email *now* to your stock broker
to 'sell'.  You get to have your sale or you don't.  The market doesn't care.  There is no 'good guy/bad guy', blame is irrelevant.
The only thing that is relevant is if you sold your stock or not.

  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.
---
	I can see how the decision was made.  I believe I _might_
have tried for a special prefix like /net/ -- a different 
flavor of hack, but not without wide precedent: /debug, /proc,
/host (not really hardcoded, but defaulted)" etc.

	But you're right in that you can never really say, for certain, what choices one would have made because in the present,
one, irrevocably, has some knowledge of the present.

	However the good news is that with the emphasis on applications maintaining POSIX compatibility -- no one
should be *relying* on "//" having a special meaning.  

That being the case, one could choose, in the present, to do a
simple hack (in the minimal case) to change the smb-share prefix
from "//<host/share>" to "/smb/<host/share>".  Theoretically, this
should break nothing. unless they have hard-coded paths.

If transitioning of current CYGWIN customers who may have
hardcoded paths is a concern, then a transition plan could be
put into effect (dates TBD):
1) string in envvar CYGWIN, maybe, 'SMB_PRFX="//"'.
   This could be added to any "update" if not defined, or 
   set as 'SMB_PRFX="/smb/"' in new installs or set
   to SMB_PRFX="" by users who want to do their own mounting.
2) When automounting SMB shares is available, then can 
   default SMB PRFX="" in new installs.  Warning in console
   login shells of "SMB_PRFX" being deprecated in favor of
   automount usage.
3) Base install includes smb-automount setup. Usage of SMB_PRFX 
   generates warning about being ignored/obsolete and to use
   automount for smb references (with default "/smb").
4) ...after a few years...remove check for SMB_PRFX...

Steps can be skipped/merged; it may be decided that it is a non-issue and just do it.

For Win32 paths -- again, going with full Win32 compatibility
seems logical since it is the only standard that assigns
meanings to ":\" usage in the Win32 world.  Again, if *really*
needed, one could use a similar transition plan to allow
conversion of apps that make assumptions about C:foobar not
having the standard Win32 meaning (as previously shown, this
is not a property of CMD, and is 'honored' (wherever it is 
implemented) in, AFAIK,  all of MS's programs.

Any issues only affecting Win32 path usage would be unlikely
to affect POSIX-compliant programs using preferred-character-set filenames.

Logical?  Not asking, necessarily, that anyone implement it --
I'm only engaging in a concept discussion.  Actual implementation --
well that may never happen, or may -- may be done by someone
expert in the various areas affected, or done by me (in all my loads of spare time...*cough-cough*).

I'm trying to focus on what I believe would be useful for the
Cygwin toolset to allow for gnu-linux tool porting for the
purpose of using them interactively/transparently in a win32
environment _and_ providing a *nix-POSIX compatibility layer.

Thanks Larry for shedding some light on the past...it's easier to
see how we got here (wherever here is).

Linda

(and all I wanted to do was to find my favorite pen (being
used on something else) that was dropped in the swamp, that
needed to be drained anyway, for cleaning....; re: "up to ears in alligators")

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Christopher Faylor]

On Fri, Jan 10, 2003 at 10:30:23AM -0800, Shankar Unni wrote:
>linda w (cyg) wrote:
>>What were the _original_ design goals of Cygwin -- i.e.  as sponsored
>>by "RedHat"?
>
>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?

Like me, for instance?  I came onboard in '98 and talked to most of the
initial developers who had eventually stampeded away from the (to them)
distasteful duty of working on Windows.  I'd been involved with cygwin
(aka gnu-win32) since early '97.

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

Posix paths were one of the main reasons for cygwin.  The goal was to to
modify tools like gcc and make as little as possible so that Cygnus
could have a Windows toolchain but not force tool developers to deal
with modifying every line of code which assumed that '/foo' meant "the
file foo in the root directory" rather than "the file foo at the root
directory of the current drive" or "the foo option".

I've been managing support for cygwin and have had to answer the "Why
doesn't gcc deal with my c:\include paths very well" questions for
years now.  Most people get the concept once it is explained to them.
YMMV.

So, anyway, fork, exec, and posix paths were the main motivations for
cygwin.  Once I came onboard, you could add signals to that list, too.

But, hey, if you don't believe me, then maybe Larry Hall has more
credibility.  He's been around longer than I.

cgf

RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Larry Hall (RFK Partners, Inc)]

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/

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Shankar Unni]

linda w (cyg) wrote:

> 	What were the _original_ design goals of Cygwin -- i.e. as 
> sponsored by "RedHat"?

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

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Kurt Starsinic]

On Jan 09, linda w (cyg) wrote:
> > 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.

    That's not a feature of the OS, it's a feature of the filesystem.
The fact that Unix-like OS's *typically* use ext2fs/ffs/etc. as their
primary filesystems, and that MS OS's *typically* use, um, any of
about seven filesystems with a variety of case-sensitivity, maximum-
filename-length, valid characterset, path separator, and directory
structure permutations is orthogonal.

    Your sysadmins don't need to learn different path syntaxes for
different *environments*, but they do for different *filesystems*.  You
can mount an HPFS filesystem on a Linux box, and you can mount an FFS
filesystem on a Windows box.  Either way, you will have to cope.

    - Kurt

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Rick Rankin]

--- Christopher Faylor <cgf@redhat.com> wrote:
> On Fri, Jan 10, 2003 at 10:30:23AM -0800, Shankar Unni wrote:
> >linda w (cyg) wrote:
> >>What were the _original_ design goals of Cygwin -- i.e.  as sponsored
> >>by "RedHat"?
> >
> >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?
> 
> Like me, for instance?  I came onboard in '98 and talked to most of the
> initial developers who had eventually stampeded away from the (to them)
> distasteful duty of working on Windows.  I'd been involved with cygwin
> (aka gnu-win32) since early '97.
> 
> >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..
> 
> Posix paths were one of the main reasons for cygwin.  The goal was to to
> modify tools like gcc and make as little as possible so that Cygnus
> could have a Windows toolchain but not force tool developers to deal
> with modifying every line of code which assumed that '/foo' meant "the
> file foo in the root directory" rather than "the file foo at the root
> directory of the current drive" or "the foo option".
> 
> I've been managing support for cygwin and have had to answer the "Why
> doesn't gcc deal with my c:\include paths very well" questions for
> years now.  Most people get the concept once it is explained to them.
> YMMV.
> 
> So, anyway, fork, exec, and posix paths were the main motivations for
> cygwin.  Once I came onboard, you could add signals to that list, too.
> 
> But, hey, if you don't believe me, then maybe Larry Hall has more
> credibility.  He's been around longer than I.
> 

I think I picked up my first GNU-Win32 package around b3 maybe? I seem to
remember discussions about changing the name to GNU-Win32, so I don't even
think that's what it was called when I first got it. Anyway, I recall when the
// convention was added so that //c mapped to C:/, for example, and there was
*much* discussion around the posix standard and its interpretation of the
leading //.  I also recall that there was much weeping, wailing, and gnashing
of teeth when the interpretation of // was changed to what it is now, but
that's another story...

FWIW,

Rick

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[hv]

"linda w \(cyg\)" <cygwin@tlinx.org> wrote:
:	What were the _original_ design goals of Cygwin -- i.e. as 
:sponsored by "RedHat"?

I do not think perl5-porters is the best place to be having that
discussion; perhaps it would be better served by a new thread
in the appropriate forum.

Thanks,

Hugo

Re: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Christopher Faylor]

One would have to wonder...

On Fri, Jan 10, 2003 at 03:25:17PM -0800, 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/

Re: Hindsite, moving forward, concepts...?

[Larry Hall (RFK Partners, Inc)]

At 05:07 PM 1/11/2003, linda w \(cyg\) wrote:

<snip>

>         However the good news is that with the emphasis on applications maintaining POSIX compatibility -- no one
>should be *relying* on "//" having a special meaning.  


If you mean programmatically, I'd say that's probably true.  Some may
have created scripts that make this assumption but I don't see that
as a major issue.



>That being the case, one could choose, in the present, to do a
>simple hack (in the minimal case) to change the smb-share prefix
>from "//<host/share>" to "/smb/<host/share>".  Theoretically, this
>should break nothing. unless they have hard-coded paths.


Right, 'theoretically'.



>If transitioning of current CYGWIN customers who may have
>hardcoded paths is a concern, then a transition plan could be
>put into effect (dates TBD):
>1) string in envvar CYGWIN, maybe, 'SMB_PRFX="//"'.
>    This could be added to any "update" if not defined, or 
>    set as 'SMB_PRFX="/smb/"' in new installs or set
>    to SMB_PRFX="" by users who want to do their own mounting.
>2) When automounting SMB shares is available, then can 
>    default SMB PRFX="" in new installs.  Warning in console
>    login shells of "SMB_PRFX" being deprecated in favor of
>    automount usage.
>3) Base install includes smb-automount setup. Usage of SMB_PRFX 
>    generates warning about being ignored/obsolete and to use
>    automount for smb references (with default "/smb").
>4) ...after a few years...remove check for SMB_PRFX...


Right.  This could be a way to phase out the UNC path convention if
this was desirable.


>Steps can be skipped/merged; it may be decided that it is a non-issue and just do it.
>
>For Win32 paths -- again, going with full Win32 compatibility
>seems logical since it is the only standard that assigns
>meanings to ":\" usage in the Win32 world.  Again, if *really*
>needed, one could use a similar transition plan to allow
>conversion of apps that make assumptions about C:foobar not
>having the standard Win32 meaning (as previously shown, this
>is not a property of CMD, and is 'honored' (wherever it is 
>implemented) in, AFAIK,  all of MS's programs.
>
>Any issues only affecting Win32 path usage would be unlikely
>to affect POSIX-compliant programs using preferred-character-set filenames.
>
>Logical?  Not asking, necessarily, that anyone implement it --
>I'm only engaging in a concept discussion.  Actual implementation --
>well that may never happen, or may -- may be done by someone
>expert in the various areas affected, or done by me (in all my loads of spare time...*cough-cough*).


Logical, yes, in terms of reaching your stated goal.  Whether that goal is
desirable as a whole measured by the community's usage preferences, patterns, 
and needs, that wouldn't be for me to say. ;-)  Of course, the real hitch
is the resource to implement, which you acknowledge.  As you know, lot's 
of things can sound reasonable, logical, and even compelling in theory 
and yet still be abysmal failures once implemented.  But having something
implemented gives the entire community a concrete item to review, reform, 
critique, and accept/reject.  It's generally a very successful route to 
getting new functionality in Cygwin.  I recommend it if you're motivated 
to implement some functionality.


>I'm trying to focus on what I believe would be useful for the
>Cygwin toolset to allow for gnu-linux tool porting for the
>purpose of using them interactively/transparently in a win32
>environment _and_ providing a *nix-POSIX compatibility layer.


I understand.  I'm not sure that I concur with your assessment the current
needs for this work but I'm quite willing to evaluate it based on the 
merits of it's implementation.  Not to 'scare' you of course but changing
behavior of the Cygwin path handling code is not a task to be undertaken
lightly.  This area has allot of logic to parse the various path forms
already handled plus POSIXy emulations.  Any changes there must be rigorously
tested for correctness and performance (i.e. no worse performance than now).
But if that doesn't scare you ( :-) ) then I'd recommend you take the next
step and start poking around in the code.  It really is the best way to 
understand the details of what's there and formulate a real plan of attack.

Good luck,



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX