Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

"David L. Nicol" wrote: > Nathan Wiger wrote: > >3. There's no way to have them interpolated in strings into > > something potentially useful. > > The string value of a file handle. Hmm. Is it's internal file > descriptor number? Umm... that's the numeric value of a file handle, ri

Re: "Standardization" of Perl IO functions

Nathan Wiger wrote: > 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 co

Re: RFC 39 (v3) Perl should have a print operator

Tom Christiansen wrote: > Again, I can't *ever* remember wanting a function that did this. Rare things > shouldn't have hard-to-figure-out names. Why do you want it? Debugging or > something? Have you tried tie? I've found myself wanting this operator several times since I wrote the RFC - mos

Re: RFC 39 (v3) Perl should have a print operator

Bart Lateur wrote: > Also, > > print @items; > > should then return join($,, @items).$\ I would want it to return @items: @sorted = sort print @items; I'd prefer a different name (tee?) and keep print as it is. Jon -- Knowledge is that which remains when what is learned is forgott

Re: RFC 39 Perl should have a print operator

Ken Rich wrote: > How about quotes? A quoted lhs expression could mean print. A quoted lhs > expression preceded by a file handle could mean print to filehandle. Have you seen ? > Tom Christiansen's complaint seems irrelevant to me because a print > statement i

Re: RFC 39 (v3) Perl should have a print operator

Bart Lateur wrote: > For input, the handle is marked as a source: > > $data = ; > > In order to be symmetrical, your ousput handle should look and act like > a sink: > > >STDOUT< = $data; > > There. Now it's symmetrical. = $data; is symmetrical. I am considering thi

Re: RFC 39 (v3) Perl should have a print operator

Tom Christiansen wrote: > Perl already *has* a print operator: "print". :-) I think what I really want is a tee operator. > The problem with what you have there is that it hides the act of > output within an arbitrarily long circumfix operator whose terminating > portion is potentially very far

Re: RFC 34 (v3) Angle brackets should not be used for file globbing

Tom Christiansen wrote: > >=item Complex filehandle references > > >my %filesystem; > >my $filename = '/etc/shells'; > >open $filesystem{$filename}, $filename > >or die "can't open $filename: $!"; > >print <$filesystem{$filename}>; > >__END__ > > >GLOB{0xa042284}

Re: RFC 39 (v2) Perl should have a print operator

Jonathan Scott Duff wrote: > On Thu, Aug 17, 2000 at 03:30:09PM -0700, Jon Ericson wrote: > > Nathan Wiger wrote: > > >3. Can you support here documents with this syntax? > > > > I haven't thought about this yet, but you can always use print. > >

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

Perl6 RFC Librarian wrote: > The new C<$DEFIN> accomplishes a similar thing, but with > input. Currently, the special <> filehandle acts on one of > two things, either C<@ARGV> or (if C<@ARGV> is > empty). This is not strictly true. <> is shorthand for . ARGV is the special filehandle that ope

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

Perl6 RFC Librarian wrote: > With C<$DEFERR>, all error functions are set to act on it > instead of C<$STDERR> by default. So, the Perl 6 version > of the above is replaced by a single, simple line of code > at the top of your main program: > >$DEFERR = $ERRORLOG unless $have_a_tty; open S

Re: RFC 39 (v2) Perl should have a print operator

Nathan Wiger wrote: > > > >"Print this line.\n"<; > > Some questions: > >1. How do you specify alternate filehandles to output to? > select() doesn't count for the purposes of this question. It's a shortcut, not a replacement. Rumors of select's death are greatly exaggerated. >

Re: RFC 39 (v2) Perl should have a print operator

Nathan Wiger wrote: > We should consider if this *adds value* to Perl 6. If not, we should > start trimming down some RFC's and retracting them. If this RFC presents > a significant win, we should keep it. If not (I personally don't see > one), we should retract it. > > I'm not claiming to be aut

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. > >

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

