Instead of passing a file list, I could have the array by a mixed set of either filehandles or scalars. If it's a filehandle, it will be assumed to be an OPEN file handle, such that it will read right from the file. Otherwise, it will do the same as above. The only problem here is trying to determine the difference between a scalar and a filehandle. I can't think of an easy test that will capture all the possible cases of filehandles, including those that are from the IO:: modules. If anyone has any ideas, that would be helpful.

But obviously, if this was in place, then if you had binary files that you wanted search, it would be rather trivial to create a list of open filehandles, all set to binmode, before passing to this function.

-----------------------------------------------------
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

I ran into this problem in the past when trying to allow a function to accept filenames or filehandles.

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]

This isn't bullet-proof but if the documentation is explicit then it may be sufficient.

--
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"