That's the best way I've found. You might find the tests for Term::Complete interesting; that was the most challenging test I've ever written, I/O wise.

I don't have time to check right now, but can you tie *ARGV to fix readline() without a filehandle or a scalar? Something in the back of my brain thinks I've done this before.

In my posting on pre-empting STDIN during testing yesterday, I noted that my provisional solution had the following problem:

If the code being tested calls for input from STDIN more times than there are elements in the array tied to STDIN (or if those elements are undef), and if the user prompt is located (as is likely) within a while (<>) loop, then the program goes into an infinite loop because all elements of the tied array have been shifted off.

A simple change in Preempt::Stdin::READLINE() solves this problem: Croak if there are no elements left in the list provided to the subroutine; then capture and examine the error in the testing script.

Here's the revised Preempt::Stdin:

Read more... (500 Bytes)

And here's the revised testing script, starting with the two passing tests from yesterday and followed by a new test in which the error is captured and examined.

Read more... (1514 Bytes)

Two additional points.

First, as mentioned yesterday, if you wanted to capture all those prompt messages going to STDOUT, you could do so with IO::Capture::Stdout.

Second, if the subroutine being tested were more complex than the one above, there is a good chance that, in the case of insufficient arguments, warnings would be generated due to uninitialized variables. Since those warnings would be expected, you would probably want to suppress them during testing. You could so by defining a subroutine

sub _capture { my $str = $_[0]; }

and then calling

    local $SIG{__WARN__} = \&_capture;
    tie *STDIN, 'Preempt::Stdin', @lines;
    ...  # as before
[download]

at the top of the block.

To give credit where credit is due: The idea of capturing the error from a deliberately failing test and examining it with Test::More::like() was picked up from monk dha during our joint work on the Phalanx project. And the idea of capturing warnings within a block was picked up from (IIRC) Benjamin Goldberg on c.l.p.misc a couple of years back.

Jim Keenan

#!/usr/bin/perl
use strict;
use warnings;
use IO::Handle;
open (INPUT, "myfile")    || die $!;
if (my $fh = STDIN->fdopen(\*INPUT, "r")) {
    print <>;
    $fh->close;
}
close INPUT;
[download]

{
  local *STDIN;
  open(STDIN,'myfile');
  #local *STDIN = *MYFILE;
  print <>;
  close(STDIN);
}
[download]

my @lines = (
    'a string with numbers and letters 4678',
    '5678',
    '46789',
    ' 4678',
    '4678',
);
open (INPUT, '+<', "tmpfile")    || die $!;
print INPUT $_."\n" for @lines;
seek(INPUT,0,0);
if (my $fh = STDIN->fdopen(\*INPUT, "r")) {
    my $room = enter_number();
    $fh->close;
    print "Room:  $room\n";
}
close INPUT;
unlink 'tmpfile';
[download]

Revelation wrote: P.S: FYI, this is technique is generally called 'overloading STDIN'. Your searches would have been more successful, even on perlmonks, if you had used the proper vocabulary. :)

Really? What makes you think that?

I took your suggestion and did a Google Groups search for the exact phrase "overloading STDIN." Nothing on c.l.p.misc, c.l.p.modules or perl.qa.

I then Super Searched the monastery archives for that phrase. Had to hit the button at least 5 times. Had to go back to an April 29 2001 posting by chromatic (who else?) , Re: Problem with tie *STDIN, 'IO::Scalar', \$text;, to find a node that had contained both words (albeit separated from each other) and had some relevance.

Now, if I wanted to overcome the problem with the diamond operator, I would certainly have thought in terms of overloading, because operators are what one overloads. And in the node cited above, chromatic does speak of "overloading TIEHANDLE." But I don't think "overloading STDIN" is a phrase that people have commonly used.

Calm down, man. I wasn't trying to insult you or anything, just giving you a hint at a resource, which comes up if you search overloading STDIN: how do i redirect STDOUT, STDIN, or STDERR to a FILE? . There's something else that comes up on google, I believe, but legal issues prevent me from posting it.

I looked through the documentation for IO::Handle, IO::File, IO::Scalar, etc. while working on this ... and I confess I can't see the connection to my problem.

Both of your code examples refer to opening files. I don't see the connection to reading from STDIN. How, for example, would you rework my code samples with IO::Handle or the localization of STDIN?

Thanks for looking at this problem.

Jim Keenan

Using this approach, you can inject on the fly, interleave injections and reads, and also simulate EOF input conditions.

The following code, which should work back to Perl 5.6, shows one way to do it.

#! perl

use warnings;
use strict;

