You could probably get by with overloading TIEHANDLE() and READLINE(), though your needs will determine that. I can provide code if you really need some, but it's pretty plain in perltie.

Update: Perhaps I've not made myself clear. Yes, I've found myself in exactly the same situation you describe. Trying to integrate HTTP::Daemon with CGI is a hassle -- HTTP::Daemon produces a HTTP::Response object that allows you to get at posted data via the content() method (I may have the names slightly wrong, but the idea is the same). CGI reads from STDIN or another filehandle.

The solution was to make a tied filehandle, pass it to the CGI.pm constructor. This let me intercept the READ and READLINE calls from CGI.pm to the filehandle, pulling data out of content(), manipulate them as desired, and pass them along.

As far as HTTP::Response knew, I was doing normal stuff. As far as CGI.pm knew, it was reading from a normal filehandle.

Yes, it would be nice if they knew how to play together. At the cost of writing 30 lines of glue code, I faked them out.

That is why I brought it up -- it will let you do just what you describe.

Hi chromatic

At some other time I will probably follow your advice and learn how to subclass Tie::Handle to solve some specific problem.

At this stage I am raising what to me looks like a general perl programming question:

Some popular perl modules export subroutines that read text from specified input file(s), defaulting to STDIN, transform the text, and deliver the result to a specified output file, defaulting to STDOUT. This is fine in many applications.

Two subroutines that behave like this, and that I'm interested in right now are

Pod::Html::pod2html
Pod::Select::podselect
[download]


However, I want to call these subroutines in a context where the input text or output text, or both, are in my script's scalar variables. This lets me do some other processing before calling one of these subroutines, and some more after the call.

I would like to know if other monks have had this of requirement or wish.

While I can easily solve my problems by using temporary files, out of curiosity I started looking for a more perlish solution. Following stephen's advice, I was able to redirect podselect STDOUT into a IO::Scalar tied to a scalar variable (see the first snippet in my post above). However, my attempt to use a similar redirection on STDIN to pod2html failed. I will try to dig deeper to try to understand why does it work when it works, and why not when not.

Rudif

As to the real issue...
You are tie'ing a scalar to the global symbol for the STDIN filehandle. Then you try to open the real STDIN using a trick perl provides. Even if your method could work, which it won't, It is a BAD IDEA(tm) to open a file handle twice.

You should be trying to dup(2) the filehandle since it is already open. But that won't work either.

The tie() doesn't create a real filehandle in the OS sense of the term. It just lets you intercept calls to the mid-level Perl abstraction of a file handle. This is fine because the Perl abstraction is access via a known API. open(FH, "<-") is trying to open the REAL filehandle. Further, the Perl FileHandle TIE API doesn't provide functions for open() or dup() (interestingly it does provide CLOSE).

So what is a perl-coder supposed to do? Well I don't know cuz you didn't show the real problem you are trying to solve and the assosiated code.

Where you have:
open TSCLR, "<-" or die "can't open <-";
you could replace it with:
local *TSCLR = \*STDIN;
This works at the name space level.

If you went all the way using the OO Perl file handle modules, you could have code that works this way:

use IO::File ();
use IO::Scalar ();

sub do_stuff_with_a_fh {
  my ($fh) = @_;
  ...do stuff...
}

my $str = "this is my string";
my $fh_scalar = IO::Scalar->new(\$str)
  or die "failed to create fh from str: $!";

do_stuff_with_a_fh($fh_scalar);

my $fh_stdin_duped = IO::File->new("<&STDIN")
  or die "failed to dup stdin: $!";

do_stuff_with_a_fh($fh_sdtin_duped);
[download]

Please post an update, and we can help you further.

P.S. Yes that pod2html() function from Pod::Html uses implicit inputs and outputs. See, that proves my point about subroutines with no inputs and ouputs. It restricts the flexability. It could have been pod2html($fh_pod_input, $fh_html_output).

Well I don't know cuz you didn't show the real problem you are trying to solve and the assosiated code.

pod2html() function from Pod::Html uses implicit inputs and outputs.
It could have been pod2html($fh_pod_input, $fh_html_output).

But it is not, and hence my problem.
I want to feed text from a scalar variable to a subroutine that reads from STDIN. Specifically, I want to convert some pod text from a scalar variable to a html file, using Pod::Html::pod2html.

