filters

[Leslie Mikesell]

In article <109685 at convex.convex.com> tchrist at 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 at chinet.chi.il.us