Disable op/pipe.t test under Machten
authorDominic Dunlop <domo@slipper.ip.lu>
Thu, 1 May 1997 10:48:26 +0000 (12:48 +0200)
committerChip Salzenberg <chip@atlantic.net>
Wed, 30 Apr 1997 12:00:00 +0000 (00:00 +1200)
At 09:47 +0200 1997-05-01, I wrote:
>Everything else is as expected, but I'm looking into this:
>
>dialup02 domo$ ./TEST io/pipe.t
>io/pipe...........print failed: Broken pipe at ./io/pipe.t line 86.
>FAILED on test 9

Here's a patch.  It seems MachTen doesn't behave like native UNIX here, so
punt.

Given that VMS doesn't behave like native UNIX either (and there's been
nothing on the list yet about NT and other "aliens"), test 9 looks like a
good emulation exposer.  Is this what we want?  As far as I can make out
from a little mucking about and a reading of ISO 9945-1:1990, MachTen is
behaving in a way that POSIX allows: stdio elects not to buffer writes on
pipes (a defensible decision); a write on a broken pipe fails with EPIPE
and raises SIGPIPE (correct by POSIX); close of a broken pipe succeeds
(correct by POSIX,and OK by perl: nothing's buffered, because the write
failed) if the pipe reader exited with zero status.  Slightly
disconcertingly, I discover that, if I substitute the command 'false' for
'true' as the putative pipe reader, the (perl) close fails.  close() is not
documented as failing if a pipe reader has terminated with a non-zero exit
code.  Is this a documentation shortcoming, a general perl bug, or a
MachTen perl bug?  Whether close() suceeds or fails, $? is set
appropriately.

Whatever, so as to get 5.004 out of the door, either apply this patch or do
away with test 9 entirely, pending deeper reflection.

p5p-msgid: v03102801af8e160d3879@[194.51.248.68]

t/io/pipe.t

index 21f02a7..ac14981 100755 (executable)
@@ -74,9 +74,10 @@ if ($^O eq 'VMS') {
     exit;
 }
 
-if ($Config{d_sfio}) {
+if ($Config{d_sfio} || $^O eq machten) {
     # Sfio doesn't report failure when closing a broken pipe
-    # that has pending output.  Go figure.
+    # that has pending output.  Go figure.  MachTen doesn't either,
+    # but won't write to broken pipes, so nothing's pending at close.
     print "ok 9\n";
 }
 else {