[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: bug#30928: no error val returned by 'nice' failure?
Date: Sat, 31 Mar 2018 16:00:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]