Mail Archives: cygwin/2003/01/05/15:42:13
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 AT ActiveState DOT 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/
- Raw text -