Re: [Expectperl-discuss] How not to receive my own STDOUT?

[<RGi...@a1...>]

> > But then the first expect call picks up "das", and the next gets
> > "ARTDEF". I thought $pid->expect() was supposed to read the child's
> > output, not its input. Am I mistaken?
> 	
> 	By default a terminal will echo its input. You may need to turn
> echoing off via stty("raw") or "-echo".

Right, that's the problem.  Pseudo-terminals usually start off with 
echoning enabled (also CR->LF translation and a lot of other things).  
Best thing to do is to set the pty to 'raw', so no processing takes 
place.  I have just added a new method raw_pty() to the latest beta 
version, so what you would do if you use that version is:

  my $tagger = new Expect;
  $tagger->raw_pty(1);
  $tagger->spawn("/path/to/tagger", ...) or die;
  foreach my $text (@text) {
    $tagger->send("$text\n");
    my @tags;
    $tagger->expect($timeout,
                    # grab a line
                    [ ".*?\n" => sub { my $self = shift;
                                       my $tag = $self->match();
                                       chomp $tag;
                                       push @tags, $tag;
                                       exp_continue; # go on
                                      } ],
                    # finished with processing
                    [ "$endtag" => sub { my $self = shift;
                                         my $endtag = $self->match();
                                         chomp $endtag;
                                         push @tags, $endtag;
                                         0; # stop expecting here
                                       } ],
                    # error handling
                    [ 'eof' => sub { die "Tagger exited" } ],
                    [ 'timeout => sub { die "Tagger took too long" } ],
                   );
    # do something with the tags
  }

This presumes that there is an endtag that gets sent when the tagger is 
done with the word or that there is some other way to recognize the 
end.  Using a timeout isn't really reliable and can lead to spurious 
failures.  Anyway, that's your problem. :-)

Hope this helps,

Roland
--
RGi...@cp...