RFC 66 (v2) Shell Style Redirection
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Shell Style Redirection =head1 VERSION Maintainer: David Nicol <[EMAIL PROTECTED]> Date: 8 Aug 2000 Last Modified: 5 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 66 Status: Developing =head1 ABSTRACT The C pragma or a new C keyword is introduced to allow redirection of streams of any kind into each other. The keyword may not be really needed, as when does it make any sense to do a lt or gt comparison with a file handle? =head1 SUMMARY sub callfritz{ local STDIN < $InputData; local STDOUT > PREVIOUSLY_OPENED_HANDLE; eval `cat fritz.pl`; }; is proposed as an alternative to doing the same thing with a variety of open2 calls. =head1 DESCRIPTION As an alternative to the Bourne shell style C syntax described in `perldoc -f open`, 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 their file handles, will get from and give to where we want them to. The redirection is affected by the scoping operators like any other variable which alters the situation. It will also provide another way to capture STDERR from within backticks. sub ToolErrorsFirst{ # place to hold the output my $tooloutput; # place to hold the errors my $errors; # use redirect: very similar to shell redirection my use redirect STDOUT > $tooloutput ; # alternately, FILE > $scalar is obviously a redirect # (if we accept the overload of >) # so no additional keywords are required my STDERR > $errors ; $tooloutput = `tool @_`; return $errors . $tooloutput; }; Currently I do this kind of thing by using the file system as temporary storage. another use of the angle brackets would be as a single-character print operator, similar to << in C++ streams. print $abc; print OUT $z; # one way to do it < $abc; OUT < $z; # another way to do it Left-angle could differ from C by returning the file handle, instead of a success code, making C++ like constructions possible: < $this < "and" < $that;# same as print "${this}and$that" =head1 IMPLEMENTATION We need overloading based on type. The < operator will be like C when there is a file handle on the left side, it will be like assigning from when there is a file handle on the right, and it will be like the Bourne shell duplicate C when there are file handles on both sides. Setting up a way to trap the standard error from a forked process and load it into a scalar -- will that be difficult? =head1 MIGRATION Code that compares file handles, or compares file handles with scalars, will break. =head1 CHANGES discussion of C++ and use of < as a print operator =head1 REFERENCES RFC 39: Perl should have a print operator RFC 61: Interfaces for linking C objects into perlsubs
Re: RFC 66 (v2) Shell Style Redirection
> sub callfritz{ > local STDIN < $InputData; > local STDOUT > PREVIOUSLY_OPENED_HANDLE; > eval `cat fritz.pl`; > }; Unclear what you really mean there with the eval. But why not simply allow open(local *STDIN, "< $InputData"); open(local *STDOUT, ">&PREVIOUSLY_OPENED_HANDLE"); to do the obvious thing? You are very close to that now. >is proposed as an alternative to doing the same thing >with a variety of open2 calls. That's unneeded even now. >=head1 DESCRIPTION >As an alternative to the Bourne shell style C syntax >described in `perldoc -f open`, this That's a legacy term. I would avoid it. >It will also provide another way to capture STDERR from >within backticks. And pray tell, what's so onerous about the status quo? >Currently I do this kind of thing by using the >file system as temporary storage. I think you're doing that the hard way then. No need for such. >another use of the angle brackets would be as a single-character >print operator, similar to << in C++ streams. EW No, no, no. Please don't do this. It is naughty to hide I/O operations inside cutesy overloaded punctuation. Perl is already too punctuation heavy. This helps nothing. It only makes it all worse. If you want to use print, why make a short cut? Just use print. We get so beaten up already over instead of readline(FH), and now we're getting worse. --tom
Re: RFC 39 (v3) Perl should have a print operator
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote: >Those are not the semantics of print. It returns true (1) if successful, and >false (undef) otherwise. You cannot change that. If I write print "0", it >bloody well shan't be returning false. Oh, why not? Does anybody actually *ever* check the return value of print? I think it's not as if we'd break a lot of code. Problem is: if you need defined() to see if the print was succesful, you cannot return what was printed as well. It's one thing or the other. So you cannot have it both ways. -- Bart.
Re: RFC 39 (v3) Perl should have a print operator
>On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote: >>Those are not the semantics of print. It returns true (1) if successf >>false (undef) otherwise. You cannot change that. If I write print "0", it >>bloody well shan't be returning false. >Oh, why not? Does anybody actually *ever* check the return value of >print? Yes. > I think it's not as if we'd break a lot of code. Don't worry, Mercutio, 'tis but a small wound. >Problem is: if you need defined() to see if the print was succesful, you defined() is superstition. I said true and false. If I say true, I don't want you testing against 1. If I say false, I don't want you testing definedness. Most tests like this should be true or false. >cannot return what was printed as well. It's one thing or the other. So >you cannot have it both ways. I don't *WANT* it to return what it alleges to have printed. That's stupid, since I can always get that myself. I don't need it to tell me this! --tom