Re: RFC 100 (v1) Embed full URI support into Perl

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL>$fo = open "C:\Windows\System";# non-portable PRL>$fo = open "file://C|/Windows/System"; # portable In what way is the second example portable? I don't think it will do anything useful on any of my *nix boxes. PR

Re: RFC 14 (v3) Modify open() to support FileObjects and

You forget that open() handles all the magic. "| ...", " ...|", and the rest of the family. Sysopen specifically doesn't. So one could easily (and does) use open to do the magic, and then uses sysread/syswrite to handle the dirty details of playing with a pipe. Oh, before I forget, one also needs

RFC 100 (v1) Embed full URI support into Perl

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Embed full URI support into Perl =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 100 Status: Developing =h

Re: RFC 14 (v3) Modify open() to support FileObjects and

Chaim Frenkel wrote: > > > "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: > > NW># Replaced by 'open sys' > NW>sysopen > NW>sysread # sys->read instead > NW>syswrite# sys->write instead > > sysread and syswrite also work on files that were opened via standa

Re: RFC 14 (v3) Modify open() to support FileObjects and

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW># Replaced by 'open sys' NW>sysopen NW>sysread # sys->read instead NW>syswrite# sys->write instead sysread and syswrite also work on files that were opened via standard open. It bypasses the stdio library.

Re: RFC 14 (v3) Modify open() to support FileObjects and

Today around 2:54pm, Nathan Wiger hammered out this masterpiece: : > open "http://my.homepage.com"; # the file : : Well, I think this is a bit of an edge case. If you really have a file : named this, it would have to be in UNIX, named: : :http:/my.homepage.com : : So, you'd have a UNIX dir

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

> "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?

Re: RFC 14 (v3) Modify open() to support FileObjects and

> >myhttp->open("http://www.perl.com", "fred", "barney"); > > Indeed I had written it that way to begin with, but changed it because > it didn't seem to make a difference to me. Why is one "more correct" > than the other? Currently, there's no real difference. Depending on what happens in P

Re: RFC 14 (v3) Modify open() to support FileObjects and

> $fh = open socket "tcp://www.perl.com:80"; This is not bad, I hadn't thought of making it URI-like. There is already a proposal in the RFC to replace socket() with: # Open a client socket # By overloading < and > we can do clients and servers $socket = open socket "< 25", PF_I

Re: RFC 14 (v3) Modify open() to support FileObjects and

> $fh = open file "http://my.homepage.com"; Excellent point. Thanks Scott! :-) > or less verbose, > > $fh = open "

Re: RFC 14 (v3) Modify open() to support FileObjects and

> open "http://my.homepage.com"; # the file Well, I think this is a bit of an edge case. If you really have a file named this, it would have to be in UNIX, named: http:/my.homepage.com So, you'd have a UNIX directory named "http:" containing the file "my.homepage.com". The double // will get

Re: RFC 30 (v3) STDIN, STDOUT, and STDERR should be renamed

On Mon, Aug 14, 2000 at 02:44:45PM -0700, Nathan Wiger wrote: > The two suggestions I like that I've heard are the one you mention and > $PERL{VARIABLE}, because then you can get all the current settings by > iterating through %PERL. Well, you can iterate over a namespace too you know (unless th

Re: RFC 30 (v3) STDIN, STDOUT, and STDERR should be renamed

Jonathan Scott Duff wrote: > > Everytime I see this I think that Perl should have it's own namespace > for special variables. > > print $PERL::STDERR "Oops!\n"; Check out RFC 17, it deals with this issue somewhat. The two suggestions I like that I've heard are the one you mention and $P

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Mon, Aug 14, 2000 at 04:50:51PM -0400, Casey R. Tweten wrote: > open HOME_PAGE, "> $url" or die $!; #assuming default (as of 5.6.x) syntax > print HOME_PAGE getprint $url; > close HOME_PAGE; > > So now we have a file called `http://my.homepage.com`. Perhaps we want to > parse this file, so

Re: RFC 14 (v3) Modify open() to support FileObjects and

Today around 1:08pm, Jonathan Scott Duff hammered out this masterpiece: : Where are these handlers registered? How are they registered? In my : mind I was thinking that we could just name our handlers as packages : so that : : $fh = open "http://www.perl.com"; # and :

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

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

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Sat, Aug 12, 2000 at 11:01:30PM -0400, Chaim Frenkel wrote: > What hasn't been discussed, is > > Are files (or perhaps resources) named natively or in a portable fashion? > > If portable, then > for (@ARGV) { open $_; ... } > has to DWIM both portable and native formats. > > If native

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Mon, Aug 14, 2000 at 11:21:38AM -0700, Nathan Wiger wrote: > Exactly. Or to be "more correct" > >myhttp->open("http://www.perl.com", "fred", "barney"); Indeed I had written it that way to begin with, but changed it because it didn't seem to make a difference to me. Why is one "more corre

Re: RFC 14 (v3) Modify open() to support FileObjects and

> What does that mean? When the handler is invoked, what does it see? > > $fh = open myhttp "http://www.perl.com", "fred", "barney"; > > Does that result in a call like this? > > myhttp::open("http://www.perl.com", "fred", "barney"); Exactly. Or to be "more correct" myhttp

Re: RFC 30 (v3) STDIN, STDOUT, and STDERR should be renamed

On Mon, Aug 14, 2000 at 05:48:33PM -, Perl6 RFC Librarian wrote: >print $STDERR "$stuff\n"; Everytime I see this I think that Perl should have it's own namespace for special variables. print $PERL::STDERR "Oops!\n"; -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]

Re: RFC 14 (v3) Modify open() to support FileObjects and

On Sat, Aug 12, 2000 at 09:09:33PM -0700, Nathan Wiger wrote: > 1. If called as an indirect object function (in the form currently >proposed), steps 2-3 are skipped and the handler specified is >automatically invoked. What does that mean? When the handler is invoked, what does it see?

RFC 30 (v3) STDIN, STDOUT, and STDERR should be renamed

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE STDIN, STDOUT, and STDERR should be renamed =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Last-Modified: 14 Aug 2000 Version: 3 Mailing List: [EMAIL PROTECTED] Nu

Re: RFC 14 (v3) Modify open() to support FileObjects and

Joe McMahon wrote: > On Sat, 12 Aug 2000, Nathan Wiger wrote: > > > Pick one: > > > > > > 1) Filenames that end with a '/' are directories and those that don't > > > are files. (Both examples are files.) > > > > No, too restrictive. I don't like this and would hate having to remember > > it. > >