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
