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
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
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Chaim Frenkel wrote:
>>
>> Sitting on a unix box, and getting to C: on a windows box?
DLN> That implies a whole pile of implementation details. Are you
DLN> suggesting a Perl Orifice to run on all participating windows
DLN> boxes?
Chaim Frenkel wrote:
>
> Sitting on a unix box, and getting to C: on a windows box?
That implies a whole pile of implementation details. Are you
suggesting a Perl Orifice to run on all participating windows
boxes?
I'd
like to call "open" with the arguments I can currently pass
to "hose" from
> "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
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
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
> 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
> "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
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
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
> "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
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
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
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
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])
> "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 = "
> "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
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
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
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> Chaim Frenkel wrote:
>>
>> 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 versionin
Chaim Frenkel wrote:
>
> 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/b
> "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
> > 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
> 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
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
> >
> > 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 cumbersome.
Why not extend C to be able to take other things besides
strings of
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
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
[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
On Wed, Aug 09, 2000 at 06:37:07PM -0700, Jon Ericson wrote:
> =item 33 (v1): Eliminate bareword filehandles. (language)
>
> No discussion.
Using "$fh = open()" accomplishes this. I think everyone is in
agreement that bareword filehandles must go.
>
> =item 39 (v1): print operator
>
> No di
> "JE" == Jon Ericson <[EMAIL PROTECTED]> writes:
JE> =item 33 (v1): Eliminate bareword filehandles. (language)
JE> No discussion.
I think it carried unanimously.
JE> =item 36 (v1): Structured Internal Representation of Filenames
JE> (internal)
JE> No discussion of the proposal that "Where
=head1 Summary of I/O related RFCs
Please correct my misunderstandings and omitions. This (or something
like it) should be sent up to perl6-language.
=over
=item 2 (v1): Request For New Pragma: Implicit (language)
Values in void context would be printed to the default filehandle.
use
33 matches
Mail list logo
