Perl package File::Spec confused under cygwin

Soren A
Mon Dec 23 23:52:00 GMT 2002

On Sun, 22 Dec 2002 02:59:49 GMT, Michael A Chase <>
wrote in 

> On Sat, 21 Dec 2002 17:36:58 -0800 "linda w (cyg)" <>
> wrote: 
>>> 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.
>> ---
>> 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/ 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:
Bug reporting:

More information about the Cygwin mailing list