Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
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 different matter. @parts = qw(sy $ foo bar 262); Now, create a file in the same directory with the same type, and name blech. Any idea? -- Johan
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
"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 with all other parts left alone"; $fh = open $resource-asNativeFormat() Blech, but possible. chaim (Stolen parphrased but liberally from the Symbolics manual) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
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])
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
"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 JH it obey, how to parse it. I don't see how your proposal solves the problem. It still has to know what the source/intended/target platform is. Why do all those acts have to be performed to do an open? Hmm, unless you are planning to have a direct perl - os layer. (A rewrite/stealing^wborrowing from sfio?) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
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 some other format for Perl to deal with. For example: open "C:\Windows\System"; # non-portable open "file://C|/Windows/System"; # portable Under the hood, these could be converted into huge structs or something else that the user never has to know or care about. Many others have begged :-) for URI support in open(), so it'll be in there. This seems like the easiest thing todo. No reason to reinvent the wheel, URIs are a well-established platform-independent naming scheme. -Nate
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
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). The VMS (and TOPS20) advocates will scream here. Versions are part of the file name. The default is the latest version. But the filesystem automatically versions files. Hmm, if we support versioning files, will perl have to support emacs versioned files? /foo/bar/bash.c.~356~ "have to" is awfully strong, but it's a reasonable thing to do. Whether it's too specialized to be worth it's a separate issue, of course. I agree with Dan: people do seem to get into "have to" mode awfully soon and easily. The proposed framework is supposed to make it easy to handle file names and make Perl internals (well, not internal- internals, but the IO layer) better support multiplatform situations, both when scripts have to run on multiple platforms, and when an application is running on multiple platforms _simultaneously_, servers-clients, peers-peers, etc. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
