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 ch
On 03/24/2018 10:09 PM, 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
Clint Adams wrote:
What's keeping it out of glibc?
Sorry, don't know offhand. Mostly lack of time, I expect.
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 ch
On Fri, Mar 23, 2018 at 12:02:36PM -0700, Paul Eggert wrote:
> That would reintroduce race-condition security holes in the ordinary build
> of GNU Coreutils on GNU/Linux, which would not be a good thing. Instead, how
> about fixing fakeroot so that it traps 'syscall' and fails with errno ==
> ENOTS
I executed a command:
nice --19 sleep 5
and hoped to get back a status as to whether or not I was
allowed to use a negative priority, since on Windows,
anyone in the Admin group can set a priority, with
the above command running sleep at 'High' priority, but
on linux:
nice --19 sleep 1
nice
On 03/20/2018 02:34 PM, Roland Hieber wrote:
> * .github/ISSUE_TEMPLATE.txt, .github/PULL_REQUEST_TEMPLATE.txt:
> fix typo "coreitils" in the URL to the bug tracker.
Thanks, pushed (with a little tweak in the commit message).
Have a nice day,
Berny
