Mail Archives: cygwin/2003/01/05/20:28:48
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]
Personally, I think that that is *not* a bug, even if it looks like one.
Whenever one writes require BAREWORD, it is passed a "path/file.pm" type
string -- it's \Ualways\E a unix style path, even on windows or vms or
any other OS; internally, it gets translated from a unix style path to a
platform-appropriate path. Thus, if you want to require() something
produced by catfile, you should write:
use File::Spec::Unix;
my $file = File::Spec::Unix->catfile("GetOpt","Long.pm");
require $file;
Using F::S::U, not F::S.
> 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
When used with the underlying system calls for open, creat, unlink, etc,
don't all of these work equally well? It seems that it's a waste of
effort to go about canonicalizing them if the user hasn't explicitly
asked to do that with canonpath().
[snip]
> 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..
If a programmer wants to compare paths, then he should be forced to
transform them into canonical paths, with canonpath. That's what it's
there for, after all.
> 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...
But paths delimited with forward slashes instead of backslashes get
interpreted wrong by command.com.
<IDEA type="wild" subtype="unlikely">Hmm... how about, forward slashes
get produced everywhere, *but*, we also provide a new F::S method
'shellquote' which on Windows, changes forward slashes to backslashes,
and puts quotes around the whole thing if there are spaces in the path,
and on unix, simply calls quotemeta to quote the spaces. (And maybe on
VMS, uses some DWIM hueristic to tell if it's been passed a unix-style
path, and if so, changes it to a proper VMS path). A path which has
been shellquote()ed could then be safely used in system(STRING) without
fear that it will be seperated into multiple arguments or flags or
whatever.</IDEA>
--
$..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
$..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
$.=~s'!'haktrsreltanPJ,r coeueh"';BEGIN{${"\cH"}
|=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);
--
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 -