GNU bug report logs - #12530
nice(1) man page, bad wording

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12530 in the body.
You can then email your comments to 12530 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Diggles <david.diggles <at> dnrm.qld.gov.au>
To: bug-coreutils <at> gnu.org
Subject: nice(1) man page, bad wording
Date: Fri, 28 Sep 2012 12:44:39 +1000

DESCRIPTION
       Run  COMMAND  with an adjusted niceness, which affects process
scheduling.  With no COMMAND, print the current niceness.  Nicenesses
range from -20
       (most favorable scheduling) to 19 (least favorable).

Favorable to what?  It really does not explain, since it can be
interpreted in opposite ways.  Please use words like higher and lower
priority.

-- 
David Diggles
Computer Systems Officer, Spatial Information
Telephone 07 3170 5810
Level 4, Block B, Ecosciences Precinct    
Joe Baker St (41 Boggo Rd)
Dutton Park, 4102, Australia


------------------------------
The information in this email together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. There is no waiver of any confidentiality/privilege by your inadvertent receipt of this material. 
Any form of review, disclosure, modification, distribution and/or publication of this email message is prohibited, unless as a necessary part of Departmental business.
If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
------------------------------

Message #8 received at 12530 <at> debbugs.gnu.org (full text, mbox):

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: David Diggles <david.diggles <at> dnrm.qld.gov.au>, "12530 <at> debbugs.gnu.org"
	<12530 <at> debbugs.gnu.org>
Subject: RE: bug#12530: nice(1) man page, bad wording
Date: Fri, 28 Sep 2012 13:25:25 +0000

David Diggles wrote (Friday, September 28, 2012 4:45 AM)

> DESCRIPTION
>        Run  COMMAND  with an adjusted niceness, which affects process
> scheduling.  With no COMMAND, print the current niceness.  Nicenesses
> range from -20
>        (most favorable scheduling) to 19 (least favorable).
>
> Favorable to what?  It really does not explain, since it can be
> interpreted in opposite ways.  Please use words like higher and lower
> priority.

Hello to Brisbane!

Thanks for the report.

"Favorable" means the kernel will favor this process before
it will take "least favorable" processes into account for
scheduling.

I don't think the words "higher"/"lower" will bring clarity
to it, maybe it'd even be worse because a higher nice number
leads to lower priority.

What about a stronger term like "aggressive scheduling"?

Have a nice day,
Berny

Message #11 received at 12530 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: David Diggles <david.diggles <at> dnrm.qld.gov.au>,
	"12530-done <at> debbugs.gnu.org" <12530 <at> debbugs.gnu.org>
Subject: Re: bug#12530: nice(1) man page, bad wording
Date: Fri, 28 Sep 2012 15:25:31 +0100

On 09/28/2012 02:25 PM, Voelker, Bernhard wrote:
> David Diggles wrote (Friday, September 28, 2012 4:45 AM)
>
>> DESCRIPTION
>>         Run  COMMAND  with an adjusted niceness, which affects process
>> scheduling.  With no COMMAND, print the current niceness.  Nicenesses
>> range from -20
>>         (most favorable scheduling) to 19 (least favorable).
>>
>> Favorable to what?  It really does not explain, since it can be
>> interpreted in opposite ways.  Please use words like higher and lower
>> priority.
>
> Hello to Brisbane!
>
> Thanks for the report.
>
> "Favorable" means the kernel will favor this process before
> it will take "least favorable" processes into account for
> scheduling.
>
> I don't think the words "higher"/"lower" will bring clarity
> to it, maybe it'd even be worse because a higher nice number
> leads to lower priority.
>
> What about a stronger term like "aggressive scheduling"?

Well with relative terms, it's best to state what they're relative to,
so I'll apply something like this, as the wording is ambiguous.

thanks!
Pádraig.