This here does the job, but it uses a script pod2html.pl that wraps the sub Pod::Html::pod2html:

sub string2Html {
    my ($htmlfilename, $podtext) = @_;
    open PIPE, "| pod2html --outfile $htmlfilename"; 
        # works, because there is a pod2html.bat
    print PIPE $podString;
    close PIPE;
}
[download]

I would like to replace it by something like this, not using a separate script and pipes or temporary files:

sub string2Html {
    my ($htmlfilename, $podtext) = @_;
    ### some code that causes pod2html to read from scalar \$podtext;
    ### when it wants to read from STDIN
    Pod::Html::pod2html "--outfile $htmlfilename";
    ### code to wrap up 
}
[download]

I hope that this clarifies what I am trying to solve.

Rudif

Thanks for the clarification. I should have read your original post more thoroughtly.

I tried all my tricks to fake out &Pod::Html::pod2html, but I can't make it work without resorting to pipes.

If you wish to resort to pipes, the following Worked For Me(tm).

use strict;
use IO::File;
use IO::Pipe;
use Pod::Html qw( &pod2html );

# I only use $fh to get a pod string, It is not part
#  of the solution.
my $fh = IO::File->new("<foo.pod")
  or die "filaed to open foo.pod: $!";
$fh->input_record_separator( undef );
my ($str);
$str = $fh->getline();
$fh->close;
# Got the pod string in $str
 
my $pipe = IO::Pipe->new()
  or die "failed to create pipe: $!";
 
my ($pid,$fd);
if ( $pid = fork() )
 { #parent
 
   open(TMPSTDIN, "<&STDIN")
     or die "failed to dup stdin to tmp: $!";
 
   $pipe->reader();
 
   $fd = $pipe->fileno;
   open(STDIN, "<&=$fd")
     or die "failed to dup \$fd to STDIN: $!";
 
   pod2html();

   open(STDIN, "<&TMPSTDIN")
     or die "failed to restore dup'ed stdin: $!";
 }
else
 { #child
   $pipe->writer();
 
   $pipe->print($str);
 
   $pipe->close();
 
   exit 0;
 }

$pipe->close();
 
exit 0;
[download]

I think this will work satifactorally even on the Win32 port of Perl. Win32 doesn't really fork(), it just creates a thread. But I restore the original STDIN and the child dies pretty quickly.

Sorry this is sorta off on a tangent, but why the hostile attitude towards subroutines?

Obviously, implicit modification of globals CAN be a Bad Thing™ if it's done in such a way that it's hard to follow, but if you're writing a small script,and pressed for time, and you're careful to document what you're doing, it's a timesaver. What other problems does it cause that I don't know about?

I've always thought of subroutines as just that - named blocks - and to me, that makes them a handy way to document or re-use code, even if they don't take args or return anything explicitly.

Have I overlooked some major diabolical evil that subroutines are capable of without knowing it? Or is my perl style just lacking for want of experience?

---

"All generalizations are incorrect, including this one." Anonymous

I think you have overlooked some major diabolical evil :).

Named blocks, as opposed to functions, HIDE the external effects of the block from the reader. Using the name of the block as some kind of documentation feature is a poor choice.

Even if you want your subroutine to affect globals, you can pass globals in and return new values for globals. This "documents" your named block even better; explicitly telling the reader what this chunk of code depends on and what it changes.

$GLOBAL1 = do_stuff($GLOBAL0, $GLOBAL1);
[download]

is MUCH better than:


... set globals ...
...
do_stuff;
...
... use modified globals
[download]

I have had to read code like this (and it is very hard):


&read_input;
&calculate_this;
&calculate_that;
&write_output; # some to files others to databases
               # all in one function.

sub calculate_this { ... }
sub read_input { ... }
sub write_output { ... }
sub calculate_that { ... }
[download]

This was horrible. I was tempted to just remove the "sub" lines, but then I noticed the subs were not declared in the order they were used. As I paid more attention, some variables inside the subs were my()'ed but had the same name as globals.

We had to audit this code to make sure it was calculating money dispusements correctly. How can you audit this code?

It was painfull to read, impossible to audit, and such a rats nest it was difficult to modify. I lay most of the blame at the fact that it was using globals, locals, and named blocks. Writing functions force a certain amount of structure. Even if the structure is lame it is emminently more readable and auditable.