Perl package File::Spec confused under cygwin
Mon Dec 23 23:52:00 GMT 2002
On Sun, 22 Dec 2002 02:59:49 GMT, Michael A Chase <firstname.lastname@example.org>
wrote in news:Mahoganyemail@example.com:
> On Sat, 21 Dec 2002 17:36:58 -0800 "linda w (cyg)" <firstname.lastname@example.org>
>>> Note that Cygwin, like Unix, doesn't have a concept of
>>> volume. Everything except network paths (//host/dir) are
>>> based on a single root directory.
>> But Unix does have a concept of a mount point (device) and
>> path from the mount point. Conceivably, one could view the
>> mount point itself as a local host name for the "volume" (local,
>> remote or a device) with path being location on the mounted fs.
> device != volume. For the purposes of File::Spec, it would be better
> to leave the directory structure as a single tree.
>> It is arbitrary to choose to see the /fs as one giant
>> undifferentiated tree.
> But that is the convention used by Unix and hence Cygwin. You can
> distinguish which device a file or directory is in by using the first
> element returned by stat(), but that doesn't affect the file spec.
This is the crucial point. It may be arbitrary but that doesn't mean you
can ignore it and still make cogent arguments that some code isn't working
right. Historical factors determine a great many things in our computing
life. Historically, MS Windows decided to have a concept of "Volumes"
(which indeed are NOT the same thing as "devices") whereas Unix decided to
have such a thing as a single-rooted or monolithic filesystem. That's just
the way it is. I personally think that the single-rooted filesystem is far
more rational. Take away the conventions that dictate that there will
always be a "/bin" and a "/usr" and a "/tmp" dir, etc., and it is *still*
an important concept. There's always going to be a "root" above which you
cannot climb, but beneath which everything can be decended into. To me,
that is rational. Also more than any other single factor it gives me the
kind of distinct Unix-style computing experience.
It reminds me that the family of orchid plants (a huge family numbering in
the 10s of 1000s of species) there is a major division: "monopodial"
['single-footed'] vs. "sympodial" ['together-footed' or something like
that]. At a glance, most people can see the difference between monopodial
types of orchids and sympodial types, once the concept has been explained
to them. Likewise, this filesystem-structure difference between MSWin and
POSIX is a BIG, fundamental difference. It isn't merely a small detail of
style (that people can be careless about paying attention to most of the
time) but rather a large, shaping issue. IMHO.
>>> You can always call File::Spec::Win32 -> splitpath() to get
>>> that behavior.
>> Well, for 'portability' one shouldn't call ::<OS> anything.
>> The purpose of File::Spec was to provide a OS independent way to
>> deconstruct/construct pathnames into their separate components.
> Portability is a worthy goal, but sometimes you have to accomodate
> your specific environment, that's why $^O is available.
Yeah. Sometimes the better part of valor is just to put some conditionals
in your Perl code to accomodate the reality that Perl hasn't yet been able
to completely "flatten" all OS distinctions.
>>> It does, but File::Spec::Cygwin is very close to File::Spec::Unix.
>> Yeah...got that. I guess most immediate fix would be to fix
>> the Cygwin version to differentiate things... then if it was
>> important, one could split the path to mount:path for more useful,
>> yet spec-compatible functionality.
> If you submit a Perl bug report with a patch that does what you want
> and explains why you want it, it is likely to get included in the next
> release of Perl. If you talk nice to Gerrit, you may even get it in
> the next build of Cygwin Perl pending a change to the base source.
> Borrowed code from File/Spec/Win32.pm may provide a start.
I am wondering, Michael, have you tried my module? I'd value your feedback
on it. CPAN-Authors listing: /S/SO/SOMIAN/.
Yes, it's really SÃ¶ren, not Soren.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
More information about the Cygwin