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

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

[Christopher Faylor]

...why there are two messages with the same body and different
from addresses.

Please fix your configuration problem and stop duplicating your messages.

On Fri, Jan 10, 2003 at 03:27:49PM -0800, linda w (cyg) 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

[lhall]

Ah, yes.  Teeth gnashing!  Those were the good old days! ;-)

Larry


Original Message:
-----------------
From: Rick Rankin rick_rankin@yahoo.com
Date: Fri, 10 Jan 2003 11:44:47 -0800 (PST)
To: cygwin@cygwin.com
Subject: Re: Repost, different list...File::Spec, cygwin, Syntactic vs. 
Semantic path analysis



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

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


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

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

[Elfyn McBratney]

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

You may not have mentioned POSIX but you sure mentioned cygwin. Cygwin
tries to be as POSIX compliant as possible, where possible should i
say. So in this stance `//' would be used by cygwin to access network
shares. Have you ever used a combination of a samba server and the
mount utility on your adventures with "unices"? Also if your going to draw an argument that "Posix != Unix" then Linux != Unix...

Now I've dont it... If this thread is still here in a week I'll have to
sell my sole to Microsoft ;-)

_____________________________________________________________
www.smokeJet.com - Free UK Internet Services

_____________________________________________________________
Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

--
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)]

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

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

[linda w (cyg)]

> 
> 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.
---
	Would you please contact RedHat and have them change the stated purpose of the project?  It's very confusing:

At http://www.redhat.com/software/cygwin/,  it says:

"Cygwin is a set of powerful tools to assist developers in migrating applications from UNIX/Linux to the Windows platform."  

That's the first and primary purpose listed.  Later on, it says " In addition, it provides for a standard UNIX/Linux development environment on Windows including APIs and command shells. The Cygwin.dll library, included with Cygwin, delivers the interesting subset of UNIX SVR4, BSD, and POSIX APIs to enable quick ports of UNIX/Linux applications to the Windows platform."

A stated project *feature* (in the next paragraph) is:

"Standard Windows command line tools can even be intermixed within the UNIX/Linux shell script environment to administer the Windows system. Over the years, UNIX/Linux system administrators have developed a large toolbox set of management scripts for their UNIX/Linux machines. Cygwin provides the ability to continue using these scripts on Windows machines."

	In order to be able to seamlessly integrate cygwin tools with Windows tools in the same shell script environment and apply linux scripts to windows machines -- seamlessly, the linux scripts need to understand Windows pathnames.

	Now maybe you'd like to change "Cygwin" to be something other than what it was intended.  If you really want a linux only environment -- I have had pretty good success with SuSE over the years.  I've even regularly used Vmware to run Windows on top of my linux machine -- for
*years* to provide Win access to my linux files and vice-versa.

	You are trying to change the original design goal of Cygwin by "vehement assertion" -- much like Microsoft tries to change the realities of software ownership and first-sale doctrine by "vehement assertion and threats of "legal bullying" (that logically, would eventually fail under current law...but in our system, it's those who have the most money to pay their warriors (lawyers) full-time to harass you that win their point by forfeit -- not court decision).  MS, historically, on every patent case that they kenw they didn't stand a chance on, when the person was stubborn enough try to 1) buy rights to use the patent, 2) buy the patent, 3) buy the company that owns the patent, 4) negotiate business deals with the company that specify MS gets the patent (or use thereof) if they fall through -- and make the deal look attractive enough that the company is distracted by the 'gold' (fake gold) that appears to be in the deal for them.  Then MS withdraws support, the company dies and MS gets the patent -- again by forfeit.  So far, no one has withstood all of MS's patent acquisition tactics.  It's not that MS is *right*, they just have the loudest and longest lasting voices -- PR department that try to reframe people's idea of what is normal.  If you get enough people to believe a lie for long enough, it can become accepted as truth.

	In this situation, your vehement assertion not withstanding, the origins of the Cygwin project are clearly stated and they are not what you are claiming them to be.


> 
> >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.
---
	More vehement assertion of incorrect facts.
 
> Understanding that the OS uses :\ specially, and that the
> filenames are case preserving but case insensitive, is, of 
> course, necessary. 
---
	No more necessary than it is for you to run Windows.  You could write your own file system layer -- port ext2 to Windows.  Write your own API to the file system.  At the *very* least, you could use a UTF-8 type encoding scheme to encode a 'colon' as some other sequence of bits.  Under NT, there is a local policy that specifies whether or not to enforce case ignorance on all file systems -- you can *choose* not to have case ignored on subsystems that provide upper and lower case.  Perhaps FAT32 as well -- just might not be a backward portable FS to Win98---but
NTFS...*very* likely. 

> Understanding that double slashes at the
> beginning of a path are special is good sense for any 
> portable program.
---
	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 "//" = "/".

	It appears you may be having the 'reactive' feelings about Win32 of a recovering Win32-aholic.  Once you've seen the 'light' of linux, Win32 is now the "villian" to be despised.  Only by viewing linux and Win32 as different in design, both with strengths and weaknesses will you truly be free to pick what is truly useful from both, and ignore the rest. But to be in "reactive" mode against Win32 (as are many Open Source and Linux affectionados (and myself as well in times past), is to ignore the things Win32 does right or better than the Open Source/Linux alternatives.

	You will never truly be free of MS's influence as long as you are emotionally attached one way or the other.


> Again, spending a lot of time worrying about what will happen
> when a user types in a MS-DOS path name is uninteresting.  
---
	To you -- not to the Cygwin project nor me.  You are a divisive element seeking to create division where there need be none.  Rather than unification, peace and healing, you want war.  I suppose you also voted for George Bush.


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

> >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.
===
	Because Win32 users won't understand them and linux/gnu utils won't seamlessly integrate into the win32 environment -- the first and foremost stated goal of the project.

> Maybe your mom is special.
--
	My mom and dad are special -- they taught me to question "common knowledge" and "vehement assertions".  In short, they tried to create something akin to "critical thinking" skills that most adult americans lack. Dogma is an anesthetization of "critical thinking".

> 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.  
---
	Just like they'd jump off a cliff if you told them to, no doubt?
	My parents -- my dad has been trying to use and learning to use a computer for about 5-6 years (he'll be 80 this year).  My mom got her own computer about 2-3 years ago (she'll be 72 this year).  Something else the passed on to me -- a desire to keep learning.  Something most adults tend to stop doing, unless they have to,  as soon as they get out of school. I take classes and read textbooks from diverse fields to try to balance out my engineering background and profession: law, medical, comparative religion, dance, sociology, psychology, finance, politics, philosophy as well as computer related courses as desired. I try to get the widest scope of knowledge I can to see things outside of the perspective of individual or group dogma to be able to create ideas and make decisions outside the 'box'. 
 

> 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.
---
	I'm sorry to hear that.

> 
> 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.
---
	You just contradicted yourself.  You said they are "equivalent" but then you say the "\" causes it to be treated as a "windows" path [which may be, as you pointed out earlier, different, due to, say, the presence of a cygwin mountpoint of C:\<cygdir>\foo on /foo.  They are not equivalent -- as you already have convinced me.  You won't easily convince me to the contrary now, since (of course), I logically verified the statement when I first encountered it.


> 
> So, I don't want to see any of these conversions as part of a
> canonicalization:
> 
> Path		Conversion			## My Comment
> /foo\bar	/foo/bar				## agreed
> /foo/bar	\foo\bar				## agreed
> c:/foo/bar	/cygdrive/c/foo/bar	## agreed
> c:\foo/bar	/cygdrive/c/foo/bar	## agreed
> /cygdrive/c/foo	c:\foo			## agreed
> 
> These are ok:
> 
> path		conversion
> /foo\bar	\foo\bar				## Nope -- "foo" could be a 
							## mounted cygwin file system and
							## changing the initial "/" to "\"
							## could change file handling
							## semantics
> /foo/bar	/foo/bar				## agreed (noop)
> c:/foo/bar	c:\foo\bar			## agreed
> c:\foo/bar	c:\foo\bar			## agreed
> c:\foo\bar	c:/foo/bar	(presence of colon means win32)
							## Yes and no -- did you mean
							## C:/foo/bar -> C:\foo\bar?, 							## since ":" means win32 and 
							## therefore, "\"
> /cygdrive/c/foo	/cygdrive/c/foo		## agreed -- as well as:
							## /cygdrive\c\f -> /cygdrive/c/f

> 
> >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.
							## I may not be correct, but
							## what does it mean to have
							## a windows path mounted in 
							## the middle of a linux path?

 
> 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.
---
	Perhaps an example would explain the misunderstanding:

law/scripts> ls //ishtar/share/music/new
law/scripts>					## empty dir
							## verify write access to music
law/scripts> mv //ishtar/share/music/new //ishtar/share/music/new2 law/scripts> ls -d //ishtar/share/music/new* //ishtar/share/music/new2/ law/scripts> mv //ishtar/share/music/new2 //ishtar/share/music/new
							## verify write access to 'new'
							## and create mount point
law/scripts> mkdir //ishtar/share/music/new/windows
law/scripts> ll //ishtar/share/music/new	## is it what we expect?
total 0
drwxr-xr-x    2 law      Domain A        0 Jan  8 13:30 windows/

							## now for the mount:
law/scripts> mount 'c:\windows\' //ishtar/share/music/new/windows
mount: //ishtar/share/music/new/windows: Invalid argument

							## :-(
Looks like 'bad' magic to me.  Something is protecting the remote path from being mounted.  I can't even do a mount that would be allowed under linux:

tara:root# smbmount //ishtar/share /mnt
Password:
tara:root# mount |grep smb
//ishtar/share on /mnt type smbfs (0)
tara:root# mount |grep windows
/dev/hda2 on /windows/c type vfat (rw,nosuid,nodev,uid=108)
tara:root# mkdir /mnt/music/new/c		## better dirname
tara:root# mount /dev/hda2 /mnt/music/new/c
tara:root# ls /mnt/music/new/c/windows
./                               control.ini*       progman.exe*
../                              convmem.txt*       progman.ini*
3cwmunst.exe*                    convpack.isu*      protman.dos*
...<a win98 windows dir listing>...

---
	I dunno -- seems to me that you can't do a cygwin mount on a remote drive.  Even with //ishtar/share/music mapped to a drive "M", I still
get:

law/scripts> ls M:/new
c/  windows/				## oops, forgot to rmdir 'c' from tara
law/scripts> mount 'c:\windows\' M:/new/windows
mount: M:/new/windows: Invalid argument



> 
> Hmm.  I would think that my vote would count very highly in
> the matter of what is right or wrong for cygwin.
---
	Maybe so, maybe you own cygwin...I don't know.  I'm only some random idiot that was trying to use it for the defined purpose on the RH Cygwin page -- porting tools to the Win32 env.  The specs may be wrong -- you may be God for all I know, but I would blythely argue with God if I thought he was wrong on something.  These issues should be decidable by logic and logical design decisions, not emotional or vehement argument.


>> >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.
---
	Maybe...I live on the edge quite a bit...:-)

> 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.
---
	Gotcha!  I very much agree -- a symantic parse of a unix path 
should yield up fs's in the 'volume' field, though not with a 
'syntactic' parse.

> 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.
---
	Exactly -- no problem.

> 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.
----
	Well, Houston, we have a slight problem here.  But it's cygwin only, so as not to clutter the perl list w/non perlese.... (somehow I felt a discussion of what was appropriate for cygwin in perl as some merging of unix/win32 functionality was appropriate for both lists...)

	But suffice it to say that the semantics of "\" meaning it
is a "win32" path may be getting misapplied or confused somewhere. While I really like the cleanliness of the Christopher's idea of "\" 
meaning "win32", it may not be so clean...but maybe I'm just confused...I never know...:-)

-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

[LA Walsh]

> 
> 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.
---
	Would you please contact RedHat and have them change the
stated purpose of the project?  It's very confusing:

At http://www.redhat.com/software/cygwin/,  it says:

"Cygwin is a set of powerful tools to assist developers in migrating
applications from UNIX/Linux to the Windows platform."  

That's the first and primary purpose listed.  Later on, it says
" In addition, it provides for a standard UNIX/Linux development environment on
Windows including APIs and command shells. The Cygwin.dll library, included with
Cygwin, delivers the interesting subset of UNIX SVR4, BSD, and POSIX APIs to
enable quick ports of UNIX/Linux applications to the Windows platform."

A stated project *feature* (in the next paragraph) is:

"Standard Windows command line tools can even be intermixed within the
UNIX/Linux shell script environment to administer the Windows system. Over the
years, UNIX/Linux system administrators have developed a large toolbox set of
management scripts for their UNIX/Linux machines. Cygwin provides the ability to
continue using these scripts on Windows machines."

	In order to be able to seamlessly integrate cygwin tools with
Windows tools in the same shell script environment and apply linux
scripts to windows machines -- seamlessly, the linux scripts need to
understand Windows pathnames.

	Now maybe you'd like to change "Cygwin" to be something other than
what it was intended.  If you really want a linux only environment --
I have had pretty good success with SuSE over the years.  I've even
regularly used Vmware to run Windows on top of my linux machine -- for
*years* to provide Win access to my linux files and vice-versa.

	You are trying to change the original design goal of Cygwin by
"vehement assertion" -- much like Microsoft tries to change the realities
of software ownership and first-sale doctrine by "vehement assertion and
threats of "legal bullying" (that logically, would eventually fail under
current law...but in our system, it's those who have the most money to pay their
warriors (lawyers) full-time to harass you that win their point
by forfeit -- not court decision).  MS, historically, on every patent case
that they kenw they didn't stand a chance on, when the person was stubborn
enough try to 1) buy rights to use the patent, 2) buy the patent, 3) buy the
company that owns the patent, 4) negotiate business deals with the company that
specify MS gets the patent (or use thereof) if they fall through -- and make the
deal look attractive enough that the company is distracted by the 'gold' (fake
gold) that appears to be in the deal for them.  Then MS withdraws support, the
company dies and MS gets the patent -- again by forfeit.  So far, no one has
withstood all of MS's patent acquisition tactics.  It's not that MS is *right*,
they just have the loudest and longest lasting voices -- PR department that try
to reframe people's idea of what is normal.  If you get enough people to believe
a lie for long enough, it can become accepted as truth.

	In this situation, your vehement assertion not withstanding, the origins
of the Cygwin project are clearly stated and they are not what you are claiming
them to be.


> 
> >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.
---
	More vehement assertion of incorrect facts.
 
> Understanding that the OS uses :\ specially, and that the 
> filenames are case preserving but case insensitive, is, of 
> course, necessary. 
---
	No more necessary than it is for you to run Windows.  You could write
your own file system layer -- port ext2 to Windows.  Write your own
API to the file system.  At the *very* least, you could use a UTF-8 type
encoding scheme to encode a 'colon' as some other sequence of bits.  Under NT,
there is a local policy that specifies whether or not to enforce
case ignorance on all file systems -- you can *choose* not to have
case ignored on subsystems that provide upper and lower case.  Perhaps
FAT32 as well -- just might not be a backward portable FS to Win98---but
NTFS...*very* likely. 

> Understanding that double slashes at the 
> beginning of a path are special is good sense for any 
> portable program.
---
	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 "//" = "/".

	It appears you may be having the 'reactive' feelings about Win32
of a recovering Win32-aholic.  Once you've seen the 'light' of linux,
Win32 is now the "villian" to be despised.  Only by viewing linux and
Win32 as different in design, both with strengths and weaknesses will you
truly be free to pick what is truly useful from both, and ignore the rest.
But to be in "reactive" mode against Win32 (as are many Open Source and
Linux affectionados (and myself as well in times past), is to ignore the things
Win32 does right or better than the Open Source/Linux alternatives.

	You will never truly be free of MS's influence as long as you are
emotionally attached one way or the other.


> Again, spending a lot of time worrying about what will happen 
> when a user types in a MS-DOS path name is uninteresting.  
---
	To you -- not to the Cygwin project nor me.  You are a divisive
element seeking to create division where there need be none.  Rather than
unification, peace and healing, you want war.  I suppose you also voted
for George Bush.


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

> >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.
===
	Because Win32 users won't understand them and linux/gnu utils won't
seamlessly integrate into the win32 environment -- the first and foremost stated
goal of the project.

> Maybe your mom is special.  
--
	My mom and dad are special -- they taught me to question "common
knowledge" and "vehement assertions".  In short, they tried to create something
akin to "critical thinking" skills that most adult americans lack.
Dogma is an anesthetization of "critical thinking".

> 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.  
---
	Just like they'd jump off a cliff if you told them to, no doubt?
	My parents -- my dad has been trying to use and learning to use
a computer for about 5-6 years (he'll be 80 this year).  My mom got her own
computer about 2-3 years ago (she'll be 72 this year).  Something else
the passed on to me -- a desire to keep learning.  Something most adults tend to
stop doing, unless they have to,  as soon as they get out of school.
I take classes and read textbooks from diverse fields to try to balance out my
engineering background and profession: law, medical, comparative religion,
dance, sociology, psychology, finance, politics, philosophy as well as computer
related courses as desired. I try to get the widest scope of knowledge I can to
see things outside of the perspective of individual or group dogma to be able to
create ideas and make decisions outside the 'box'. 
 

> 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.
---
	I'm sorry to hear that.

> 
> 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.
---
	You just contradicted yourself.  You said they are "equivalent"
but then you say the "\" causes it to be treated as a "windows" path
[which may be, as you pointed out earlier, different, due to, say, the presence
of a cygwin mountpoint of C:\<cygdir>\foo on /foo.  They
are not equivalent -- as you already have convinced me.  You won't
easily convince me to the contrary now, since (of course), I logically
verified the statement when I first encountered it.


> 
> So, I don't want to see any of these conversions as part of a
> canonicalization:
> 
> Path		Conversion			## My Comment
> /foo\bar	/foo/bar				## agreed
> /foo/bar	\foo\bar				## agreed
> c:/foo/bar	/cygdrive/c/foo/bar	## agreed
> c:\foo/bar	/cygdrive/c/foo/bar	## agreed
> /cygdrive/c/foo	c:\foo			## agreed
> 
> These are ok:
> 
> path		conversion
> /foo\bar	\foo\bar				## Nope -- "foo" could
be a 
							## mounted cygwin file
system and
							## changing the initial
"/" to "\"
							## could change file
handling
							## semantics
> /foo/bar	/foo/bar				## agreed (noop)
> c:/foo/bar	c:\foo\bar			## agreed
> c:\foo/bar	c:\foo\bar			## agreed
> c:\foo\bar	c:/foo/bar	(presence of colon means win32)
							## Yes and no -- did you
mean
							## C:/foo/bar ->
C:\foo\bar?, 							## since ":"
means win32 and 
							## therefore, "\"
> /cygdrive/c/foo	/cygdrive/c/foo		## agreed -- as well as:
							## /cygdrive\c\f ->
/cygdrive/c/f

> 
> >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.
							## I may not be correct,
but
							## what does it mean to
have
							## a windows path
mounted in 
							## the middle of a linux
path?

 
> 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.
---
	Perhaps an example would explain the misunderstanding:

law/scripts> ls //ishtar/share/music/new
law/scripts>					## empty dir
							## verify write access
to music
law/scripts> mv //ishtar/share/music/new //ishtar/share/music/new2
law/scripts> ls -d //ishtar/share/music/new*
//ishtar/share/music/new2/
law/scripts> mv //ishtar/share/music/new2 //ishtar/share/music/new
							## verify write access
to 'new'
							## and create mount
point
law/scripts> mkdir //ishtar/share/music/new/windows
law/scripts> ll //ishtar/share/music/new	## is it what we expect?
total 0
drwxr-xr-x    2 law      Domain A        0 Jan  8 13:30 windows/

							## now for the mount:
law/scripts> mount 'c:\windows\' //ishtar/share/music/new/windows
mount: //ishtar/share/music/new/windows: Invalid argument

							## :-(
Looks like 'bad' magic to me.  Something is protecting the remote
path from being mounted.  I can't even do a mount that would be
allowed under linux:

tara:root# smbmount //ishtar/share /mnt
Password:
tara:root# mount |grep smb
//ishtar/share on /mnt type smbfs (0)
tara:root# mount |grep windows
/dev/hda2 on /windows/c type vfat (rw,nosuid,nodev,uid=108)
tara:root# mkdir /mnt/music/new/c		## better dirname
tara:root# mount /dev/hda2 /mnt/music/new/c
tara:root# ls /mnt/music/new/c/windows
./                               control.ini*       progman.exe*
../                              convmem.txt*       progman.ini*
3cwmunst.exe*                    convpack.isu*      protman.dos*
...<a win98 windows dir listing>...

---
	I dunno -- seems to me that you can't do a cygwin mount on a remote
drive.  Even with //ishtar/share/music mapped to a drive "M", I still
get:

law/scripts> ls M:/new
c/  windows/				## oops, forgot to rmdir 'c' from tara
law/scripts> mount 'c:\windows\' M:/new/windows
mount: M:/new/windows: Invalid argument



> 
> Hmm.  I would think that my vote would count very highly in 
> the matter of what is right or wrong for cygwin.
---
	Maybe so, maybe you own cygwin...I don't know.  I'm only some
random idiot that was trying to use it for the defined purpose on the
RH Cygwin page -- porting tools to the Win32 env.  The specs may be
wrong -- you may be God for all I know, but I would blythely argue
with God if I thought he was wrong on something.  These issues should
be decidable by logic and logical design decisions, not emotional
or vehement argument.


>> >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.
---
	Maybe...I live on the edge quite a bit...:-)

> 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.
---
	Gotcha!  I very much agree -- a symantic parse of a unix path 
should yield up fs's in the 'volume' field, though not with a 
'syntactic' parse.

> 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.
---
	Exactly -- no problem.

> 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.
----
	Well, Houston, we have a slight problem here.  But it's cygwin
only, so as not to clutter the perl list w/non perlese....
(somehow I felt a discussion of what was appropriate for cygwin
in perl as some merging of unix/win32 functionality was appropriate
for both lists...)

	But suffice it to say that the semantics of "\" meaning it
is a "win32" path may be getting misapplied or confused somewhere.
While I really like the cleanliness of the Christopher's idea of "\" 
meaning "win32", it may not be so clean...but maybe I'm just
confused...I never know...:-)

-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

[Christopher Faylor]

I'm sure that everyone in perl5-porters is sick of this discussion
(although I think I remember similar discussions from the days when I
was an occasional contributor) and so I apologize.

Let me make some points and then I'll shut up:

1) I'm the person who currently sets the direction of the cygwin
   project.  I'm also the primary technical contributor to cygwin
   and I have been for several years.  FWIW, I'm also sort of running
   sources.redhat.com these days.

2) I was wrong in some of my assertions of how cygwin handles paths.
   I won't go into details.  I should have checked more thoroughly and
   I apologize for contributing to confusion.  The next version of cygwin
   will match the table that I had sent in my previous email.

3) To mount a remote share, you do this:

    mount //remote/share/bob /whatever/bob

   To mount a local directory you do this:

    mount c:/hello/bob /hi/bob

   The second argument to mount can't start with two slashes.
   It doesn't have backslashes or colons.

That's it for me.
cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sources.redhat.com
and be permanently blocked from mailing lists at sources.redhat.com

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

[Robert Collins]

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

Sorry for butting in again, but you have a factual error that needs
highlighting.

On Thu, 2003-01-09 at 13:18, linda w (cyg) wrote:

> > Understanding that double slashes at the
> > beginning of a path are special is good sense for any 
> > portable program.
> ---
> 	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.

Growing up on unix does NOT mean // == /. If you assume that *anywhere*
you will limit your programs portability (specifically, you are
IMMEDIATELY non-posix).


> Dogma is an anesthetization of "critical thinking".

Just curious, if that is the case, why do you make vehement assertions
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: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis

[Christopher Faylor]

On Wed, Jan 08, 2003 at 03:30:25PM +0100, H.Merijn Brand wrote:
>On Wed 08 Jan 2003 05:56, Christopher Faylor <cgf-cygwin@cygwin.com> wrote:
>> >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.
>
>Sorry to drop in like this,

No problem.

>but how much influence do you have in Cygwin?

I'm the head of the project.

>How much are you aware that 1.3.18-1 does fail in the current smokes where
>1.3.16 passed? Gerrit seems to be quite busy these days.

I wasn't aware of that but then I haven't been reading perl5-porters for a while
now.  I don't know what smokes is but I assume it's a periodic test run of perl
on various platforms.

Are you up for trying a cygwin snapshot?  http://cygwin.com/snapshots/

There were a few problems fixed for the next release that will be reflected in
the latest snapshot.

>What's the stance of cygwin in threading?

We're for it!  We have pretty extensive pthreads support.

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/

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

[Robert Collins]

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

On Mon, 2003-01-06 at 19:30, Elfyn McBratney wrote:

> Although the win32 api supports both one takes more work as paths
> containing forward-slashes are converted to back-slashes*. I know this
> is being petty but if different style paths cause problems surely it
> would make sense to follow the standard the OS follows?

Right, so:
Perl for Cygwin uses "/"
Perl for win32 uses "\" and ":".

Seems pretty straight forward to me.

Cygwin may be 'just a partial posix layer', but if you are compiling for
it, you should use "/" delimited paths.

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: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis

[Benjamin Goldberg]

Jos I. Boumans wrote:
> Gurusamy Sarathy wrote:
> > I agree with most of your points, and in particular with the one
> > above.  I consider File::Spec::Win32 currently broken because it
> > hijacks all paths and turns them into the backslashed variety, which
> > is completely wrong from the portability POV.  (By which I mean that
> > utilities written for UNIX that would otherwise work on windows are
> > now broken because of this change.)
> 
> The biggest problem with File::Spec::Win32 right now is the fact that
> it will allow _both_ types of slashes in a path. This has lead to bugs
> like report
> [19213] [http://rt.perl.org/rt2/Ticket/Display.html?id=19213]

Personally, I think that that is *not* a bug, even if it looks like one.
Whenever one writes require BAREWORD, it is passed a "path/file.pm" type
string -- it's \Ualways\E a unix style path, even on windows or vms or
any other OS; internally, it gets translated from a unix style path to a
platform-appropriate path.  Thus, if you want to require() something
produced by catfile, you should write:

   use File::Spec::Unix;
   my $file = File::Spec::Unix->catfile("GetOpt","Long.pm");
   require $file;

Using F::S::U, not F::S.

> For portabillity, it would be fine if either a path would be
> represented as c:\perl\5.8.0\bin\perl.exe or
> c:/perl/5.8.0/bin/perl.exe but never as
> c:\perl\5.8.0/bin/perl.exe

When used with the underlying system calls for open, creat, unlink, etc,
don't all of these work equally well?  It seems that it's a waste of
effort to go about canonicalizing them if the user hasn't explicitly
asked to do that with canonpath().

[snip]
> I'm not sure this should be the preferred way, since you are not
> guaranteed to be able to compare paths anymore (which is what F::S is
> often used for), since one path may have been generated on the same
> machine with the '/' pathsep setting, and the other with a '\'
> setting, depending on the programmer's whim..

If a programmer wants to compare paths, then he should be forced to
transform them into canonical paths, with canonpath.  That's what it's
there for, after all.

> Note that you can always call File::Spec::Unix->catfile() explicitly
> to get the unix version.
> 
> So I think a fix could to change F::S::Win32 to convert all win32
> pathseperators to unix pathseperators, and hand it off to F::S::Unix
> to do the actual catfile(), etc calls...

But paths delimited with forward slashes instead of backslashes get
interpreted wrong by command.com.

<IDEA type="wild" subtype="unlikely">Hmm... how about, forward slashes
get produced everywhere, *but*, we also provide a new F::S method
'shellquote' which on Windows, changes forward slashes to backslashes,
and puts quotes around the whole thing if there are spaces in the path,
and on unix, simply calls quotemeta to quote the spaces.  (And maybe on
VMS, uses some DWIM hueristic to tell if it's been passed a unix-style
path, and if so, changes it to a proper VMS path).  A path which has
been shellquote()ed could then be safely used in system(STRING) without
fear that it will be seperated into multiple arguments or flags or
whatever.</IDEA>

-- 
$..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
$..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
$.=~s'!'haktrsreltanPJ,r  coeueh"';BEGIN{${"\cH"}
|=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);

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

[Hack Kampbjorn]

LA Walsh wrote:
> Cygwin, and possibly, the Win32 module, are inconsistent in handling
> the differences between i:/foobar/ and i:.  On one hand i: is
> considered a 'volume' but on the other hand i:/ seems to evaluate to
> the same, incorrect, value. In "Win32", each 'fs' of form "<x>:', x
> of class <[:alpha:]>, there is a process-specific "current
> directory".  This can be seen by:
> 
In the old DOS days yes, but in Win32 there is only one current 
directory. The illusion of having a current directory per drive and an 
active drive is maintained in cmd.exe (or is it in the MS C runtime?). 
As cygwin doesn't use it, i:foobar and i:/foobar is always the same.

<deleted long list of tests that demostrate this/>

-- 
Med venlig hilsen / Kind regards

Hack Kampbjørn


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

[Christopher Faylor]

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/

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

[H.Merijn Brand]

On Wed 08 Jan 2003 05:56, Christopher Faylor <cgf-cygwin@cygwin.com> wrote:
> >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.

Sorry to drop in like this, but how much influence do you have in Cygwin?
How much are you aware that 1.3.18-1 does fail in the current smokes where
1.3.16 passed? Gerrit seems to be quite busy these days.


Automated smoke report for patch 18456                               cc            gcc
                                                      | HP-UX 11.00  B.11.11.06    3.3   32-bit
O = OK                                                |                            3.3   64-bit +GNUld
F = Failure(s), extended report at the bottom         | HP-UX 10.20  A.10.32.30    3.2  
? = still running or test results not (yet) available | AIX 4.3.3.0  vac 5.0.2.6   3.1.1
Build failures during:       - = unknown,   = skipped | AIX 4.2.1.0  xlc 3.1.4.10  3.1.1
    c = Configure, m = make, t = make test-prep       | Cygwin 1.3.18              3.2-3

 HP-UX    HP-UX    HP-UX    HP-UX     AIX      AIX    cygwin  
 11.00    11.00    10.20    10.20    4.3.3    4.3.3   1.3.18-1  
  HPc      gcc      HPc      gcc      vac      gcc      gcc   
 18456    18456    18456    18456    18456    18453    18456   Configuration
-------  -------  -------  -------  -------  -------  -------  --------------------------------------------------------------------
O O O O  O O O O  O O O O  O O O O  O O O O  O O O O  F F F F   
O O O O  O O O O                    O O O O  O O O O  F F F F  -Duse64bitint
O O O O  O O O O                                      . . . .  -Duse64bitall
O O O O  O O O O  O O O O  O O O O  O O ? ?  O O O O  F F F F  -Duselongdouble
O O O O  O O O O                    ? ? ? ?           F F F F  -Dusemorebits
O O O O  O O O O                    ? ? ? ?           . . . .  -Duse64bitall -Duselongdouble
| |                            | |
| +----- PERLIO = perlio       | +- PERLIO = perlio -DDEBUGGING
+------- PERLIO = stdio        +--- PERLIO = stdio  -DDEBUGGING

Failures:

Cygwin 1.3   stdio             
Cygwin 1.3   stdio/perlio     -DDEBUGGING  
Cygwin 1.3   perlio           -Duse64bitint
Cygwin 1.3   stdio/perlio     -Duselongdouble
Cygwin 1.3   stdio            -Dusemorebits
    lib/IPC/Open3 ....................... 22
    lib/Test/Harness/t/strap-analyze .... 2
    lib/warnings ........................ 413-415
    t/op/alarm .......................... 1-4

Cygwin 1.3   perlio            
Cygwin 1.3   perlio           -Dusemorebits
Cygwin 1.3   stdio/perlio     -DDEBUGGING -Dusemorebits
    lib/IPC/Open3 ....................... 22
    lib/Test/Harness/t/strap-analyze .... 2
    lib/warnings ........................ 413-415

What's the stance of cygwin in threading?

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE: smokers@perl.org
http://archives.develooper.com/daily-build@perl.org/   perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org



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

[Elfyn McBratney]

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

> Right, so:
> Perl for Cygwin uses "/"
> Perl for win32 uses "\" and ":".
>
> Seems pretty straight forward to me.
>
> Cygwin may be 'just a partial posix layer', but if you are compiling > for it, you should use "/" delimited paths.

And thats just what I meant to end with before hitting that send button. *Slap*

Elfyn
elfyn@exposure.org.uk


--- message from Robert Collins <rbcollins@cygwin.com> attached:

_____________________________________________________________
www.smokeJet.com - Free UK Internet Services

_____________________________________________________________
Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

[-- Attachment #2: Type: message/rfc822, Size: 3019 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 643 bytes --]

On Mon, 2003-01-06 at 19:30, Elfyn McBratney wrote:

> Although the win32 api supports both one takes more work as paths
> containing forward-slashes are converted to back-slashes*. I know this
> is being petty but if different style paths cause problems surely it
> would make sense to follow the standard the OS follows?

Right, so:
Perl for Cygwin uses "/"
Perl for win32 uses "\" and ":".

Seems pretty straight forward to me.

Cygwin may be 'just a partial posix layer', but if you are compiling for
it, you should use "/" delimited paths.

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

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

[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

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

[Christopher Faylor]

On Mon, Jan 06, 2003 at 02:02:31AM +0100, Hack Kampbjorn wrote:
>LA Walsh wrote:
>>Cygwin, and possibly, the Win32 module, are inconsistent in handling
>>the differences between i:/foobar/ and i:.  On one hand i: is
>>considered a 'volume' but on the other hand i:/ seems to evaluate to
>>the same, incorrect, value. In "Win32", each 'fs' of form "<x>:', x
>>of class <[:alpha:]>, there is a process-specific "current
>>directory".  This can be seen by:
>>
>In the old DOS days yes, but in Win32 there is only one current 
>directory. The illusion of having a current directory per drive and an 
>active drive is maintained in cmd.exe (or is it in the MS C runtime?). 
>As cygwin doesn't use it, i:foobar and i:/foobar is always the same.
>
><deleted long list of tests that demostrate this/>

Right.  Even though I rely on the behavior (which is a feature of the
MS-DOS/Win9x OS and the Windows NT command line shells) on Windows, it
has no business in cygwin.  If you want somewhat similar behavior use
pushd/popd.

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/

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

[Robert Collins]

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

On Mon, 2003-01-06 at 20:52, LA Walsh wrote:


> 	Do you think this is proper behavior?  Do you think a win32 person being
> introduced to posix/gnu utils would find this beneficial?  Do you think
> a linux person who uses some combination of cygwin and Win utils would find
> this beneficial?  

Doctor, it hurts when I poke my eye..

Patient, don't do that.

Cygwin is a layer, and if you want to violate that layer, expect
somethings to need careful accomodation. If you want a win32 'normal'
vim, download a win32 vim binary.

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: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis

[LA Walsh]

> -----Original Message-----
> From: Hack Kampbjorn [mailto:cygwin@hack.kampbjorn.com] 

> > Cygwin, and possibly, the Win32 module, are inconsistent in 
> handling 
> > the differences between i:/foobar/ and i:.  On one hand i: is 
> > considered a 'volume' but on the other hand i:/ seems to 
> evaluate to 
> > the same, incorrect, value. In "Win32", each 'fs' of form 
> "<x>:', x of 
> > class <[:alpha:]>, there is a process-specific "current 
> directory".  
> > This can be seen by:
> > 
> In the old DOS days yes, but in Win32 there is only one current 
> directory. The illusion of having a current directory per 
> drive and an 
> active drive is maintained in cmd.exe (or is it in the MS C 
> runtime?). 

====
	Most programs seem to recognize this convention, for example, "notepad.exe",  "win32-GVIM", Adobe Acrobat, vbs scripts.  

	Do you know of any programs that don't behave this way?

> As cygwin doesn't use it, i:foobar and i:/foobar is always the same.
---
	Always?  Like when 'foobar' = '*'?

law> echo z:*
z:*
law> echo z:/*
z:/Content.IE5 z:/OLKAD7 z:/desktop.ini z:/foo z:/stardock_activedesktop.pdf z:/
which.txt


	IMO, this is "wrong" behavior:

1)
C:\>dir /a /b z:
foo.txt
foobar.txt
foobar.txt.000
stardock_activedesktop.pdf

C:\>ls z:
Content.IE5  OLKAD7  desktop.ini  foo  stardock_activedesktop.pdf

2) Take your pick -- if I launch bash from the above CMD.EXE -- bash
will ignore win32's curdir for Z:, but if then launch a win32 app like
Gvim, directly from bash and write a file "z:new", then when I exit gvim 
and do an "ls z:" the file isn't there.  That's inconsistent with the underlying
OS's concept of a current dir/drive.  It's not just in 'cmd.exe' -- more likely
in USER.DLL or some such, which pretty much makes it a part of the OS.


law> /c/Program\ Files/Vim/vim61/gvim.exe (write out blank file to "z:new")
law> ls z:
Content.IE5/  OLKAD7/  desktop.ini  foo/  stardock_activedesktop.pdf  which.txt
law> ls z:foo
foo.txt     foobar.txt.000  new.000                     which.txt
foobar.txt  new             stardock_activedesktop.pdf
law>

	Do you think this is proper behavior?  Do you think a win32 person being
introduced to posix/gnu utils would find this beneficial?  Do you think
a linux person who uses some combination of cygwin and Win utils would find
this beneficial?  

-l




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

[Jos I. Boumans]

Gurusamy Sarathy wrote:
> I agree with most of your points, and in particular with the one above.
> I consider File::Spec::Win32 currently broken because it hijacks all
> paths and turns them into the backslashed variety, which is completely
> wrong from the portability POV.  (By which I mean that utilities written
> for UNIX that would otherwise work on windows are now broken because of
> this change.)

The biggest problem with File::Spec::Win32 right now is the fact that it 
will allow _both_ types of slashes in a path. This has lead to bugs like
report [19213] [http://rt.perl.org/rt2/Ticket/Display.html?id=19213]

For portabillity, it would be fine if either a path would be represented 
as c:\perl\5.8.0\bin\perl.exe or c:/perl/5.8.0/bin/perl.exe but never as
c:\perl\5.8.0/bin/perl.exe

Imho, a fix to F::S::Win32 that would consistently change paths to ANY 
standard seems like the best solution. As the below script shows, even
unix paths work just fine (noting that this is tested on win2000 with 
cmd.exe):

#######################################################################

#! perl -wl
use File::Spec::Unix;

my $perl = File::Spec::Unix->catfile( qw[c: perl 5.8.0 bin perl.exe] );

print $perl;                                # c:/perl/5.8.0/bin/perl.exe
print "found" if -x $perl;                  # found
system(qq[$perl -le"print 'hello world'"]); # hello world

########################################################################

> As far as the Win32 native port goes (I'm not really that cygwin-savvy to
> comment on what should happen for that port) I like to see:
> 
>   * Where there is a prior hint for what the directory separator should
>     be (either in the form of (0) an explicit argument specifying the
>     separator, or failing that (1) a module/class variable, or failing that
>     (2) a preexisting directory separator in one of the path arguments),
>     File::Spec should use that for catenating/canonicalizing paths.

I'm not sure this should be the preferred way, since you are not 
guaranteed to be able to compare paths anymore (which is what F::S is 
often used for), since one path may have been generated on the same 
machine with the '/' pathsep setting, and the other with a '\' setting, 
depending on the programmer's whim..

Note that you can always call File::Spec::Unix->catfile() explicitly to 
get the unix version.

So I think a fix could to change F::S::Win32 to convert all win32 
pathseperators to unix pathseperators, and hand it off to F::S::Unix
to do the actual catfile(), etc calls...

If we can agree on this, I'll happily provide the patch.

>   * Where there is no such hint available, File::Spec should default to
>     using '/' as the dirsep (which is the portable default and hence
>     should always be the preferred one).  Note that this was the
>     situation in 5.6.1 and before, so I'm not really that much worried
>     about "breaking" the new behavior/bugs.

-- 

Jos Boumans

How do I prove I am not crazy to people who are?

CPANPLUS			http://cpanplus.sf.net
Just another perl hacker	http://japh.nu


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

[Christopher Faylor]

On Mon, Jan 06, 2003 at 09:43:30AM -0800, LA Walsh wrote:
>So it seems that 'syntactically', one can't always determine if a "/" is
>invalid in a straight win32 environment -- at least not when a network name
>is involved, but I'd agree it is pathological and should be ignored (and
>documented as ignored for pathological share names)

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.

>So I'd suggest the following:
>
>I. 
>Win32 syntactic normalization should always proceed to return "\".
>
>Cygwin is a Posix compatibility layer for Win32, though -- it isn't 
>supposed to be a complete replacement/invalidation of the underlying Win32
>layer -- unless one wants to declare that "e:foobar" only can reference a
>file and simulate "foobar\fee" as a valid file (through some mechanism).
>
>For cygwin to be a useful constructor of utils -- it should hand both Posix
>names *and* win32 names.  Normalization can return "/" for any filename that
>doesn't have, say, a <colon> in it -- but ... no... I agree it should always
>return "/" for _syntactic_ normalization....and *document* that "\" will be
>converted to / even if a remote fs allows "\" as a filename character.

You could take the radical approach of having a cygwin perl module
reject backslashes and colons entirely.  Whatever you do *please* do not
make the mistake of converting slashes to backslashes in anything that
is seen by cygwin functions.  If you convert backslashes to slashes then
you will be introducing an inconsistency between the way cygwin handles
these types of paths and the way the perl module interprets them.  Backslashes
and colons in paths short-circuit mount table operations in cygwin.  So,
\usr\bin is not equivalent to /usr/bin.

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.

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/

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

[LA Walsh]

> Gurusamy Sarathy wrote:
> > I agree with most of your points, and in particular with the one 
> > above. I consider File::Spec::Win32 currently broken because it 
> > hijacks all paths and turns them into the backslashed 
> variety, which 
> > is completely wrong from the portability POV.  (By which I 
> mean that 
> > utilities written for UNIX that would otherwise work on windows are 
> > now broken because of this change.)
> 
> The biggest problem with File::Spec::Win32 right now is the 
> fact that it 
> will allow _both_ types of slashes in a path. This has lead 
> to bugs like report [19213] 
> [http://rt.perl.org/rt2/Ticket/Display.html?id=19213]
> 
> For portabillity, it would be fine if either a path would be 
> represented 
> as c:\perl\5.8.0\bin\perl.exe or c:/perl/5.8.0/bin/perl.exe 
> but never as c:\perl\5.8.0/bin/perl.exe
---
	If a user calls the 'normalize' function, it should convert it to
"\" -- since that is the OS standard/default -- HOWEVER...

	the OS accepts *either* -- so having Win32 accept paths that contain
either is valid.  File Spec is supposed to provide a way to manipulate
paths that are valid on a particular OS.  It isn't a supposed to be a
"please convert me to posix, unix, or some form that someone thinks Win should
have used".

	In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'.  You have
to quote the "/" so it won't be interpreted as a switch character -- but 
the underlying OS seems to not really care which you use and neither should
Win32.

	As for the bug -- it is a red-herring issue -- the user calls the
OS normal form for generating a pathname, then Perl itself choose not to
use the OS normal form for its internally generated paths.  I don't think it
is a bug to use either -- bug certainly specifying the same library twice by
two separate names shouldn't cause a core dump in any event.

-l


-----------------------


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

[Gurusamy Sarathy]

On Sun, 05 Jan 2003 21:10:09 +0100, "Jos I. Boumans" wrote:
>Gurusamy Sarathy wrote:
>> I agree with most of your points, and in particular with the one above.
>> I consider File::Spec::Win32 currently broken because it hijacks all
>> paths and turns them into the backslashed variety, which is completely
>> wrong from the portability POV.  (By which I mean that utilities written
>> for UNIX that would otherwise work on windows are now broken because of
>> this change.)
>
>The biggest problem with File::Spec::Win32 right now is the fact that it 
>will allow _both_ types of slashes in a path. This has lead to bugs like
>report [19213] [http://rt.perl.org/rt2/Ticket/Display.html?id=19213]
>
>For portabillity, it would be fine if either a path would be represented 
>as c:\perl\5.8.0\bin\perl.exe or c:/perl/5.8.0/bin/perl.exe but never as
>c:\perl\5.8.0/bin/perl.exe

Agreed!

[snip example]

>> As far as the Win32 native port goes (I'm not really that cygwin-savvy to
>> comment on what should happen for that port) I like to see:
>> 
>>   * Where there is a prior hint for what the directory separator should
>>     be (either in the form of (0) an explicit argument specifying the
>>     separator, or failing that (1) a module/class variable, or failing that
>>     (2) a preexisting directory separator in one of the path arguments),
>>     File::Spec should use that for catenating/canonicalizing paths.
>
>I'm not sure this should be the preferred way, since you are not 
>guaranteed to be able to compare paths anymore (which is what F::S is 
>often used for),

I don't see this as a big deal.  Path comparisons could always be done
via a File::Spec method that normalizes the slashes before comparison.

Where the script is exclusively using UNIX style pathnames, it would
be free to use eq to efficiently compare things without having to
worry about File::Spec corrupting the slash style.

>since one path may have been generated on the same 
>machine with the '/' pathsep setting, and the other with a '\' setting, 
>depending on the programmer's whim..
>
>Note that you can always call File::Spec::Unix->catfile() explicitly to 
>get the unix version.

I don't see this as a good futureproof API solution, given that we can't
make any guarantees about File::Spec::Unix not wanting to "correct" UNC
paths or handling the catenation of paths with drive letters in
them correctly (I don't want to end up with /foo/bar/c:/some/thing--that
should be an error).

>So I think a fix could to change F::S::Win32 to convert all win32 
>pathseperators to unix pathseperators, and hand it off to F::S::Unix
>to do the actual catfile(), etc calls...

Sounds fine, as long as we still do the right thing when handed paths
with backslashes in them (i.e. result should have backslashes too).
I'm not much worried about how the internal implementation is done
(at least for now :) as long as the interface and semantic guarantees
are correct.

So yes, I think we're generally in agreement here.


Sarathy
gsar@ActiveState.com

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

[Elfyn McBratney]

>	If a user calls the 'normalize' function, it should convert it
>to "\" -- since that is the OS standard/default -- HOWEVER...

I tend to agree that as windows uses the back-slash as a default path
seperator so should `normalize' but also in the interest of
compatability with windows 95 (in dos mode) as it doesn't support the
forward-slash path seperator.

