Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3E189121.70901@dwim.org> Date: Sun, 05 Jan 2003 21:10:09 +0100 From: "Jos I. Boumans" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: perl.perl5.porters To: Gurusamy Sarathy CC: LA Walsh , perl5-porters AT perl DOT org, cygwin AT cygwin DOT com Subject: Re: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis References: <012901c2b496$3f4955e0$1403a8c0 AT sc DOT tlinx DOT org> <200301051902 DOT h05J22p26110 AT smtp3 DOT ActiveState DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Imho, a fix to F::S::Win32 that would consistently change paths to ANY standard seems like the best solution. As the below script shows, even unix paths work just fine (noting that this is tested on win2000 with cmd.exe): ####################################################################### #! perl -wl use File::Spec::Unix; my $perl = File::Spec::Unix->catfile( qw[c: perl 5.8.0 bin perl.exe] ); print $perl; # c:/perl/5.8.0/bin/perl.exe print "found" if -x $perl; # found system(qq[$perl -le"print 'hello world'"]); # hello world ######################################################################## > 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), 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. 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... If we can agree on this, I'll happily provide the patch. > * Where there is no such hint available, File::Spec should default to > using '/' as the dirsep (which is the portable default and hence > should always be the preferred one). Note that this was the > situation in 5.6.1 and before, so I'm not really that much worried > about "breaking" the new behavior/bugs. -- Jos Boumans How do I prove I am not crazy to people who are? CPANPLUS http://cpanplus.sf.net Just another perl hacker http://japh.nu -- 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/