Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-16 Thread Nick Ing-Simmons
Johan Vromans <[EMAIL PROTECTED]> writes: >Nathan Wiger <[EMAIL PROTECTED]> writes: > >>$fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR"; >>$fo->pathdrive = "C:" ; > >I think the drive is "C", not "C:". The reason for including the ':' is so that the rule for reconstructing the path is ea

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-16 Thread Nick Ing-Simmons
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >On Fri, Aug 11, 2000 at 02:16:31AM -0700, Nathan Wiger wrote: >> [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 t

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Chaim Frenkel
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Many others have begged :-) for URI support in open(), so it'll be in NW> there. This seems like the easiest thing todo. No reason to reinvent the NW> wheel, URIs are a well-established platform-independent naming scheme. I'm not sure th

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 02:14:24PM -0400, Chaim Frenkel wrote: > > "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 the

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Nathan Wiger
> 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 so

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Chaim Frenkel
> "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 se

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 01:22:30PM -0400, Chaim Frenkel wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote: > >> This all seems like a lot of work for (what I would consider to be) the > > JH> Read careful

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 01:22:30PM -0400, Chaim Frenkel wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote: > >> This all seems like a lot of work for (what I would consider to be) the > > JH> Read careful

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Chaim Frenkel
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote: >> This all seems like a lot of work for (what I would consider to be) the JH> Read carefully the subject: *internal* representation. If you are JH> opening a file w

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote: > This all seems like a lot of work for (what I would consider to be) the Read carefully the subject: *internal* representation. If you are opening a file with open() or sysopen(), you supply a string with your native FS semantics

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 07:54:34AM -0400, Chaim Frenkel wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > JH> I agree with Dan: people do seem to get into "have to" mode awfully > JH> soon and easily. The proposed framework is supposed to make it easy > JH> to handle file

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Jarkko Hietaniemi
On Sun, Aug 13, 2000 at 01:19:03PM +0200, Johan Vromans wrote: > 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 dir

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Bryan C . Warnock
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)

2000-08-13 Thread Chaim Frenkel
> "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 = "

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Chaim Frenkel
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: JH> I agree with Dan: people do seem to get into "have to" mode awfully JH> soon and easily. The proposed framework is supposed to make it easy JH> to handle file names and make Perl internals (well, not internal- JH> internals, but the

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-13 Thread Johan Vromans
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

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Jarkko Hietaniemi
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 s

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Dan Sugalski
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. Versio

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Chaim Frenkel
> "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

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Jarkko Hietaniemi
> > Splitting apart or putting together either one of these paths is trivial > > I think it's far from trivial, especially if you want to take into > account network names, file versions, protection attributes and ACLs, ... Access details like this are largely independent of the logical manipula

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Johan Vromans
Nathan Wiger <[EMAIL PROTECTED]> writes: >$fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR"; >$fo->pathdrive = "C:" ; I think the drive is "C", not "C:". >$fo->patharray = [ Windows, System, IOSUBSYS, RMM.PDR ]; I think the patharray is [ Windows, System, IOSUBSYS ]. The file name is

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Nathan Wiger
> I think it's far from trivial, especially if you want to take into > account network names, file versions, protection attributes and ACLs, ... Sure, this all depends on what we're going to do with this data and at what level. The biggest problem that modules like CGI.pm have to deal with is jus

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-11 Thread Chaim Frenkel
Here's a list of attributes that I found in my old Symbolics Reference Guide to Streams, FIles, and I/O. (March 1985) Host Device Directory Name Type Version Plus it needs to handle cross-system support. How to specify the name of a unix file when

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-11 Thread Jarkko Hietaniemi
On Fri, Aug 11, 2000 at 02:16:31AM -0700, Nathan Wiger wrote: > [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 hav

Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-11 Thread Nathan Wiger
[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 cumb