in reply to Passing filehandles to subroutines

I know this isn't strictly answering the question, but after a lot of pondering I came to the conslusion that removing the filehandle from the print, and selecting the correct filehandle increased the functionality of my code dramatically.

For instance, say I have a function that generates HTML, I can (a) use it 'vanilla' style under a webserver and get a webpage, (b) tie a filehandle to a scalar, select it and manipulate the resultant HTML programmatically, or (c) select a normal filehandle for placement into a content management hierarchy (or whatever). Same function, different results.

rdfield

Replies are listed 'Best First'.
Re^2: Passing filehandles to subroutines
by Aristotle (Chancellor) on Jan 27, 2003 at 11:46 UTC
    I'd prefer to keep an explicit filehandle on my prints and default it as in $fh ||= \*STDOUT or something like that. I still get all of the functionality you mention and without having to mess with a global variable (ie the "selected filehandle").

    Makeshifts last the longest.

      I knew I'd come up with a concrete counter-example eventually :)

      I use Pod::HTML in a mod_perl handler to generate "Help" screens on the fly when a user clicks on the Help menu item in my CGI application. The module uses a named filehandle, which when used in "interactive" mode is opened against "". Works great from the command line - but completely baulks under mod_perl. Back to the drawing board: I worked around it by supplying it with a temporary (session based) file name, and then reading the resultant file and printing it to (what appears to be) STDOUT.

      rdfield

        I don't see why the same approach wouldn't be applicable in that case if you do it right. Have you tried something like the following?
        open PODHTMLFH, ">&=STDOUT" or die "Can't dup STDOUT\n"; # or even more generically open PODHTMLFH, ">&=".fileno(STDOUT) or die "Can't dup STDOUT\n";
        Temporary files are icky.

        Makeshifts last the longest.