[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re[2]: [MacPerl] More on the lack of path handling routines




Matthias Ulrich Neeracher <neeri@iis.ee.ethz.ch> writes:
}  - Scott's remark about the lack of a path handling library is absolutely
}    correct, and noted as such. As far as I know, Kenneth Albanowski and/or
}    Charles Bailey are working on such a library.

Do you have any more information of that?  How to contact them, etc?

}  - His point about line terminators in the parser was well taken. I've
}    inspected the perl sources to see what it would take to make the perl
}    parser recognize all end of line styles (CR, LF, CRLF), but with the
}    current I/O architecture, that's not possible in an efficient way.
}    Perl will soon switch to an sfio based architecture, and then, this project
}    is worth another look.

That definitely seems like a perl-core project rather than a MacPerl one...

}  - Intuiting the OS from directory tests, as Daniel suggests, is somewhat too
}    risky (one day you might meet a freak Mac with a directory named "/") and
}    not necessary anyway: Just use the $^O variable.

My amusing story regarding quick-hack pathname fixes is the Sun Java libraries,
which internally treat Mac file system paths as forward-slash delimited names in
the UNIX style.  Problem is, Mac filenames can have forward slashes in them; as
an example, the System folder on the machine I'm working on is named 
"753/8500/GX3/RD/SD/OD", after the OS/machine configuration.  Needless to say,
the Sun Java interpreter can never find its class libraries in the system
folder...

Paul J. Schinder (schinder@pjstoaster.pg.md.us) wrote:

> But I think part of this discussion
>has taken the wrong tack.  There's need for standard path handling
>routines, but there's no need for portable ones that autodetect
>architectures.  What I have in mind is something like what you've done
>with File::Basename, where it functions with Mac paths exactly like the
>Unix File::Basename functions with Unix paths.  I don't expect to be
>able to copy File::Basename from my Mac to my Sun (or vice versa) and
>have it work.  All I expect is that basename() give me the right result
>for the archtecture I'm using, and since File::Basename is in the
>standard distribution, I can use it without worry that it won't exist.
>But the key is to get the routines into the standard Perl 5
>distribution, and to write the routines so they do the "right" thing for
>each architecture.

This is right on the money.  The base problem (that I started this thread by
complaining about) was that, in the lack of such standard Perl libraries, we
were forces to resort to auto-detection hacks to make our code do the right
thing on each platform.

  --Scott