in reply to Re: Function that accepts either a file name or a handle
in thread Function that accepts either a file name or a handle

The heart of Scalar::Util's openhandle() is

defined(fileno $arg)

which was my first thought. It goes a bit further to try to deal with tied file handles (that you might be able to read from, etc. even though they don't directly contain an open file descriptor).

If one wants to do something other than read/write the handle (for example: stat or select), then I'd just use defined(fileno $arg) (since stat and select aren't going to work on tied handles anyway).

My second thought was that if one just wants to read from the handle, can might offer a simple and high-quality solution. I didn't produce a working example of that because I decided my third thought was even better in that case...

eval{<$arg>} was my third thought. But testing reminded me that <...> doesn't give you any reasonable way to distinguish "end of file" from "error reading"1.

1 I first discovered this when writing a book on Perl. No, it never got finished. The editor had health problems, the publisher didn't follow through, then I no longer had time.

- tye        

Replies are listed 'Best First'.
Re: Re^2: Function that accepts either a file name or a handle
by eyepopslikeamosquito (Archbishop) on Apr 21, 2004 at 08:25 UTC
    eval{<$arg>} was my third thought. But testing reminded me that <...> doesn't give you any reasonable way to distinguish "end of file" from "error reading".

    I don't understand how eval could be employed since the following program does not die when you read from <$fh>:

    my $fh = 'f.tmp'; my $s = <$fh>; print "i am here: s='$s'\n";

    That is, there is nothing to catch.

      That is, there is nothing to catch.

      Yes. That was why the second sentence started with "But".

      - tye