Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "linda w \(cyg\)" <cygwin AT tlinx DOT org>
To: <cygwin AT cygwin DOT com>
Cc: "'Soren A'" <soren_andersen AT fastmail DOT fm>
Subject: RE: Perl package File::Spec confused under cygwin
Date: Sat, 28 Dec 2002 23:25:09 -0800
Message-ID: <000201c2af0b$6d810bf0$1403a8c0@sc.tlinx.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: 
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id gBT7Pui31044

Hello Sören,

> From Soren A

> What you expected File::Spec to do perhaps seemed intuitive and
> natural,
===
	"Least surprise' is a valuable design principle.  I try to design things
knowing that 2-3 months from now I'll likely have forgotten all the details of
why I did something a certain way.  If I make it 'self-documenting' and
'intuitive', I'll be less likely to have a problem using it later in some,
weird, unforeseen way that I didn't think of when I initially created it.  It's
sort-of an 'overdesign' principle so when I 'reuse' it in unforeseen ways, it
will still do what it should 'intuitive' "_should_" do -- not just the original
spec to which it was created.  

> but in fact the situation on Cygwin is kind of unprecedented and no,
> Perl hasn't been "ported" to Cygwin to THAT degree. The fact is it is 
> a pretty complex set of issues.
> 
> First of all, the $^O (Eng: $OS_NAME) on CygwinPerl is *not*
> 'MSWin32'. You need to be clear on that because if you rtfm
---
	Perhaps your usage is different than mine, but rtfm(/rtfmp), is usually 
employed when something is _evident_ in the places one would look _first_.  It
doesn't apply to arcane developer documentation.  Making every OS/application
component such that it requires everyone have the source and be familiar with
every readme or footnote embedded in the program source is lazy or bad practice.

	I've had the Camel book since the early 90's.  I had the layout
memorized to the point that switching to the Perl 5 edition was a pain (am still
not as 
efficient in perl5 lookups as was in perl4).
	Also, Cygwin isn't mentioned in the "perlvar" manpage where it mentions
win32, but not cygwin.  Um, WTFM were you referring to? :-)


> The value of $^O on Cygwin is "cygwin".
---
	Logical, but am not sure where I would have read that.  Heck, I didn't
even know about $^O, but then, I've never had a need for it, before now, either.


> On Cygwin we have a possibility to access files on the local
> filesystem (as distinguished from any sort of "remoteness") via two 
> different "modes": the correct
---
	"Correct"?  Just because it is posix doesn't mean users will not be more
likely to use d:/foobar rather than /cygdrive/d/foobar.  Yes, for myself I setup
symlinks, /d->cygdrive/d, but that is arcana a Win user shouldn't have to learn.
Maybe I just want to develop/deploy a general utility for Windows using the 
cygwin toolset.  You can't access the full power of Win32 using a Posix only
interface and even, for example, even if Posix DS ACLs were implemented, they
have different and incompatible semantics. 


>"cygwin" mode which is otherwise knows as the POSIX  filesystem;
---
	Posix?  But it's not really POSIX -- for example try creating a file
named "\foo" or :foo -- legal in POSIX but not cygwin.


> and
> the completely different Win32 mode. Never the twain shall meet. They 
> are fundamentally incompatible, as a little thought will show to
> anyone who 
> ponders it (and many have).
---
	Often being one who doesn't see things the way everyone else sees them,
could you elaborate?  How many have pondered this?  Why are they fundamentally
incompatible?
	
	My grammar skills are *very* rusty, but perhaps you could refine,
correct and/or elaborate the logic, below,  to clearly show where they are
incompatible?
It seems like this would provide a merging of win32 and the semi-posix naming
conventions.  Additional semantic details such as whether or not case makes a
difference are not addressed.
	There is a syntactic incompatibility within win32 in that it is possible
to have a sharename with ":/\" in it (at least using Samba)...trying to parse
such would be a pain.  In fact, that 'sharenames' seem to be able to be composed
of semi-arbitrary strings would seem to defy a syntactic-only parsing.  
	Also, inherent in the below 'grammar' is a parsing based on 'semantics',
not
just syntax.  Syntactically, the best one could do would be to parse out drive
letters, the share-hostname and the apparent first syntactic element as a
likely sharename.  
	Under Unix one could assume no file-systems in a syntax-only parsing
which
is seems to be the only supported usage for File::Spec.
	But given that, I don't see why you believe that "many" have pondered 
fundamental incompatibility for cygwin-pathnames composed of win32 and/or posix
elements.

Conventions: [] denote 0 or 1 occurrence
		 []* denote 0, 1 or more
		 {} denote 1 or more occurrences, alternate to []+
		 <fnname>(<expr>) specifies function <fnname> applied to <expr>

1.
<path>		::= [<path><SEP>]<"largest" homo-fspath>[<"largest" target>] |
			    <special-fs-path>[<SEP>][<"largest" target>]

2.
<homo-fspath>	::= [[<homo-fspath>][<SEP>]]<target>[<SEP>] |
			    <largest target>[<SEP>]
				where Device(<target>)==Device(<homo-fspath>)
for all
				_derived_ values of <target> composing the right
hand
				<homo-fspath>
3.
<special-fs-path>	::= <logical drive> | <netshare>

4.
<logical drive>	::= <'a'..'z' | 'A'..'Z'><colon>

5.
<netshare>		::= '\''\'<hostname><SEP><sharename>

6.
<target>		::= {<rfnc>}	# (<restricted filename character>)
7.
<sharename>		:: {<snc>}		# (<sharename character>)

8.
<rfnc>		::= character <c>, not in set ( <null> | <slash> | <backslash> )
9.
<snc>			::= character <c>, <c> != <null>
10.
<SEP>			::= <slash> | <backslash>

11.
<null>		::= character set null / end of string value
12.
<slash>		::= '/'
13.
<backslash>		::= '\'
14.
<colon>		::= ':'


> If you go back and rtfm on File::Spec and still cannot get the tools
> you are looking to get, then my module almost undoubtedly addresses 
> your need. Whether you'll enjoy using it or find it pretty is another 
> question entirely.
---
	I'm not sure, but the above grammar would seem to be a starting place.
Additionally, it is arguable as to what is meant by a volume -- which means
filesystem under any other OS, but some people feel doesn't apply to Unix.  

For syntactic parsing this is probably true, but if one uses semantic analysis,
I'd disagree.  It would be akin to using a common term for 'dog' in all
languages, say 'pooch', but in French we'd use "chien" because that is the
"customary" word and French doesn't have a concept of 'dogs' that could be
called pooches -- because in French they are called 'chiens'  It would be,
perhaps, stereotypical, but nevertheless, ignorant of the concept of a 'dog' to
claim the French 'chien' isn't really a class of 'pooch'.

	If a volume is a filesystem in any other OS, why would it not be denial
that Unix has separate filesystems the same as any other OS?

	From what you say, your module can't handle win32-style cygwin paths.
Is that a problem, or did the above grammar give any ideas (or not)...?
It is more of a semantic grammar but a syntactic grammer shouldn't be
anymore difficult with certain assumptions of 'reasonableness'.  If you need,
I can give it some thought for you and the 'many' people who have pondered
it.  Might fall on my face, but what the heck...:-)

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/