Re: env+nice, one bug fix, two test corrections

[Jim Meyering]

Eric Blake wrote:
> According to Jim Meyering on 10/26/2009 3:04 AM:
>>>From 501bf7b589e8c63c408c86fce5bb9902ae019017 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Sat, 24 Oct 2009 13:50:13 +0200
>> Subject: [PATCH 1/3] nice: execute program even when setpriority fails due 
>> to EACCES
>
> I'm wondering if this also qualifies as a nice bug:
>
> $ nice -n -1 2>/dev/full nice
> 0
> $ echo $?
> 0
>
> The call to error() flushes stderr (so even if fd 2 is pointing to a file
> and stderr is not line-buffered, the error message is still output), but
> we are failing to check ferror(stderr), when we proceed to blindly invoke
> the subsidiary program even though we had a write failure.  Should we
> change the code to fail with EXIT_CANCELED if we detect failure to print
> the advisory message?

Good catch.

At first glance, this looked like a close call, but upon
reflection, it is clear that it does deserve a non-zero exit.
If we fail to diagnose the initial problem via stderr,
we have an obligation to escalate.  Failure to change
priority, for whatever reason, must be diagnosed.