use File::Temp qw( tempfile );

# this function encapsulates the technique.
# it returns a function that can be used to
# inject input into the targeted file handle

sub inject_input {

    my $target_fh = shift;
    my ($temp_fh, $temp_fn) = tempfile();
    my $temp_fd = fileno $temp_fh;

    local *SAVED;
    local *TARGET = $target_fh;
    local *INJECT;
    open SAVED,  "<&TARGET"     or die "can't remember target";
    open TARGET, "<&=$temp_fd"  or die "can't redirect target";
    open INJECT, "+>>$temp_fn"  or die "can't open injector";
    unlink $temp_fn;  # we don't need the directory entry any more

    select((select(INJECT), $| = 1)[0]);

    my $saved_fh  = *SAVED;
    my $inject_fh = *INJECT;

    return sub {
        if (@_) {
            print $inject_fh @_;
        }
        else {
            seek $inject_fh, 0, 0 or die "can't seek";  # rewind
            my $injected_output = do { local $/; <$inject_fh> };
            close $temp_fh or die "can't close temp file handle";
            local (*SAVED, *TARGET, *INJECT)
                = ($saved_fh, $target_fh, $inject_fh);
            open TARGET, "<&SAVED"  or die "can't restore target";
            close SAVED             or die "can't close SAVED";
            close INJECT            or die "can't close INJECT";
            return $injected_output;
        }
    }
}
[download]

Here is an example of how to use the function:

# let us inject input into STDIN

my $injector = inject_input(*STDIN);

# the resulting injector takes a string to inject

$injector->("1234\n");       # inject 1234
print "r: ", scalar <STDIN>; # read 1234 back in

# now we can inject 5678, a, and b
# we can read them back in via a loop

$injector->("5678\n");       # inject 5678
$injector->("a\n", "b\n");   # inject a and b

while (<>) {
    print "R: $_";
}

# after the read loop reaches the EOF, we
# can still inject more input and read it

$injector->("we're outta here\n");
print "r: ", <>;

# when we are done, we call the injector with
# no arguments; this will close down the injection
# apparatus, restore STDIN to its pre-injection
# condition, and return a copy of what was injected
# for flight-recording purposes 

print "\n\nwe injected:\n\n", $injector->();

# now STDIN is restored

print "\n\nEnter text by hand:\n";
while (<>) {
    print "You entered: $_";
}

# actual output follows:

__END__
r: 1234
R: 5678
R: a
R: b
r: we're outta here


we injected:

1234
5678
a
b
we're outta here


Enter text by hand:
blah
You entered: blah
blah
You entered: blah
blah
You entered: blah
[download]

I hope this helps.

Cheers,
Tom

Tom Moertel wrote:

If you are on a Unix system, you can redirect STDIN to pull input from a file. You can also open the file a second time for appending to obtain an independent file descriptor. You can write into this descriptor to inject input into STDIN. ... Using this approach, you can inject on the fly, interleave injections and reads, and also simulate EOF input conditions.

Yesterday I was frustrated by the fact that, while there are several ways to redirect where STDIN is going to (by the command-line; by IO::Handle; etc.), there didn't seem to be a robust way of changing where it is coming from. After I logged off, I got to thinking about File::Temp (a module I've been using a lot lately as part of test building in the Phalanx project). I realized that there probably would be a way to use File::Temp to, in effect, fake out STDIN. But I then thought, "That's a lot of work for a simple problem."

Well, your subroutine does do a lot of work, but it has the virtue of hiding the work in a subroutine. I'll try to check it out today. Thanks for taking the time to present your approach.

Jim Keenan

This looks like what `expect` / Expect.pm is made for. It talks to the unit under test, waiting for a string and answering with another one.

Refactoring the verification into subroutines might be the best long term solution. Do you know that your program never ever will use a different form of input? What if you need to verify e. g. XML file input?

I did look at Expect.pm. I suppose my immediate reaction was: "This is immense. Which one of these dozens of functions could be the one I need?" In other words, the learning curve I would face for Expect seemed much greater than what I thought was needed for the task at hand. So I passed on it, but will definitely keep it in mind for similar projects in the future.

Thanks for responding.

jimk

You'll want to start with Expect::Simple. And, frankly, you can start with the following methods and probably never need more:
• send() - this is what you use to interact with STDIN
• before() - this is what the prompt was that you just sent stuff to with send()
• after() - this is what the program blabs to you after you send the stuff with send()

If you need more, then more reading is the thing to do. Note: As you've found out, interacting with STDIN is hard. Don't complain if you have to read for a few hours to have someone else take all the craziness out of it for you.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.