On Wed, Feb 12, 2003 at 09:17:22AM +0100, Stéphane Payrard wrote:
> On Tue, Feb 11, 2003 at 11:42:27PM -0800, Brent Dax wrote:
> > 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"?
>
> Indeed.
> Probably my proposition would make more sense in perl6 where the
> fileop could return "0 but true" in such a case.
> May be, it has already proposed and my thought was just a
> remembrance. :)
Hem, it would be more correct to say "'0' but true". Also my
proposition does (probably) make sense only for fileops that
originally returned a boolean value. Not so sure with these 'but's
that permit to smuggle alternate values of alternate types on the
side.
>
> [snipped]
>
> --
> stef
