How about this?
open '/etc/passwd'; # file
open '/usr/local/bin/'; # directory (note the trailing '/')
open 'ftp://ftp.perl.org/'; # ftp
open 'http://www.yahoo.com/'; # http
open 'ldap://ldap.bigfoot.com/';# ldap
I think
This is nutso... shall we open-ssh and open-telnet and
open-any_protocal_under_the_sun in the core?
Well, just because the hooks are there doesn't mean all the member
modules have to be in core. The idea would be, as Tom Hughes suggests:
That is if the core provides a way for modules to
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp
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
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"
Sam Tregar wrote:
How is this better than File::Spec's approach?
File::Spec has the idea and representation dead on. However, the
interface is a pain; to write portable scripts you have to go through
some contortions.
With URI support, you still have to contort a little, but not as much.
So, what's so portable about file:// URLs again? How do they magically
know that //c/ means / on UNIX? What do they do with //z/?
This is only one example. I'm not sure it's the best way. It's
definitely not the only way. Chaim asked:
Or for that matter "file://u/frankeh/Projects" become?
Graham Barr wrote:
Create a new handle, like $DEFOUT. Then there would be no need
for selectsaver either as you would do the equiv. of
local($DEFOUT) = $newhandle;
Just submitted an RFC on this exact idea.
-Nate
Have you also looked at Damian's Text::Autoformat, which has a renewed format
implementation that looks *very* good a candidate for replacing perl 4/5's
format.
Yes, I have. It's actually very powerful. I've actually been meaning to
talk to Damian about this, because at one time he had
Jon Ericson wrote:
I would want it to return @items:
@sorted = sort print @items;
I'd prefer a different name (tee?) and keep print as it is.
Pretty much all the stuff being discussed right now can be stuck in a
module:
package Print::Variations;
use Exporter;
@EXPORT =
[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
All-
This is an idea I've been chewing on for some time. RFC 14 proposes a
new syntax to open():
$FH = open dir "/usr/local/bin" or die "Badness: $!";
which is far different from the current open(). This is actually a more
flexible and consistent syntax, with a cool feature I just came
Glenn Linderman wrote:
I have a number of scripts that use this sort of facility, using push/shift
to populate/read the array "file". These could be made simpler and more
general by wrapping the array as a file.
Perhaps the open "handler" stuff could be used to implement this?
[ for those on -all or -objects this is gonna look real familiar :-) ]
All-
As Nat has mentioned on -meta, it's time to start wrapping things up. In
particular, I think the following "deadlines" should apply:
1. Any and all *new* RFC's should be submitted by Wednesday at the
absolute
Michael G Schwern wrote:
On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote:
$fo-untaint - Removes tainting from that data source
I can guarantee this will be abused and severely water down the
utility of taint mode.
Well, as Tom pointed out to me this already
Tom Christiansen wrote:
Scalars hold references to objects. Filehandles should, ultimately,
be objects, as should directory handles.
I haven't yet seen anybody yet propose bifurcating {file,directory}handles.
This would certainly be nice.
If I'm understanding what you mean, I believe
I'd rather see you drop (or footnote) the discussion of how the various
systems are going to map content among themselves, and focus more on
what the construct allows. For instance, returning to some of the
original implementation ideas, that the location information be passed
to the
We've only got 4 days left until the One True Deadline on this whole
thing. Please, go check this out:
http://dev.perl.org/rfc/overdue-perl6-language-io.html
And get your RFC's finished up. Remember: Oct 1st is a true deadline,
coming from the powers above, meaning if your RFC is not frozen by
you would do:
$sock = AIO::Open( Host = 'www.perl.org',
Port = 80 ) ;
Similarly for LWP you would just do:
$sock = AIO::Open( Url = 'http://www.perl.org' ) ;
$event = AIO::Open( Host = 'www.perl.org',
Port
19 matches
Mail list logo
