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