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 <meyer...@redhat.com> >> 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.