diff --git a/src/nice.c b/src/nice.c
index 1a90320..12d0b0f 100644
--- a/src/nice.c
+++ b/src/nice.c
@@ -73,7 +73,7 @@ usage (int status)
       printf (_("\
 Run COMMAND with an adjusted niceness, which affects process scheduling.\n\
 With no COMMAND, print the current niceness.  Nicenesses range from\n\
-%d (most favorable scheduling) to %d (least favorable).\n\
+%d (least favorable to the system) to %d (least favorable to the process).\n\
 \n\
   -n, --adjustment=N   add integer N to the niceness (default 10)\n\
 "),

Message #14 received at 12530 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: David Diggles <david.diggles <at> dnrm.qld.gov.au>,
	"12530-done <at> debbugs.gnu.org" <12530 <at> debbugs.gnu.org>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: Re: bug#12530: nice(1) man page, bad wording
Date: Fri, 28 Sep 2012 18:46:29 +0200

Pádraig Brady wrote:

> On 09/28/2012 02:25 PM, Voelker, Bernhard wrote:
>> David Diggles wrote (Friday, September 28, 2012 4:45 AM)
>>
>>> DESCRIPTION
>>>         Run  COMMAND  with an adjusted niceness, which affects process
>>> scheduling.  With no COMMAND, print the current niceness.  Nicenesses
>>> range from -20
>>>         (most favorable scheduling) to 19 (least favorable).
>>>
>>> Favorable to what?  It really does not explain, since it can be
>>> interpreted in opposite ways.  Please use words like higher and lower
>>> priority.
>>
>> Hello to Brisbane!
>>
>> Thanks for the report.
>>
>> "Favorable" means the kernel will favor this process before
>> it will take "least favorable" processes into account for
>> scheduling.
>>
>> I don't think the words "higher"/"lower" will bring clarity
>> to it, maybe it'd even be worse because a higher nice number
>> leads to lower priority.
>>
>> What about a stronger term like "aggressive scheduling"?
>
> Well with relative terms, it's best to state what they're relative to,
> so I'll apply something like this, as the wording is ambiguous.
>
> thanks!
> Pádraig.
>
> diff --git a/src/nice.c b/src/nice.c
> index 1a90320..12d0b0f 100644
> --- a/src/nice.c
> +++ b/src/nice.c
> @@ -73,7 +73,7 @@ usage (int status)
>        printf (_("\
>  Run COMMAND with an adjusted niceness, which affects process scheduling.\n\
>  With no COMMAND, print the current niceness.  Nicenesses range from\n\
> -%d (most favorable scheduling) to %d (least favorable).\n\
> +%d (least favorable to the system) to %d (least favorable to the process).\n\
>  \n\
>    -n, --adjustment=N   add integer N to the niceness (default 10)\n\
>  "),

Thanks!
Here's an additional patch to avoid something I noticed in the context.
Using "niceness" is bad enough without cementing the ugliness by using a
plural form.

From 0d4efc37133820c5571316d0ebdf341270e712a4 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Fri, 28 Sep 2012 18:42:05 +0200
Subject: [PATCH] doc: correct an old bit of ugliness in nice --help output

* src/nice.c (usage): s/Nicenesses/Niceness values/
---
 src/nice.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nice.c b/src/nice.c
index 7402b9e..f13be63 100644
--- a/src/nice.c
+++ b/src/nice.c
@@ -72,7 +72,7 @@ usage (int status)
       printf (_("Usage: %s [OPTION] [COMMAND [ARG]...]\n"), program_name);
       printf (_("\
 Run COMMAND with an adjusted niceness, which affects process scheduling.\n\
-With no COMMAND, print the current niceness.  Nicenesses range from\n\
+With no COMMAND, print the current niceness.  Niceness values range from\n\
 %d (most favorable to the process) to %d (least favorable to the process).\n\
 \n\
   -n, --adjustment=N   add integer N to the niceness (default 10)\n\
--
1.7.12.1.382.gb0576a6

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#12530: nice(1) man page, bad wording
Date: Fri, 28 Sep 2012 23:04:02 +0200

Pádraig Brady wrote:
> On 09/28/2012 05:46 PM, Jim Meyering wrote:
>> Thanks!
>> Here's an additional patch to avoid something I noticed in the context.
>> Using "niceness" is bad enough without cementing the ugliness by using a
>> plural form.
>
> Heh I'd done that too, but then reverted because I thought
> the awkward phrasing might be there for a reason
> (to ensure people didn't think they could specify a range).
> But I was over thinking it, and your amendment is clearer.
>
> thanks,
> Pádraig.

Hmm... looks like you were right to think that.
I have just now looked for other occurrences of "nicenesses"
and found this explanation from NEWS in 2005:

    nice changes:

      Documentation and diagnostics now refer to "nicenesses" (commonly
      in the range -20...19) rather than "nice values" (commonly 0...39).

I expect to perform the same substitution on the sole use of "nicenesses"
in coreutils.texi.   Sorry I didn't think to check there before.

    $ g grep -i nicenesses doc
    doc/coreutils.texi:may have a wider range of nicenesses; conversely, other systems may

Message #20 received at 12530 <at> debbugs.gnu.org (full text, mbox):

From: David Diggles <david.diggles <at> dnrm.qld.gov.au>
To: Jim Meyering <jim <at> meyering.net>
Cc: "12530-done <at> debbugs.gnu.org" <12530 <at> debbugs.gnu.org>,
	Pádraig Brady <P <at> draigBrady.com>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: Re: bug#12530: nice(1) man page, bad wording
Date: Tue, 02 Oct 2012 09:19:13 +1000

I had not expected a response.

GNU rocks,

Cheers!

On Sat, 2012-09-29 at 02:46, Jim Meyering wrote:
> Pádraig Brady wrote:
> 
> > On 09/28/2012 02:25 PM, Voelker, Bernhard wrote:
> >> David Diggles wrote (Friday, September 28, 2012 4:45 AM)
> >>
> >>> DESCRIPTION
> >>>         Run  COMMAND  with an adjusted niceness, which affects process
> >>> scheduling.  With no COMMAND, print the current niceness.  Nicenesses
> >>> range from -20
> >>>         (most favorable scheduling) to 19 (least favorable).
> >>>
> >>> Favorable to what?  It really does not explain, since it can be
> >>> interpreted in opposite ways.  Please use words like higher and lower
> >>> priority.
> >>
> >> Hello to Brisbane!
> >>
> >> Thanks for the report.
> >>
> >> "Favorable" means the kernel will favor this process before
> >> it will take "least favorable" processes into account for
> >> scheduling.
> >>
> >> I don't think the words "higher"/"lower" will bring clarity
> >> to it, maybe it'd even be worse because a higher nice number
> >> leads to lower priority.
> >>
> >> What about a stronger term like "aggressive scheduling"?
> >
> > Well with relative terms, it's best to state what they're relative to,
> > so I'll apply something like this, as the wording is ambiguous.
> >
> > thanks!
> > Pádraig.
> >
> > diff --git a/src/nice.c b/src/nice.c
> > index 1a90320..12d0b0f 100644
> > --- a/src/nice.c
> > +++ b/src/nice.c
> > @@ -73,7 +73,7 @@ usage (int status)
> >        printf (_("\
> >  Run COMMAND with an adjusted niceness, which affects process scheduling.\n\
> >  With no COMMAND, print the current niceness.  Nicenesses range from\n\
> > -%d (most favorable scheduling) to %d (least favorable).\n\
> > +%d (least favorable to the system) to %d (least favorable to the process).\n\
> >  \n\
> >    -n, --adjustment=N   add integer N to the niceness (default 10)\n\
> >  "),
> 
> Thanks!
> Here's an additional patch to avoid something I noticed in the context.
> Using "niceness" is bad enough without cementing the ugliness by using a
> plural form.
> 
> From 0d4efc37133820c5571316d0ebdf341270e712a4 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyering <at> redhat.com>
> Date: Fri, 28 Sep 2012 18:42:05 +0200
> Subject: [PATCH] doc: correct an old bit of ugliness in nice --help output
> 
> * src/nice.c (usage): s/Nicenesses/Niceness values/
> ---
>  src/nice.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/nice.c b/src/nice.c
> index 7402b9e..f13be63 100644
> --- a/src/nice.c
> +++ b/src/nice.c
> @@ -72,7 +72,7 @@ usage (int status)
>        printf (_("Usage: %s [OPTION] [COMMAND [ARG]...]\n"), program_name);
>        printf (_("\
>  Run COMMAND with an adjusted niceness, which affects process scheduling.\n\
> -With no COMMAND, print the current niceness.  Nicenesses range from\n\
> +With no COMMAND, print the current niceness.  Niceness values range from\n\
>  %d (most favorable to the process) to %d (least favorable to the process).\n\
>  \n\
>    -n, --adjustment=N   add integer N to the niceness (default 10)\n\
> --
> 1.7.12.1.382.gb0576a6


------------------------------
The information in this email together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. There is no waiver of any confidentiality/privilege by your inadvertent receipt of this material. 
Any form of review, disclosure, modification, distribution and/or publication of this email message is prohibited, unless as a necessary part of Departmental business.
If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
------------------------------

Message #23 received at 12530 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 12530 <at> debbugs.gnu.org
Subject: Re: bug#12530: nice(1) man page, bad wording
Date: Thu, 11 Oct 2018 15:28:46 -0600

tags 12530 fixed
close 12530
stop


Pushed in
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=0d4efc37133820c5571316d0ebdf341270e712a4

Closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.