From: Karel Zak <kzak@redhat.com>
To: Stephane Chazelas <stephane.chazelas@gmail.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [bug] renice not POSIX compliant
Date: Fri, 8 Nov 2019 12:08:42 +0100 [thread overview]
Message-ID: <20191108110842.qe6vv5votmcud2f2@10.255.255.10> (raw)
In-Reply-To: <20190914135537.yps2umfx2nsynyii@chaz.gmail.com>
Hi,
(sorry for delay)
On Sat, Sep 14, 2019 at 02:55:37PM +0100, Stephane Chazelas wrote:
> util-linux added "-n" in 2009 for POSIX compliance (see
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=7cfbafda9c484a8cadefc47ee115086e803d9391),
> but the "-n" is just ignored. Since 2010, the --help message
> does say that -n/--priority takes an "increment"
> (https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=296351b0f112c821bffbe8ce7aa35d716251051d)
> but that's not what happens in practice (it still sets the
> niceness to the value specified).
I have fixed the --help and removed "increment".
> Also, a POSIX renice utility is meant to parse the options the
> usual (getopt(3)) way. In particular,
>
> renice -gn 1 -- 123
>
> Is meant to increase the niceness of pgid 123 by 1, but fails in
> util-linux renice.
>
> $ renice -gn 1 -- "$$"
> renice: invalid priorty '-gn'
> Try 'renice --help' for more information.
>
> -p, -g, -u are meant to specify how *all* operands are to be
> interpreted, they are not options that take arguments.
well, this is --help stupidity, man page is better. Fixed.
> renice +1 123
> renice +1 123 -u me
>
> are unspecified by POSIX, so it's fine for util-linux to handle
> the BSD way, but
>
> renice -n 1 -u me -p 123
>
> Is meant to increase the niceness of users "me", "-p" and "123".
>
> Also, calling it "--priority" is quite misleading as the
> niceness is rather the opposite of priority. GNU "nice" uses
> "--adjustment" as the long-option equivalent of "-n" (note that
> FreeBSD also calls it "priority" though)..
>
> IMO, the best way to handle it would be to do a BSD-style
> parsing when the first argument matches the [-+]?\d+ RE, and do
> a POSIX getopt_long parsing otherwise with:
hmm... but it will introduce regression as -n is interpreted as
absolute number now, no increment. And at first glance at Google you
can see that -n is in almost all how-to articles ;-(
I think we need to keep -n in the game for BSD-style too.
> Change the (POSIX style) options to:
>
> -n/--adjustment <num>: niceness increment
> -v/--value (deprecated: --priority) <num>: exact niceness value
> -g/--pgrp (no arg): interpret operands as gids.
> -u/--user (no arg): interpret operands as user names/ids
> -p/-pid (no arg): interpret operands as pids.
> --help/--version...
>
> And keep the
>
> renice niceness [[-p/--pid] pid ...] [[-g/--pgrp] pgid ...] [[-u/--user] user ...]
>
> usage for backward compatibility and BSD compatibility.
What about:
renice [-n] [+-]<prio> [[-p/--pid] pid ...] [[-g/--pgrp] pgid ...] [[-u/--user] user ...]
and keep <prio> is absolute number if without +/-; and as relative
if prefixed with + or - ?
It means people who use
renice -n 10 [-p ... -g ... -u ... ]
will not see any regression, and people who use
renice -n +2 [-p ... -g ... -u ... ]
will see that it work as expected :-)
For POSIX-like getopt_long() way, how does it support more arguments?
For example in BSD way you can use:
renice 10 -p 1 -p 2 -p 3
to apply 10 for processes 1, 2 and 3. How you can write it in POSIX way?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
prev parent reply other threads:[~2019-11-08 11:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 13:55 [bug] renice not POSIX compliant Stephane Chazelas
2019-11-08 11:08 ` Karel Zak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108110842.qe6vv5votmcud2f2@10.255.255.10 \
--to=kzak@redhat.com \
--cc=stephane.chazelas@gmail.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).