>	In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'. 
>You have to quote the "/" so it won't be interpreted as a switch
>character -- but the underlying OS seems to not really care which you
>use and neither should Win32.

A bit OT but dir does not support the forward slash pathsep even when quoted:

  C:\WINNT>dir "/"

   Directory of \\

  File Not Found

Although the win32 api supports both one takes more work as paths containing forward-slashes are converted to back-slashes*. I know this is being petty but if different style paths cause problems surely it would make sense to follow the standard the OS follows?

Elfyn
elfyn@exposure.org.uk


_____________________________________________________________
www.smokeJet.com - Free UK Internet Services

_____________________________________________________________
Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

--
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)]

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

	Might that not imply some minimal understanding of the Win32 environment
so as to integrate as seamlessly as possible with such?
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.

	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.  

	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.

> You could take the radical approach of having a cygwin perl
> module reject backslashes and colons entirely.  
---
	IMO, that would defeat the purpose of cygwin.  
> 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:

>  If 
> you convert backslashes to slashes then you will be 
> introducing an inconsistency between the way cygwin handles 
> these types of paths and the way the perl module interprets 
> them.  Backslashes and colons in paths short-circuit mount 
> table operations in cygwin.  So, \usr\bin is not equivalent 
> to /usr/bin.
---
	So by that logic we should do...what?  If we convert from C:\foobar
