nice(1) takes an absolute priority a

[Geoff Collyer]

Guy Harris wrote:

> > If you use nice(3c) you add another call and then do, inside it, the
> > getpriority call you could have done yourself.  And whoever reads your
> > code has to try to remember whether that old nice call was relative or
> > absolute.  If you just used getpriority and setpriority it would at
> > least be clear exactly what you were doing.

> No argument there.  I *think* all versions of "nice" after V6 add the
> value given as an argument to the current "nice", but the V7 manual's
> wording (the priority is "augmented" by the argument) is a bit vague
> (I checked the 2.9 code, assuming it was basically the same as V7, and
> it does work that way); the fact that it is that confusing indicates
> that "setpriority" is nicer (no pun intended).

The V7 nice(2) page does say ``augmented'', but declares the system call as

	nice(incr)

and refers to the argument as an ``increment'' in the next paragraph.
More importantly, nice(1) talks about its optional argument as an increment.
There's really no ambiguity here.  The nice system call (or function on 4.2)
does exactly what nice(1) wants.

Robert Elz wrote:

> The only thing that bothered me about the suggested fix, was that
> the test for an error was omitted.  That is not a good idea.

My suggested fix is the nice call from the V7 nice command,
which has the advantage that if you ask for an increment that you aren't
allowed, the niced command still runs, unlike the vanilla 4.2 nice command,
which prints a message and doesn't run the niced command.
-- 
8 > 4 + 5.