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