to /cygdrive/c/foobar we are changing the semantics introduced via the
cygwin mounting system.

	I think we are in agreement on "/home/myhome\mybin\myfile" being
canonicalized to use all forward slashes.  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.

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

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

	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.

	Is this making any sense yet?

Linda

p.s. -- Sometimes I wish _simple_ HTML would become more standardized for
email -- it could make some writing much easier to read and comprehend.

If only text-based email readers could do the 'lynx' thing with HTML 
content....



--
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)]

> >So I think a fix could to change F::S::Win32 to convert all win32
> >pathseperators to unix pathseperators, and hand it off to F::S::Unix
> >to do the actual catfile(), etc calls...
> 
> Sounds fine, as long as we still do the right thing when 
> handed paths with backslashes in them (i.e. result should 
> have backslashes too). I'm not much worried about how the 
> internal implementation is done (at least for now :) as long 
> as the interface and semantic guarantees are correct.
> 
> So yes, I think we're generally in agreement here.
===
	um...maybe...I don't mind normalizing converting all A to B, but
it could easily be *wrong*.

	I can have "\" in a unix pathname, and i can have "/" exported in
an arbitary sharename that *isn't* a directory separator.  Yes -- they are both
edge cases, but trying to come up with a rule that doesn't consider what will
happen in the 'edge' cases is like not programming to check for buffer
overruns.  Hopefully we can think farther ahead...

