note
w-ber
<p>
About the use of <code>require</code> in this example... Here is a complete
working example that captures Parse::RecDescent output in a dup'd anonymous
filehandle, which shows that <code>use</code> and <code>require</code> are
<em>not</em> equivalent in this case.
</p>
<readmore>
<code>
use strict;
my $ParseErrorFh;
BEGIN {
open(my $olderr, '>&STDERR') or die "Cannot dup STDERR: $!";
close STDERR or die "Cannot close STDERR: $!";
open(STDERR, '+>', undef) or die "Cannot open anonymous file: $!";
select STDERR; $| = 1;
open($ParseErrorFh, '>&STDERR') or die "Cannot dup anonymous file: $!";
require Parse::RecDescent;
close STDERR or die "Cannot close STDERR: $!";
open(STDERR, '>&', $olderr) or die "Cannot restore STDERR: $!";
}
sub parse {
my ($grammar, $str) = @_;
local $::RD_ERROR = 1;
local $::RD_WARN = 2;
seek($ParseErrorFh, 0, 0);
my $p = Parse::RecDescent->new($grammar)
or die "Grammar is invalid";
my $x = $p->start($str);
if (not defined $x) {
seek($ParseErrorFh, 0, 0);
die join '', grep { $_ !~ m/^\s*$/ } <$ParseErrorFh>;
}
return $x;
}
print parse('start: /foo/ | <error>', 'fo'), "\n";
</code>
<p>
Running this you will get the output
</p>
<code>
$ perl rectest.pl
ERROR (line 1): Invalid start: Was expecting /foo/
</code>
<p>
Now, if you change <code>require</code> at line 13 to <code>use</code>,
</p>
<code>
$ perl rectest2.pl
ERROR (line 1): Invalid start: Was expecting /foo/
Died at recdescent.pl line 34.
</code>
<p>
Here, the first two lines are <em>printed to STDERR</em>, while the
last one indicates that nothing is captured in the dup'd filehandle.
Regardless of what the documentation says about <code>use</code>
being equivalent to <code>require Module; import Module;</code>,
this example shows that it is not the case this time.
</p>
</readmore>
<blockquote><em>Anyway, it would be cleaner to re-open
Parse::RecDescent::ERROR.</em></blockquote>
<p>
Yes, it definitely would be. This is what I tried first. Here is a complete
example (did you try to run your own example code?):
</p>
<code>
use strict;
use Parse::RecDescent;
sub parse {
my ($grammar, $str) = @_;
open(local *Parse::RecDescent::ERROR, '>', \my $error)
or die "Cannot open in-memory filehandle: $!";
local $::RD_ERROR = 1;
local $::RD_WARN = 2;
my $p = Parse::RecDescent->new($grammar)
or die "Grammar is invalid";
my $x = $p->start($str);
defined $x or die $error;
return $x;
}
print parse('start: /foo/ | <error>', 'fo'), "\n";
</code>
<p>
Result:
</p>
<code>
$ perl recdescent3.pl
Undefined format "Parse::RecDescent::ERROR" called at /usr/share/perl5/Parse/RecDescent.pm line 2910.
</code>
<p>
Clearly <code>format</code> has a side-effect that prevents the use of the
nice solution this time. Besides that, your re-open of <code>ERROR</code>
requires knowledge of the package internals, while redirecting
<code>STDERR</code> requires arguably less knowledge, and certainly not the
name of a private (albeit package global) variable.
</p>
<div class="pmsig">
<div class="pmsig-399589">
<p>
-- <br>
say "Just Another [href://http://prometheus.frii.com/~gnat/yapc/2000-stages/slide36.html|Perl Hacker]";
</p>
</div>
</div>
710640
710872