Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.programmer
Subject: Re: filters
Keywords: stdout filters flush error exit
Message-ID: <1990Dec04.043542.6304@chinet.chi.il.us>
Date: 4 Dec 90 04:35:42 GMT
References: <109685@convex.convex.com>
Organization: Chinet - Public Access UNIX
Lines: 32

In article <109685@convex.convex.com> tchrist@convex.com (Tom Christiansen) writes:

>There seem to be a lot of filters out there that don't check that their
>output succeeded and blindly exit with success irrespective of the
>success of their writes.

>Cat and col are two utilities I've just caught doing this.  Cat does
>make a stab at detecting this, but it does it wrong.  It just checks
>ferror(stdout), but it's never done an fflush() or an fclose() first.
>Plus it only says "output write error", not what the error is.

>My first question I have is what could possible break if cat were to do
>an fclose(stdout) at the end (and check the status and set the exit 
>accordingly).  

I can't imagine anything breaking, but the situtions that would be helped
are pretty rare.  The filters in question are normally used in a pipeline
and thus typically exit before the final program is finished.  

>(We know it really needs the fclose and not just fflush because of the
>recent EDQUOTA debate, right?)
>My second question is whether this is just a symptom of sloppy programming
>or whether there's some reason why filters (mis)behave this way.

Didn't most of these programs exist long before EDQUOTA?  The only likely
thing to catch would be a completely full disk, or in the case of pipes,
PIPEDEV being full.    There is seldom a good response to this and if
it happens in a shell script it's pretty likely you are already doing
something wrong.

Les Mikesell
  les@chinet.chi.il.us