-l


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

[Christopher Faylor]

On Sun, Jan 05, 2003 at 11:02:02AM -0800, Gurusamy Sarathy wrote:
>As far as the Win32 native port goes (I'm not really that cygwin-savvy to
>comment on what should happen for that port) I like to see:

I'm cygwin savvy and pretty perl savvy (although it's been quite some
time since I've posted anything to perl5-porters) but I have to say the
issue of how to deal with win32 paths is pretty uninteresting to me as
far as cygwin is concerned.

I think that if someone wants to use win32 paths they shouldn't be using
cygwin.  One of the primary focuses of cygwin was to isolate the user
from the backslash and colon nonsense.  It's a shame that we don't allow
the creation of filenamess with colons and backslashes but going out of
the way to arbitrarily deal with c: just seems anti-cygwin to me.  And,
attempting to treat /cygdrive/c as special in some way and indicative of
a "volume" also is wrong.  If applicable, /cygdrive/c should be
considered a mount point and /cygdrive should be considered to be
equivalent to a "devfs" system on linux.

I sympathize with the headaches involved with trying to accomodate win32
paths and will obviously support whatever decisions are made in this
regard but I would like to suggest that, for the most part, Cygwin path
handling should be as close to UNIX as possible.  Cygwin short circuits
most of its special handling when it sees a ':' or a '\'.  There is no
mount table interpolation in such a case.  To be consistent, I think it
makes sense for any perl cygwin module to automatically punt to win32
path spec handling when it sees those with the possible caveat that "a:"
== "a:\" on cygwin.

