graff and ikegami,

Thanks++ to both of you. After getting a lot of inspiration from all your posts I tracked the problem down to the diamond operator, "<DATA>". A working, although possibly nonportable, version is at the bottom of this post.

In my current environment (Linux 2.6, Perl 5.8) it isn't necessary to use syswrite; ordinary print statements work fine after setting autoflush ($| = 1.) This is very fortunate because I would like to stay away from modifying the guts of Perl Expect.

The sleep statement that graff put in actually works like this: Perl is already trying to do buffered input on DATA in the inner script, and it tries to grab some of the input from the pipe. It hangs on to it when sysread is called. (That baffled me for a while, but putting a "print <DATA>" at the end of the script printed the missing first lines of input.) When I changed the sysread to read it worked reliably... on my current platform. A simple getc also works... again, on my current platform.

If anyone can explain the real difference between Perl's sysread and read I'm all ears. What I found refers me to the documentation on the Unix functions read and fread, which look almost the same. Is using read or getc in this script likely to break if it's ported to a different operating system?

If I do need to use sysread to avoid portability issues, I'm very much loath to put a sleep into production code. I tried select undef, undef, undef, 0.0001; on my laptop and it was long enough sometimes and not others. Ten microseconds was never enough and one millisecond was always enough... tonight, with nothing else running. My experience has been that the length of the sleep needed will vary by enormous factors depending on the details of the system load. I suppose that it if it was really necessary a file could be used as an "I am ready now" flag between the two processes.

Thanks again for the suggestions about too many backslashes (I changed from a here document to single quotes) and the trick of waiting for whitespace to check for a password that arrives in pieces - I had missed that one.

Sorry if I'm getting long winded. The big question: is getc a good way of doing this or is it nonportable?

The current version of the code (with getc) looks like this.

use warnings;
use strict;

my $password = "hide_me";
my $log_file = "test.log";
open STDOUT, "| perl | tee -a $log_file";
select STDOUT;
$| = 1;

print '
  use warnings;
  use strict;
  select STDOUT;
  $| = 1;
  my $chr;
  $_ = "";
  while ($chr = getc DATA) {
      $_ .= $chr;
      next unless $chr =~ /\s/;
      s/' . (quotemeta $password) . '/removed/ig;
      print;
      $_ = "";
  }
  print;
  __DATA__
';

print "The password is $password\n";
foreach (qw{Output is unbuffered if these words are printed one at a t
+ime.}) {
        print $_, " ";
        select undef, undef, undef, 0.3;
}
print "\n";
foreach (split //, "Even one character at a time: $password should be 
+filtered.\n") {
        print;
        select undef, undef, undef, 0.1;
}
close STDOUT;
[download]

The output looks like this. The second and third lines are both printed a word at a time.

The password is removed
Output is unbuffered if these words are printed one at a time.
Even one character at a time: removed should be filtered.
[download]