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

Previous Next

Package: coreutils;

Reported by: David Diggles <david.diggles <at> dnrm.qld.gov.au>

Date: Fri, 28 Sep 2012 07:15:02 UTC

Severity: normal

Tags: fixed

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: 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




This bug report was last modified 6 years and 310 days ago.

Previous Next


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