To address another issue in this thread, we won't be modifying cygwin to
allow the use of /cygdrive/c to mean "the current directory on drive c".
That's only an "OS" feature on Windows 9x and it clearly has no place in
a UNIX-like environment.  Even if this was not the case, the fact is
that this is long-established behavior for cygwin.  Changing it now
would not be a good idea without a really really good reason.

cgf
(cygwin project lead)
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sources.redhat.com
and be permanently blocked from mailing lists at sources.redhat.com

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

> -----Original Message-----
> From: Elfyn McBratney [mailto:elfyn-cygwin@sickpuppy.co.uk] 
> I tend to agree that as windows uses the back-slash as a 
> default path seperator so should `normalize' but also in the 
> interest of compatability with windows 95 (in dos mode) as it 
> doesn't support the forward-slash path seperator.
----
	I'm not sure I'd use Win95 as an example of what one should
use for compatibilities sake -- why draw the line there?  Why not
Win 3.0 or ...was there a Win 1.0?...Maybe PC-DOS 1.0... Even I wouldn't
choose to support anything prior to Win98SE.  Too many problems...
However...

> 
> >	In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'.
> >You have to quote the "/" so it won't be interpreted as a switch
> >character -- but the underlying OS seems to not really care which you
> >use and neither should Win32.
> 
> A bit OT but dir does not support the forward slash pathsep 
> even when quoted:
> 
>   C:\WINNT>dir "/"
> 
>    Directory of \\
> 
>   File Not Found
---
	You're right...I know I typed it in somewhere last night and it
worked, but it was getting a bit late...might have mucked up and typed
it into a cygwin shell...:-)  
	Weird OT examples follow preceeded by "#   "...

#   Oddly the following does work (WinXPSP1):
# 1)
#   C:\PCTemp>dir "/temp/w2k"
#   ...
#    Directory of C:\temp\w2k
#   12-27-02  12:50a    <DIR>          .
#   12-27-02  12:50a    <DIR>          ..
#   12-27-02  12:58a    <DIR>          Temp
#                  0 File(s)              0 bytes
#                  3 Dir(s)   9,374,515,200 bytes free
#   
#   But not with "cd":
# 2)
#   C:\PCTemp>cd "/temp/w2k"
#   The system cannot find the path specified.
#   
#   ...I'm getting a headache...let's look at the source!...um...drat...can't
#   do that (probably no wonder given this weird behavior).
#   
#   I have no problem with normalizing in win32 Perl changing everything to "/".
#   Seems best for syntax parses -- perhaps it's a bug in samba to allow this,
#   but just for masochism's sake I recreated my weird pathname via samba on 
#   linux:
# 3)
#   ishtar:/tmp/law> ls -R /tmp/law
#   /tmp/law:
#   dirfoo/  does this path work  linda\'s tmp dir in weird path dir
#   
#   /tmp/law/dirfoo:
#   footxt.txt
#   ---
#   cmd.exe:
# 4)
#   C:\>dir /s "//ishtar/tmp/law"		##only seems to work with /tmp
also 
#   							##exported
#    Volume in drive \\ishtar\tmp is tmp
#    Volume Serial Number is 0ADF-016E
#    Directory of \\ishtar\tmp\law
#   01-06-03  08:24a    <DIR>          .
#   01-06-03  08:30a    <DIR>          ..
#   01-06-03  08:19a                 0 LINDA~EN
#   01-06-03  08:21a                 0 does this path work
#   01-06-03  08:24a    <DIR>          dirfoo
#                  2 File(s)              0 bytes
#    Directory of \\ishtar\tmp\law\dirfoo
#   01-06-03  08:24a    <DIR>          .
#   01-06-03  08:24a    <DIR>          ..
#   01-06-03  08:24a                 0 footxt.txt
#                  1 File(s)              0 bytes
#   ---
#   ## w/o /tmp exported and only /tmp/law, explorer shows it but neither cmd
#   nor explorer can access the directory.  Oddly, 'dir' doesn't show shares
#   for the path "//ishtar" even though it can list the contents of shares
#   have to use "net view \\ishtar" (or // or \\ under cygwin). 
#   (though neither cmd nor cygwin can display contents of "tmp/law" unless 
#   "tmp" is also shared....net view shows:
#
# 5)
#   C:\root\tmp>net view \\ishtar
#   Shared resources at \\ishtar
#   Share name  Type  Used as  Comment
#   
#   ----------------------------------------------------------------------------
#   home        Disk           Home Directories
#   share       Disk  (UNC)    Ishtar Share
#   tmp/law     Disk           Per user tmp dir to demo psycho path
#   The command completed successfully.
#    
#
#	Anyway...seems like "/" works on network paths except in weird cases.
#	Also filenames with <singlequote> in them created on linux get an 8.3
# translation, but if created from win32 seem to work fine -- registry magic, 
# I guess...(?)

So it seems that 'syntactically', one can't always determine if a "/" is
invalid in a straight win32 environment -- at least not when a network name
is involved, but I'd agree it is pathological and should be ignored (and
documented as ignored for pathological share names)

So I'd suggest the following:

I. 
Win32 syntactic normalization should always proceed to return "\".

Cygwin is a Posix compatibility layer for Win32, though -- it isn't 
supposed to be a complete replacement/invalidation of the underlying Win32
layer -- unless one wants to declare that "e:foobar" only can reference a
file and simulate "foobar\fee" as a valid file (through some mechanism).

For cygwin to be a useful constructor of utils -- it should hand both Posix
names *and* win32 names.  Normalization can return "/" for any filename that
doesn't have, say, a <colon> in it -- but ... no... I agree it should always
return "/" for _syntactic_ normalization....and *document* that "\" will be
converted to / even if a remote fs allows "\" as a filename character.



II.
The second part of this is 2-fold --
a) The other "OS"s should clean up any semantic validation of paths -- since
to do so would imply that both unix and win32 and cygwin should try to 
verify the above described 'edge' cases as well as verify that all
"//host/share"
names are valid, and "x:" is a valid drive.
b) Possible option to add to File::Spec, or perhaps a different File::<module>
would be Semantic validation relative to the local system.

III.
It seems like for path splitting, syntactically, "<drive>:" should always be
split into the "device" (or volume) portion -- both under win32 and cygwin --
since it can't be anything else (<drive>: is invalid under both, though
not under unix).  Also, any <colon>s in the middle of either path should through
an exception.

What'cha think?  

> 
> Although the win32 api supports both one takes more work as 
> paths containing forward-slashes are converted to 
> back-slashes*. I know this is being petty but if different 
> style paths cause problems surely it would make sense to 
> follow the standard the OS follows?
---
	Agreed.  With special note: 'cygwin' is not an OS.  It's a posix
compatibility layer on top of a win32 OS.  Posix doesn't disallow : or \ in
filenames or assigning them to special meanings -- it just says that their
usage is dependant upon the underlying OS the program is running on.


-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

[Gurusamy Sarathy]

On Sun, 05 Jan 2003 00:41:31 PST, "LA Walsh" wrote:
>Syntactically, this can't be anticipated or interpreted and the use of a simpl
>e, documented limitation -- the assumption of non-intermixing of \ and / as pa
>thname component separators in the same pathname would be used.  So the first 
>"/" sets the dir sep to "/" and "\" could signal a warning that the syntax is 
>unclear.  But a pathname with "\" as the first dir sep, would throw an illegal
>-filename exception if "/" was encountered, because in places where '\' is a 
>dirsep, '/' is a switch character.

I agree with most of your points, and in particular with the one above.
I consider File::Spec::Win32 currently broken because it hijacks all
paths and turns them into the backslashed variety, which is completely
wrong from the portability POV.  (By which I mean that utilities written
for UNIX that would otherwise work on windows are now broken because of
this change.)

As far as the Win32 native port goes (I'm not really that cygwin-savvy to
comment on what should happen for that port) I like to see:

  * Where there is a prior hint for what the directory separator should
    be (either in the form of (0) an explicit argument specifying the
    separator, or failing that (1) a module/class variable, or failing that
    (2) a preexisting directory separator in one of the path arguments),
    File::Spec should use that for catenating/canonicalizing paths.

  * Where there is no such hint available, File::Spec should default to
    using '/' as the dirsep (which is the portable default and hence
    should always be the preferred one).  Note that this was the
    situation in 5.6.1 and before, so I'm not really that much worried
    about "breaking" the new behavior/bugs.

Thanks,


Sarathy
gsar@ActiveState.com

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

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

[LA Walsh]

This was originally sent to cygwin and module authors list, but since File::Spec
is part of core perl, it was suggested I move it to the perl5-porters list,
though it's not really 'just' a porting issue, since it also involves the
issue of how File::Spec should be _defined_ to behave (syntactic analysis
in absence of checking with a local fs, since there is no guarantee that some
paths are constructed for the current system, exceptions being routines like
'pwd'.

Anyway...here it is (again) -- sorry for the duplication to the cygwin
list, but cygwin folks are just special, ya know? :-)
-l
----

A bit late to the party, I know, but wanted to chime in on the Cygwin File::Spec discussion.  I'm 'cc'ing the cygwin list as a "heads up" for any interested parties.

A more satisfactory mapping is to base "Cygwin" on Win32, not Unix.

Cygwin, as an "OS interface" _partially_ supports posix mapping -- it supports posix naming to the same extent the underlying Win32 OS supports it -- not to the level Unix supports it.

For example, 
1) "\:" are illegal in Cygwin pathnames as they are under Win32.  Posix doesn't have this difference.

2) By default, case doesn't matter under Cygwin in the cases where it doesn't matter under Win32.  It's not _ignored_ -- case is preserved on filename creation but not lookup.  Ex:

law/proj/fspec> touch aBcDe
law/proj/fspec/tmp> ls
aBcDe							(expected)
law/proj/fspec/tmp> mv ABCDE AbCdE		(this works!)
law/proj/fspec/tmp> ls
AbCdE							(case is changed)
law/proj/fspec/tmp> touch aBcDe		(try to recreate original filename)
law/proj/fspec/tmp> ls
AbCdE							(win32 behavior, not posix behavior)

3) using unix and win32 syntaxes to parse valid cygwin filenames "i:/fee/fie/foe/fum" and "i:fee/fie/foe/fum" yield (under 5.8):

unix:v,d,f=, i:/fee/fie/foe/, fum
unix: 'i:', 'fee', 'fie', 'foe', ''
Win32:v,d,f=i:, /fee/fie/foe/, fum
Win32:'', 'fee', 'fie', 'foe', ''
    and
unix:v,d,f=, i:fee/fie/foe/, fum
unix: 'i:fee', 'fie', 'foe', ''
Win32:v,d,f=i:, fee/fie/foe/, fum
Win32:'fee', 'fie', 'foe', ''

	Under cygwin, you cannot create a filename "i:fee" -- it creates a filename 'fee' (somewhere**) on the "i:" filesystem (volume). 

====
=>	For some reason that eludes me, the current File::Spec implementation
=> returns a 'null' directory as the last directory component while no such => component existed in the original pathname.  I would tend to think this is a => bug. Elucidating comments?  Agreement?  Disagreement? ====

	Cygwin, and possibly, the Win32 module, are inconsistent in handling the differences between i:/foobar/ and i:.  On one hand i: is considered a 'volume' but on the other hand i:/ seems to evaluate to the same, incorrect, value. In "Win32", each 'fs' of form "<x>:', x of class <[:alpha:]>, there is a process-specific "current directory".  This can be seen by:

From cmd.exe, cygwin utils "ls", "pwd", "printenv" and "grep" are in my path.

1) Fresh cmd shell, what's on filesystem "Z"?

C:\Documents and Settings\law>dir /b /a z:## /a=show hidden, /b=skip header desktop.ini
Content.IE5						## expected output, /a=show hidden files
							
C:\Documents and Settings\law>ls z:
Content.IE5  desktop.ini			## again, expected output...
							
2) Where are we?

C:\Documents and Settings\law>cd
C:\Documents and Settings\law			## expected -- shows same as the
							## default prompt:
C:\Documents and Settings\law>echo %prompt%
$P$G							## $p=cur drive and path, $g=">"
C:\Documents and Settings\law>pwd		## on cygwin?
/cygdrive/c/Documents and Settings/law	## hmmm...cygwin translated c: to
							## /cygdrive/c;  seems like under
							## cygwin, /cygdrive/c is a win32 volume.
3. What does File::Spec say about that?
ishtar:law/proj/fspec> fspec "c:Documents and Settings/law/" Win32:v,d,f=c:, Documents and Settings/law/, 
Win32:'Documents and Settings', 'law', ''	## expected, C: is a fs (volume)
cygwin: v,d,f=, c:Documents and Settings/law/, 
cygwin: 'c:Documents and Settings', 'law', ''
							## oops, seems File::Spec::Cygwin
							## doesn't act the same way the Cygwin
							## layer does...>>not good<<, bug?

4. How about "/cygwin/c/Documents and Settings/law" ?
cygwin: v,d,f=, /cygwin/c/Documents and Settings/law/, 
cygwin: '', 'cygwin', 'c', 'Documents and Settings', 'law', '' unix:v,d,f=, /cygwin/c/Documents and Settings/law/, 
unix: '', 'cygwin', 'c', 'Documents and Settings', 'law', '' Win32:v,d,f=, /cygwin/c/Documents and Settings/law/, 
Win32:'', 'cygwin', 'c', 'Documents and Settings', 'law', ''

							## All the same...good, or is it?...um
5.
							## under cygwin, /cygwin/x/ can't be used
							## as a filename:
law/proj/fspec> mkdir -p /cygdrive/e/foo
mkdir: cannot create directory `/cygdrive/e': No such file or directory
							## looks like /cygdrive/<x> is just
							## as reserved as '<x>:' -- it's
							## a <fs> spec

