Re: Re[2]: [9fans] weird print(2) problems...

Re: Re[2]: [9fans] weird print(2) problems...

[David Gordon Hogan]

To paraphrase Cartman, ``These discussions of zero length
writes are soooo interesting''.

boyd writes:
> dennis will correct me.  it's early, i haven't even finished
> my first coke.

Do a couple of lines for me :-)

Re: Re[2]: [9fans] weird print(2) problems...

[Boyd Roberts]

> To paraphrase Cartman, ``These discussions of zero length
> writes are soooo interesting''.

i think he said:

    i'm a bigger unix guru than you

which was replied to with:

    no, you're a fatter unix guru than me

> Do a couple of lines for me :-)

i'm taking the 5th :-)

Re[2]: [9fans] weird print(2) problems...

[steve.simon]

Re: zero length messages on pipes

I understood that read would return 0 for a zero length message,
and -1 on a read of a hungup (broken) pipe.

Am I just rembembering UNIX stuff or just fooling myself?

-Steve

----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
----------------------------------------------------------------------

Re: Re[2]: [9fans] weird print(2) problems...

[Boyd Roberts]

> Re: zero length messages on pipes
>
> I understood that read would return 0 for a zero length message,
> and -1 on a read of a hungup (broken) pipe.

on unix a broken pipe is when the reader goes away.  the writer
then gets sigpiped/epipe on the next write.  the writer can exit
before the reader, with no ill effects.

err, if you were using a version of csh (all versions?) this could
bite you badly 'cos a pipeline was incorrectly constructed;  csh
would wait on the first process and not the _last_.  you have to
fork the pipeline in reverse to get the right semantics, but csh
did not do this.  sh did.

if your pipeline is:

    cmd | grep something > /dev/null

it's the exit status of the grep that you want, not the exit
status of cmd.

8th ed was modified to deal with dumb readers/writers by sigpipe,
then sigkill after some number of bogus i/o's -- this was to
trap programs that ignored error conditions.  i guess this was
initially added to limit the consumption of stream resources.

dennis will correct me.  it's early, i haven't even finished
my first coke.