From my testing at the time I don't think it is possible to determine if a scalar is a filehandle or not. As you point out the IO:: objects would be difficult to handle.

The solution that I can up with was just to assume that any references passed to the function were filehandles and any scalars were filenames. Here is an extract from the code.

    # If the filename is a reference it is assumed that it is a valid
    # filehandle, if not we create a filehandle.
    #
    if (ref($OLEfile)) {
        $fh = $OLEfile;
    }
    else {
        # Create a new file, open for writing
        $fh = FileHandle->new("> $OLEfile");
        if (not defined $fh) {
            croak "Can't open $OLEfile. ......";
        }

        # binmode file whether platform requires it or not
        binmode($fh);

    }

    # Store the filehandle
    $self->{_filehandle} = $fh;
[download]

--
John.

Yea, I think that will be a better solution. The only point, after I've opened the file, that I actually care if it's a file is the overall while loop, so as long as I start that loop with an open filehandle or an IO::File object, I can just do the while loop on it:

while ( my $line = <$current_file> ) { ... }
# $current_file can be a filehandle or an IO::File obejct
# or anything else that responds appropriately in the < >
# construct.
[download]

Besides making that change, I think I'll also closure-off the internals of that loop; it will be much easier to write the other suggested functions that I put in the desc of this code; in addition, I can see an 'fmap' function and a few other things that as long as I have a function that determines what you do with a line, it doesn't matter what else goes on.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

... if you had binary files that you wanted search ...

I actually meant ASCII files with one or two corrupt lines containing binary data - more specifically ^Z - the DOS EOF character which perl sees as the perfect opportunity to jump out of a while loop early (unless binmode is in effect).

I'm not sure what you mean by

Unfortunately, turning binmode on by default would be problematic as well.

but I think I have a solution - use open. The open pragma affects I/O ops for the script and from perldoc open comes the following snippet

The ":raw" discipline corresponds to "binary mode" and the ":crlf" dis
+cipline corresponds to "text mode" on platforms that distinguish betw
+een the two modes when opening files (which is many DOS-like platform
+s, including Windows). These two disciplines are currently no-ops on 
+platforms where binmode() is a no-op, but will be supported everywher
+e in future.
[download]

which may solve whatever problems you are suggesting binmode causes.

   larryk                                          
perl -le "s,,reverse killer,e,y,rifle,lycra,,print"