oops...under cygwin, /cygdrive/x/
							## always specifies a volume yet
							## File::Spec doesn't seem to know
							## about this distinction -- oh well,
							## we can use rule if win32 elements
							## present, 
6. How about remote file systems?
ishtar:law/proj/fspec> fspec '\\fee\fie\foe\fum'
argv#=0
cygwin: v,d,f=, , \\fee\fie\foe\fum
cygwin: 
unix:v,d,f=, , \\fee\fie\foe\fum
unix: 
Win32:v,d,f=\\fee\fie, \foe\, fum
Win32:'', 'foe', ''
							## hmmm. cygwin thinks it is somehow
							## different than the Win32 parsing.
							## But is is not.  As stated above,
							## "\" isn't a valid filename character
							## under cygwin.  The correct parsing
							## is the Win32 version -- since "\\"
							## always starts a hostname under
							## cygwin and win32.  The "component"
							## is the remote public share name.

7. What about 'other drives'							
C:\Documents and Settings\law>z:
Z:\							## lets goto z...
Z:\>pwd						## prompt indicates Win32 curdir
/cygdrive/z						## cygwin...consistent

8. Environmental factors...(back to 'c')
C:\Documents and Settings\law>printenv |grep Z		## nothing in env for Z
C:\Documents and Settings\law>cd z:Content.IE5
							## sets curdir in env:
