Front page | perl.perl5.porters |
Postings from February 2003
Stéphane Payrard:
# I was so sure that, in case of success, the file operators
# would return the filename that I wrote the following code to
# print where are the perl interpretors in the PATH. But, in
# case of success, fileops returns 1 not the filename.
#
# local $, = '\n";
# sub mapgrep (&@) { my ($fun, @args)=@_; map { &{$fun}($_)
# } grep { &{$fun}($_) } @args }
# print (mapgrep { -x "$_/perl" } split /:/, $ENV{PATH}), "\n";
#
# Is there a reason why file operators don't dwim?
So you don't have problems with a file name that isn't true, like "0"?
I'm not convinced that that's WIM for the average case. For your case
it certainly is, but that's not the average case, is it? :^) Part of
the reason might be to discourage people from doing things like:
-x -r $foo
Which is less efficient than:
-r $foo and -x _
Granted, that's something that could be optimized, but that isn't really
the point. I just don't think an example like yours is all that common.
Why risk problems in Boolean contexts for a feature that won't be used
very much?
--Brent Dax <brentdax@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Thread Previous
|
Thread Next