Nathan Wiger wrote: > In another email you asked: > > > Why not extend C to be able to take other things besides > > strings of text? This wasn't me. > Registering a custom handler has this capability. For example: > >use handler 'myhttp' => MyCustomMod; # upcoming syntax >open myhtt

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

Nathan Wiger wrote: > 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 "http://www.perl.com/"; Explicitly register custom handles: use myhttp; register open, 'http' => myhttp::new;

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

Perl6 RFC Librarian wrote: ># Open a remote webpage >$http = open http "http://www.perl.com/", GET; ^ >@doc = <$http>; >print @doc if $http->content_type eq 'text/html'; >close $http; This open seems awfully crufty to me. The U

Summary of I/O related RFCs

=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 impl

Re: RFC 51 (v2) Angle brackets should accept filenames a

Chaim Frenkel wrote: > >>>>> "JE" == Jon Ericson <[EMAIL PROTECTED]> writes: > JE> $gaz contains the second line. Otherwise this: > > JE> while (<'filename'>){print;}; > > JE> won't work. This gets a little hairy

Re: RFC 51 (v2) Angle brackets should accept filenames a

Chaim Frenkel wrote: > What does > > $foo = <"filename">;# 1 > $bar = <"another">; > $gaz = <"filename>; # 2 ^ add " here > Does #2 get the second line or the first? $gaz contains the second line. Otherwise this: while (<'filename'>

Re: RFC 66 (v1) Shell Style Redirection

Matthew Persico wrote: > Jon Ericson wrote: > > open(STDERR, ">&STDOUT) || die "Can't dup stdout: $!"; > > > > I don't find this hard to read or write. I think overloading < and > > > to do this would be confusing and rarely us

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

Perl6 RFC Librarian wrote: > =head2 Extensible Class Bindings > > In addition to the standard file form, C can also now take an > optional class name from which to load the appropriate methods. This > gives us easy access to methods that open Directory, Socket, HTTP, FTP, > or other types of file

Re: RFC 66 (v1) Shell Style Redirection

Perl6 RFC Librarian wrote: > =head1 DESCRIPTION > > I think we've got file re-opening already, some how; this > proposal overloads the less than and greater than operators > in order that subsequent statements, > particularly external routines that will be looking to > a file descriptor table for

Re: Treating filehandles like strings

Hildo Biersma wrote: > Jon Ericson wrote: > > You misunderstand. I want to write this: > > > > open my $file, '/path/to/file' or die "can't open $file: $!"; > > # code passes > > # /path/to/file is removed by another process > &g

Re: Treating filehandles like strings

Bart Lateur wrote: > On Mon, 07 Aug 2000 17:43:29 -0700, Nathan Wiger wrote: > >> I'd rather have a filehandle stringify to > >> the filename instead. > > > >Great minds think alike. :-) I was actually going to add this to the new > >version of the open() RFC as a possible use of RFC 49's > >soon-

Re: RFC: println()

[Reply-To set to [EMAIL PROTECTED]] Ed Mills wrote: > > I actually saw this in the newsgroups and thought it was a neat idea. What > about > >println $textvar; > > instead of > >print "$textvar\n"; > > Ever so much easier to read and write, prints the arg and appends \n. You can cur

Re: RFC 51 (v1) Angle brackets should accept filenames a

Monty Taylor wrote: > open(FOO,' @LIST=['FOO','.bashrc']; > while (<@LIST>) { > process; > } > > and a directory containing the files FOO, foo.txt, and .bashrc > > Does <@LIST> treat FOO as a filehandle or a filename? Or maybe this > would be clearer... I am assuming that bareword filehandles

Re: Treating filehandles like strings

[Reply to perl6-language-io as this is an I/O related.] Michael Mathews wrote: > > Here's a thought. Wouldn't this be cool (see below)? The idea is that in > Perl 6 you should be able to read from a file handle one character or one > line at a time (just like you can in Perl 5) BUT if you just g