C:\Documents and Settings\law>printenv |grep Z
!Z:=Z:\Content.IE5				## it's there now...

9. Current dir check:
C:\Documents and Settings\law>pwd		## win32 prompt
/cygdrive/c/Documents and Settings/law	## cygwin -- expected

10: What's on Z again ...
C:\Documents and Settings\law>dir /b /a z:
index.dat
desktop.ini
5OG8E8Y3
RRJT4N16
30F1BLRO
UYYGJ85V						## Ahh...the Win32 separate curdir
							## concept.

C:\Documents and Settings\law>ls z:
Content.IE5  desktop.ini			## uhoh, cygwin's ignoring the underlying							## OS concepts, this doesn't bode well
11. Lets switch to our 'Z' drive again'
C:\Documents and Settings\law>z:
Z:\Content.IE5>					## shows up win32's per-drive curdir
							## concept
Z:\Content.IE5>pwd
/cygdrive/z/Content.IE5				## pwd provides consistent feedback,

12. Commands: mkdir "x:c", <ls/dir> x:", cd "x:c", "<ls/dir> x:", 
	assuming x is a drive for win32/cygwin examples:
	on Unix - 2 errors and ending up in dir "x:c"
	On Win, - no errors and same output -- no change in current directory 
on current drive.
	On cygwin - output of the of the two dirs is different and the current directory is changed.

	Cygwin isn't really behaving like Unix or Win32.

	So I see a couple of problems: 
