Jarkko Hietaniemi [EMAIL PROTECTED] writes:
Access details like this are largely independent of the logical
manipulations made with pathnames. I can claim that there is
"/foo/bar/zap.txt" and I can say that file directory part is
"/foo/bar", but whether such an entity really exists, is a
"JV" == Johan Vromans [EMAIL PROTECTED] writes:
JV @parts = qw(sy $ foo bar 262);
JV Now, create a file in the same directory with the same type, and name
JV blech. Any idea?
I don't like this but how about
$resource = File::Generic "."
$resource-name = "new name
This all seems like a lot of work for (what I would consider to be) the
common, default case - wanting to open a file native to my OS, on a
filesystem seen by my OS. Or am I clue-lossy again?
--
Bryan C. Warnock
([EMAIL PROTECTED])
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
Please explain why internally it needs to be represented as anything
other than what the user passed in.
JH A flat string is a pain to handle because then you have to know
JH in which platform it was originally created: what semantics does
And how do we make it easy to pass in a name to open?
In an email I sent to Jarkko off-list, I suggested this:
If we embedded full URI support into Perl, then people could write
portable scripts using URIs, or non-portable ones using native syntax.
*Internally*, both could be converted into
