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)
commitfc2615281e1f6be0fb2f6c1497f85eea8b36442b
tree80d0a1b07057a33c9a3b836af110a9a40bfac9c2
parent05475680fbb0187887aec733f8c78c90733ace24
Disable op/pipe.t test under Machten

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