Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!think!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!ogicse!hakanson
From: hakanson@ogicse.ogc.edu (Marion Hakanson)
Newsgroups: comp.lang.perl
Subject: Re: Problems using ptys in perl.
Message-ID: <7166@ogicse.ogc.edu>
Date: 7 Feb 90 00:44:01 GMT
References: <2276@uvaarpa.virginia.edu> <7115@ogicse.ogc.edu> <6989@jpl-devvax.JPL.NASA.GOV>
Reply-To: hakanson@ogicse.UUCP (Marion Hakanson)
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 146

In article <6989@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>. . .
>Note the disclaimer in the manual entry on fork:
>
>     fork    Does a fork() call.  Returns the child pid to the
>             parent process and 0 to the child process.  Note:
>             unflushed buffers remain unflushed in both
>             processes, which means you may need to set $| to
>             avoid duplicate output.

This does look like the cause of the problem experienced by the
original poster.  In fact, I have reviewed my test scripts, and the
only one I have which exhibits the weird feedback behavior I described
is the "ptytst5.pl" script which I posted awhile back (you know, the
one for which I'm "eternally beloved").

The example may very well be a special case, since it is one of the
few ways I've seen for a Perl script to both read from and write to
the same filehandle.  I thought I understood some of what's going on,
until I tried out the following:

==========fhtty.pl========
#!/usr/bin/perl
# TTY filehandle test program -- 90/02/06
#   Marion Hakanson (hakanson@cse.ogi.edu)
#   Oregon Graduate Institute of Science and Technology

open(TTY, "+>/dev/tty") || die 'Cannot open /dev/tty, aborted';

select(TTY); $| = 1;
select(STDOUT); $| = 1;

for ($i=0; $i<3; $i++ ) {
  print TTY "TTY: TYPE Hello $i\n" || die "Cannot print to TTY, aborted";
  sleep(5);
  $ttyin = <TTY>;
  $ttyin =~ tr/A-Z/a-z/;
  $ttyin =~ s/\r//g;
  print STDOUT "STDOUT: $ttyin";
}
print TTY "$$: Done\n";
close(TTY);
==========================

The idea is that you type "Hello x" as prompted as soon as you see
the prompt, and wait for the next prompt before typing the next line.
Results:

===========DYNIX-3.0 (Sequent-4.2bsd) output========
ogicse 127% ( stty -echo; ./fhtty.pl; stty echo )
TTY: TYPE Hello 0
STDOUT: tty: type hello 0
TTY: TYPE Hello 0
TTY: TYPE Hello 1
STDOUT: tty: type hello 0
TTY: TYPE Hello 0
TTY: TYPE Hello 2
STDOUT: tty: type hello 0
TTY: TYPE Hello 0
17069: Done
ogicse 128% Hello: Command not found.
ogicse 129% Hello: Command not found.
ogicse 130% Hello: Command not found.
ogicse 131%
========================

Note that the script never gets around to reading what I typed, and in
fact never seems to get past reading back the first line it printed
out (straight 4.3bsd behaves the same).  It looks like some file
pointers are being clobbered (or not updated), while the chars you
type keep getting stuffed in the input buffer and not read.

===========SunOS-4.0.3 (Sun-3) output=========
ansel 78% ( stty -echo; ./fhtty.pl; stty echo )
TTY: TYPE Hello 0
STDOUT: hello 0
Hello 0
TTY: TYPE Hello 1
STDOUT: hello 1
Hello 1
TTY: TYPE Hello 2
STDOUT: hello 2
Hello 2
10124: Done
ansel 79%
==============================

And here, although it looks a lot cleaner and more regular than the
4.xbsd case, I can't come up with a good explanation as to where
the "Hello x" all-by-itself lines come from.  But it is completely
consistent with the ptytst5.pl behavior.

Aren't these interactions between tty drivers and stdio wonderful?

Anyway, note that the following works as expected (by me) in both
of my test OS's.

==============fhfork3.pl=============
#!/usr/bin/perl
# Forked filehandle test program -- 90/02/06
#   Marion Hakanson (hakanson@cse.ogi.edu)
#   Oregon Graduate Institute of Science and Technology

open(TTY, "+>/dev/tty") || die 'Cannot open /dev/tty, aborted';

if ( fork ) {			# parent
  select(TTY); $| = 1;
  select(STDOUT); $| = 1;

  for ($i=0; $i<3; $i++ ) {
    print TTY "$$: TYPE Hello $i\n" || die "Cannot print to TTY, aborted";
    sleep(5);
  }
  print TTY "$$: Done\n";
  close(TTY);
} else {		# child
  select(TTY); $| = 1;
  select(STDOUT); $| = 1;

  while ($ttyin = <TTY>) {
    $ttyin =~ tr/A-Z/a-z/;
    $ttyin =~ s/\r//g;
    print STDOUT "$$: $ttyin";
  }
  close(TTY);
}
==================================

=========fhfork3.pl output============
ogicse 138% ( stty -echo; ./fhfork3.pl; stty echo )
18840: TYPE Hello 0
18843: hello 0
18840: TYPE Hello 1
18843: hello 1
18840: TYPE Hello 2
18843: hello 2
18840: Done
ogicse 139%
==================================

So I guess I'm back to suspecting the SunOS-4.0.3 pty driver.  Even
if I had sources to SunOS, I doubt I'd want to track this one down....

-- 
Marion Hakanson         Domain: hakanson@cse.ogi.edu
                        UUCP  : {hp-pcd,tektronix}!ogicse!hakanson