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
On Sat, Aug 12, 2000 at 10:27:17PM -0400, Dan Sugalski wrote:
At 10:24 PM 8/12/00 -0400, Chaim Frenkel wrote:
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
NW just deal with filenames universally this would be a big win (leave
NW acls, permissions, versions, etc to something else).
[cc'ed on internals as FYI]
=item 36 (v1): Structured Internal Representation of Filenames
I think this should be discussed a good amount. I think URIs are cool,
but too much trouble for simple stuff. I don't want to have to write
"file:///etc/motd" everytime I want to address a file. Too