1) File::Spec should mainly be based on Win32, if not exactly the same.
2) Cygwin should pay attention to the Win32 concept of per-drive pathnames
	when win32 drive letters are used (though /cygdrive/c should still refer to the root dir of the 'c' drive).
3) File::Spec needs cleanup.  Is it supposed to be parsing "Syntactically" or "Semantically".  They are different.
4) File::Spec::Win32 would give incorrect results on one of my old Samba exported fs's: server exported people's home directories as "/home/<user>" to prevent Win98 from automatically using \home\<user> as a location for a traveling profile.

Syntactic parsing would yield a volume/fs of would yield //server/home and 
file=<user> but the exported fs name was really "/home/user", and should have been parsed as one volume name: //server/home/user, or in DOS-syntax, "\\server\home/user".

Syntactically, this can't be anticipated or interpreted and the use of a simple, documented limitation -- the assumption of non-intermixing of \ and / as pathname component separators in the same pathname would be used.  So the first "/" sets the dir sep to "/" and "\" could signal a warning that the syntax is unclear.  But a pathname with "\" as the first dir sep, would throw an illegal-filename exception if "/" was encountered, because in places where '\' is a 
dirsep, '/' is a switch character.

Refering to problem 3, above, Semantically, under Unix as in other OS's, 
separate filesystems should be parsed out as separate volumes -- since the concept of a 'volume' in OS terminology is most often used to describe a filesystem.  Older usage, I believe, used the term interchangeably with 'disk', but in modern usage (influenced most commonly by Win32), it is a file system.

The Win32 module, semantically, also, for consistency, has to recognize the same problem in later NT-based OS's since 'volumes' can be mounted on arbitrary mount points in the fs-hierarchy.  This underscores the concept of of a 'volume' as a mountable fs -- a definition that, semantically, would apply to Unix as well.  But, vaguely, it appears the intent of File::Spec was to provide OS-blind ways of manipulating arbitrary filenames (not necessarily limited to valid filenames on the current system).  As such, default manipulation routines should consistently be altered to be 'syntax-only' (except where absolutely
necessary: ex. 'pwd' function).

I'm not decided on the best syntax to provide an additional layer that does semantic analysis based on what is true on the current system.

Comments?  No flames, please...we don't need to get personal or religious on what should be an engineering discussion (in which I may have misconceptions, but may just be trying to look at the problem space from a different perspective.

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/