bug#30928: no error val returned by 'nice' failure?

[Pádraig Brady]

On 24/03/18 16:32, L A Walsh wrote:
> 
> 
> Paul Eggert wrote:
>> L A Walsh wrote:
>>> how do you tell if the resetting of the
>>> priority worked or failed?
>>
>> I guess you're supposed to look at stderr, which is what you did.
>>
>> This is the way 'nice' has behaved for quite some time, and it's what POSIX 
>> specifies. We'd need a real good reason to change it, given that changing it 
>> would no doubt break stuff.
> ---
> How about a flag, like -e for 'fail on failure to change priority' and
> (maybe less important or useful) '-w' to only return nice's return 
> value, with the posix error message returned for called app (if error).
> 
> So, 
>   nice -e --19 sleep 99
> would return immediately if not root with exit status for EPERM (and
> no text); sleep would not be executed.
>  
> and for -w case:
> 
>   nice -w --19 ls noexist
> would return status for EPERM, and message:
> ls: cannot access 'noexist': No such file or directory
> 
> Seems those would cover most possibly wants, though
> the first would be enough to determine if nice is going to work.
> 
> Not an earth-shattering change, but at least it would allow
> some way to check if nice is going to work or not so
> one could not use it where it would fail (and not
> generate an error message).

I wonder could we special case `nice true`
to indicate the nice return, so you could then:

  nice true && nice cmd || exit

That would be forwards compat,
and backwards compat in the sense it would degrade to the current situation.

It's probably a bit hacky though.

Pádraig