* [PATCH 2/4 V2] chrt: do not try to interpret the --pid option itself as a PID
From: Benno Schulenberg @ 2025-07-03 14:47 UTC (permalink / raw)
To: util-linux
In-Reply-To: <20250703144752.29971-1-bensberg@telfort.nl>
When not specifying a PID with --pid, `chrt` would report:
chrt: invalid PID argument: '--pid'
That was silly. After this change, `chrt --pid` will report:
chrt: too few arguments
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
schedutils/chrt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/schedutils/chrt.c b/schedutils/chrt.c
index 415a9aa77..a72c0de26 100644
--- a/schedutils/chrt.c
+++ b/schedutils/chrt.c
@@ -474,6 +474,8 @@ int main(int argc, char **argv)
policy_given = true;
break;
case 'p':
+ if (argc - optind == 0)
+ errx(EXIT_FAILURE, _("too few arguments"));
errno = 0;
/* strtopid_or_err() is not suitable here; 0 can be passed.*/
ctl->pid = strtos32_or_err(argv[argc - 1], _("invalid PID argument"));
--
2.48.1
^ permalink raw reply related
* [PATCH 1/4 V2] chrt: with more than one argument, interpret first argument as priority
From: Benno Schulenberg @ 2025-07-03 14:47 UTC (permalink / raw)
To: util-linux; +Cc: Madadi Vineeth Reddy
The first argument is a priority not only for `chrt --pid <prio> <pid>`
but also for `chrt <prio> <command> [<argument>...]`.
This fixes an oversight in recent commit e7a2d62434.
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
---
schedutils/chrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/schedutils/chrt.c b/schedutils/chrt.c
index 550cefe4d..415a9aa77 100644
--- a/schedutils/chrt.c
+++ b/schedutils/chrt.c
@@ -530,7 +530,7 @@ int main(int argc, char **argv)
errno = 0;
- if (need_prio || argc - optind == 2)
+ if (need_prio || argc - optind > 1)
ctl->priority = strtos32_or_err(argv[optind], _("invalid priority argument"));
else
ctl->priority = 0;
--
2.48.1
^ permalink raw reply related
* Re: [PATCH v3] taskset: Accept 0 pid for current process
From: Karel Zak @ 2025-07-03 7:34 UTC (permalink / raw)
To: Jesse Rosenstock; +Cc: util-linux
In-Reply-To: <CAMZQ0r+-JSaC7UFvAvG10cvqSKiQY--7VYtpsEALidF44wmjbg@mail.gmail.com>
On Wed, Jul 02, 2025 at 10:08:23PM +0200, Jesse Rosenstock wrote:
> https://github.com/util-linux/util-linux/pull/3637
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* btrfs device detection bug util-linux 2.39.4 to 2.41
From: Mio @ 2025-07-03 3:05 UTC (permalink / raw)
To: util-linux
Hello util-linux mailing list
I found a bug affecting device detection of my btrfs filesystem with 3
devices. My test system is currently running NixOS 25.05 with util-linux
2.41. I am able to run a older version of util-linux with the command
`nix shell github:NixOS/nixpkgs/nixos-24.11#util-linux` which doesn't
have the bug.
The filesystem is called HDDPool-data
The output where only one device is detected
$ blkid
/dev/sdf: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="fa8bf8cb-a856-4ab3-9bbd-7e91aa2f5c7d" BLOCK_SIZE="4096"
TYPE="btrfs"
/dev/sdd: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="13536110-8eaf-4d0c-bef5-6dac628c9e4f" BLOCK_SIZE="4096"
TYPE="btrfs"
/dev/sdb4: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="6e5fac53-ae6a-465b-9f7b-cc36f584e3d3" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="c2ae79a1-1e90-42a9-896b-007df274a07e"
/dev/sdb2: LABEL="RootFS" UUID="b66ce927-d4e1-4237-982a-e924c0cfde15"
UUID_SUB="a80d43a7-cd54-4579-8720-d4c8e1563891" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="fe7a32da-c3b1-4b97-80c3-3cb63b5fd8dd"
/dev/sdb9: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="231ab628-74ce-4e0b-a3a5-f467dfd9e11d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="b9709f1a-0676-4da2-81b5-7e10aaa599e8"
/dev/sdb7: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="c2339d28-19ed-4515-b230-44d697269deb" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="f137692a-bae0-4d9b-9ac6-e0e5e5394df2"
/dev/sdb5: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="c1aff881-f902-4d68-b8f5-13751fad06b4" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="3bcde9d0-728f-4989-a230-b4f26554f203"
/dev/sdb3: UUID="f2e0b6c8-d683-4a51-b2bc-7af13b7d100a" TYPE="swap"
PARTUUID="1691a4f1-67ac-40e8-944c-55b103eafc5b"
/dev/sdb1: UUID="1EF4-5E59" BLOCK_SIZE="512" TYPE="vfat"
PARTUUID="2ebac8c4-2714-4f2b-bb09-e2981e77ce5e"
/dev/sdb8: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="a3e7378e-ecee-45af-a980-c8b17d332f01" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="6d991377-7202-4689-9564-6ea09cbe9445"
/dev/sdb6: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="b8646ac0-1010-4a20-83cb-d0e3c6e9e92d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="fe349a2d-4e8a-4f7e-9f15-90d6a02c9404"
/dev/sdg1: LABEL="HDDPool-data"
UUID="cae95f27-f8c3-48c5-96d6-e263458efda2"
UUID_SUB="2e280995-52c7-4e41-b0aa-11a22dd0187d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="65a68c39-46e9-e94a-9603-878003ef85c9"
/dev/sde: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="de2d0690-2b18-48ab-8262-66a767c389e5" BLOCK_SIZE="4096"
TYPE="btrfs"
The output on util-linux 2.39.4 where all 3 devices are detected
$ sudo blkid
/dev/sdf: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="fa8bf8cb-a856-4ab3-9bbd-7e91aa2f5c7d" BLOCK_SIZE="4096"
TYPE="btrfs"
/dev/sdd: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="13536110-8eaf-4d0c-bef5-6dac628c9e4f" BLOCK_SIZE="4096"
TYPE="btrfs"
/dev/sdb4: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="6e5fac53-ae6a-465b-9f7b-cc36f584e3d3" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="c2ae79a1-1e90-42a9-896b-007df274a07e"
/dev/sdb2: LABEL="RootFS" UUID="b66ce927-d4e1-4237-982a-e924c0cfde15"
UUID_SUB="a80d43a7-cd54-4579-8720-d4c8e1563891" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="fe7a32da-c3b1-4b97-80c3-3cb63b5fd8dd"
/dev/sdb9: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="231ab628-74ce-4e0b-a3a5-f467dfd9e11d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="b9709f1a-0676-4da2-81b5-7e10aaa599e8"
/dev/sdb7: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="c2339d28-19ed-4515-b230-44d697269deb" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="f137692a-bae0-4d9b-9ac6-e0e5e5394df2"
/dev/sdb5: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="c1aff881-f902-4d68-b8f5-13751fad06b4" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="3bcde9d0-728f-4989-a230-b4f26554f203"
/dev/sdb3: UUID="f2e0b6c8-d683-4a51-b2bc-7af13b7d100a" TYPE="swap"
PARTUUID="1691a4f1-67ac-40e8-944c-55b103eafc5b"
/dev/sdb1: UUID="1EF4-5E59" BLOCK_SIZE="512" TYPE="vfat"
PARTUUID="2ebac8c4-2714-4f2b-bb09-e2981e77ce5e"
/dev/sdb8: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="a3e7378e-ecee-45af-a980-c8b17d332f01" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="6d991377-7202-4689-9564-6ea09cbe9445"
/dev/sdb6: LABEL="ssdpool" UUID="119c2a64-e46c-4e63-87f9-3aa3161bec03"
UUID_SUB="b8646ac0-1010-4a20-83cb-d0e3c6e9e92d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="fe349a2d-4e8a-4f7e-9f15-90d6a02c9404"
/dev/sdg1: LABEL="HDDPool-data"
UUID="cae95f27-f8c3-48c5-96d6-e263458efda2"
UUID_SUB="2e280995-52c7-4e41-b0aa-11a22dd0187d" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="65a68c39-46e9-e94a-9603-878003ef85c9"
/dev/sde: LABEL="Rescue3" UUID="623630d3-64d8-4917-ade8-412101d23b40"
UUID_SUB="de2d0690-2b18-48ab-8262-66a767c389e5" BLOCK_SIZE="4096"
TYPE="btrfs"
/dev/sdc2: PARTUUID="42c6b5c0-3869-4c8f-8112-b277660321cd"
/dev/sdc3: LABEL="HDDPool-data"
UUID="cae95f27-f8c3-48c5-96d6-e263458efda2"
UUID_SUB="6481359c-d118-4a87-8d92-32d9c205362b" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="47439aab-c752-c348-bc53-47c69dcdd3b6"
/dev/sdc1: PARTUUID="5048125b-8e2d-4558-b528-17a8f6e5cd0e"
/dev/sda2: PARTUUID="3363e8af-efc0-44c7-9062-287e8fd54eb1"
/dev/sda3: LABEL="HDDPool-data"
UUID="cae95f27-f8c3-48c5-96d6-e263458efda2"
UUID_SUB="c33bc5b0-2e12-459a-ac95-8638e02bce67" BLOCK_SIZE="4096"
TYPE="btrfs" PARTUUID="d3e471d0-41e4-8641-8ea0-97b469f16698"
/dev/sda1: PARTUUID="96c699ea-4e75-4ae4-8f42-bd656438bcd1"
I previously reported this problem on
https://lore.kernel.org/linux-btrfs/TY4PR01MB13853B64BF6DB7BEA98170AE99240A@TY4PR01MB13853.jpnprd01.prod.outlook.com/T/#u
https://bbs.archlinux.org/viewtopic.php?id=306625 and
https://github.com/NixOS/nixpkgs/issues/408631
Mio
^ permalink raw reply
* [PATCH v3] taskset: Accept 0 pid for current process
From: Jesse Rosenstock @ 2025-07-02 20:08 UTC (permalink / raw)
To: util-linux
In-Reply-To: <lscxfxbzi6j667md5buwprb5muuzpmsdpvvpmbdk7jvsq2rtxo@ucpthvyj2efw>
Diffs from v2:
* Use strtos32_or_err to parse pid
https://github.com/util-linux/util-linux/pull/3637
This is useful to print the current mask without using `$$`: `taskset -p 0`.
It is also helpful to test taskset: `taskset -c 1-4 taskset -p 0`.
This is not easy with `$$`.
sched_setaffinity(2)/sched_getaffinity(2) accept 0 for the calling
thread, so this seems consistent.
As an implementation detail, we replace 0 with getpid(), so the existing
pid != 0 <==> "will exec" logic continues to work unchanged.
A reasonable alternative would be to interpret just `taskset` (currently
an error) as printing the current mask. This seems less orthogonal,
and a better use may be found for plain `taskset` in the future.
Signed-off-by: Jesse Rosenstock <jmr@google.com>
---
schedutils/taskset.1.adoc | 8 ++++++++
schedutils/taskset.c | 13 ++++++++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/schedutils/taskset.1.adoc b/schedutils/taskset.1.adoc
index 9384347372..45622613bd 100644
--- a/schedutils/taskset.1.adoc
+++ b/schedutils/taskset.1.adoc
@@ -77,6 +77,7 @@
*-p*, *--pid*::
Operate on an existing PID and do not launch a new task.
+If PID is zero, then operate on the *taskset* process.
include::man-common/help-version.adoc[]
@@ -134,6 +135,13 @@
$ echo $? +
1 +
+== EXAMPLES
+
+Print the current CPU affinity as a list.
+
+$ taskset -pc 0 +
+pid 1355988's current affinity list: 0-47 +
+
== AUTHORS
Written by Robert M. Love.
diff --git a/schedutils/taskset.c b/schedutils/taskset.c
index b52cd4338b..7e2ecc3365 100644
--- a/schedutils/taskset.c
+++ b/schedutils/taskset.c
@@ -186,7 +186,18 @@
all_tasks = 1;
break;
case 'p':
- pid = strtopid_or_err(argv[argc - 1],
_("invalid PID argument"));
+ /*
+ * strtopid_or_err() is not suitable here; 0 can be
+ * passed.
+ */
+ pid = strtos32_or_err(argv[argc - 1],
+ _("invalid PID argument"));
+ if (pid == 0)
+ pid = getpid();
+ /*
+ * After this point, pid == 0 means "no pid" and that
+ * we will exec a command.
+ */
break;
case 'c':
ts.use_list = 1;
^ permalink raw reply related
* Re: [PATCH 3/4] chrt: simplify the other check for too few arguments
From: Karel Zak @ 2025-07-02 14:52 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: Madadi Vineeth Reddy, util-linux
In-Reply-To: <bc67a8ab-2a8b-4339-88e7-02fe71779491@telfort.nl>
On Wed, Jul 02, 2025 at 03:39:53PM +0200, Benno Schulenberg wrote:
> As far as I can tell, all the util-linux tools understand --help.
> So, for util-linux tools, it is rather redundant to tell the user
> this.
I mean when users use it on the command line and mix tools from different
projects and sources.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 3/4] chrt: simplify the other check for too few arguments
From: Benno Schulenberg @ 2025-07-02 13:39 UTC (permalink / raw)
To: Karel Zak; +Cc: Madadi Vineeth Reddy, util-linux
In-Reply-To: <4xnz2hducqdq7o2nvysrm5pvll7k52sprsycok6ouf5epqua6d@5yicext46xu5>
[-- Attachment #1.1: Type: text/plain, Size: 1297 bytes --]
Op 02-07-2025 om 11:01 schreef Karel Zak:
> On Tue, Jul 01, 2025 at 03:39:57PM +0200, Benno Schulenberg wrote:
>> The reason I don't want to see "Try 'chrt --help' for more information."
>> when I make a mistake is that it means that I have to read two lines:
>
> We should be consistent. The `errtryhelp()` function is usually used as the
> default error for an unknown option or when the user is "lost" on the command
> line, for example, if not all required arguments are used.
>
> warnx(_("too few arguments"));
> errtryhelp(EXIT_FAILURE);
>
> (or "bad usage") is consistent with the rest of util-linux.
After grepping for -B1 errtryhelp, I now see that this is the style
in the util-linux tools. I'm sorry to realize that. :/
>> the
>> second line doesn't add any information -- it just states the obvious.
>
> It does not have to be obvious to all users, -? -h, -H, --help, sometimes
> nothing, etc.
As far as I can tell, all the util-linux tools understand --help.
So, for util-linux tools, it is rather redundant to tell the user
this.
(There are just three tools that don't understand the short form
-h for help: agettty, col, and setttetm. fsck does not officially
support -h, but prints a help text anyway, from e2fsprogs.)
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH] man: Replace RETURN VALUE with EXIT STATUS in section 1
From: Karel Zak @ 2025-07-02 9:13 UTC (permalink / raw)
To: Jesse Rosenstock; +Cc: util-linux
In-Reply-To: <CAMZQ0rKb4J1LqtQ_vYbCi7sBvD9pp-jQpcmwzeY2y=vFDCLgPw@mail.gmail.com>
On Mon, Jun 30, 2025 at 08:59:55PM +0200, Jesse Rosenstock wrote:
> schedutils/coresched.1.adoc | 2 +-
> schedutils/taskset.1.adoc | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied (from github), thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 3/4] chrt: simplify the other check for too few arguments
From: Karel Zak @ 2025-07-02 9:01 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: Madadi Vineeth Reddy, util-linux
In-Reply-To: <a80cdbf2-0c4d-40dc-8ae6-9ccbd900bc1b@telfort.nl>
On Tue, Jul 01, 2025 at 03:39:57PM +0200, Benno Schulenberg wrote:
>
> Op 01-07-2025 om 07:16 schreef Madadi Vineeth Reddy:
> > Nit: I think we could still have "Try 'chrt --help' for more information."
> > along with your "too few arguments" so that user knows exactly how
> > many arguments are needed.
>
> The reason I don't want to see "Try 'chrt --help' for more information."
> when I make a mistake is that it means that I have to read two lines:
We should be consistent. The `errtryhelp()` function is usually used as the
default error for an unknown option or when the user is "lost" on the command
line, for example, if not all required arguments are used.
warnx(_("too few arguments"));
errtryhelp(EXIT_FAILURE);
(or "bad usage") is consistent with the rest of util-linux.
I can imagine a new function `errclimess(EXIT_FAILURE)` (or a better
name ;-) for exactly this case to avoid creativity in code. We can
use it everywhere and keep the error message on one line
"unexpected number of arguments, try chrt --help"
or so. Would this be a good compromise?
> the error message plus the "Try...". It takes me more time, _and_ the
> second line doesn't add any information -- it just states the obvious.
It does not have to be obvious to all users, -? -h, -H, --help, sometimes
nothing, etc.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 2/4] chrt: do not try to interpret the --pid option itself as a PID
From: Karel Zak @ 2025-07-02 8:30 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: Madadi Vineeth Reddy, util-linux
In-Reply-To: <3f71b403-9c43-4d99-9d15-6d6708832a00@telfort.nl>
On Tue, Jul 01, 2025 at 03:34:40PM +0200, Benno Schulenberg wrote:
> I don't think that is a good idea: the current interface is already
> confusing in that _gets_ info when a single argument follows --pid,
> and that it _sets_ something when there a two arguments. Allowing
> to set something for multiple PIDs at once while it's not possible
> to query multiple PIDs at once... is more confusing.
I agree, the schedutils UI is quite confusing. From time to time, I think
about a new tool that will combine all the tools into one (setsched,
lssched?) with a user-friendly interface.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH v2] rename: change "expression" to "substring"
From: Karel Zak @ 2025-07-02 8:03 UTC (permalink / raw)
To: Haelwenn (lanodan) Monnier; +Cc: util-linux
In-Reply-To: <20250701160139.24110-1-contact@hacktivis.me>
On Tue, Jul 01, 2025 at 06:01:05PM +0200, Haelwenn (lanodan) Monnier wrote:
> misc-utils/rename.1.adoc | 12 ++++++------
> misc-utils/rename.c | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH v2] taskset: Accept 0 pid for current process
From: Karel Zak @ 2025-07-02 7:37 UTC (permalink / raw)
To: Jesse Rosenstock; +Cc: util-linux
In-Reply-To: <CAMZQ0rLM9UYMupEX4WLmi-J9mh0jGhruzDw3OwpU8yEf0+2E_Q@mail.gmail.com>
On Tue, Jul 01, 2025 at 08:35:11AM +0200, Jesse Rosenstock wrote:
> A reasonable alternative would be to interpret just `taskset` (currently
> an error) as printing the current mask. This seems less orthogonal,
> and a better use may be found for plain `taskset` in the future.
Unfortunately, all schedutils have an odd command-line semantic.
> case 'p':
> - pid = strtopid_or_err(argv[argc - 1],
> _("invalid PID argument"));
> + /*
> + * Like strtopid_or_err() but accept 0 for this process,
> + * like sched_getaffinity()/sched_setaffinity() do.
> + */
> + pid = (pid_t) str2num_or_err(
> + argv[argc - 1], 10, _("invalid PID argument"),
> + 0, SINT_MAX(pid_t));
chrt uses:
/* strtopid_or_err() is not suitable here; 0 can be passed.*/
ctl->pid = strtos32_or_err(argv[argc - 1], _("invalid PID argument"));
would be this enough?
> + if (pid == 0)
> + pid = getpid();
Yes, this is probably better than make many other changes to the code.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH v2] rename: change "expression" to "substring"
From: Haelwenn (lanodan) Monnier @ 2025-07-01 16:01 UTC (permalink / raw)
To: util-linux; +Cc: Haelwenn (lanodan) Monnier
In-Reply-To: <20250621232642.17613-2-contact@hacktivis.me>
As rename(1) doesn't uses an expression (like regex or glob) but rather a substring.
---
misc-utils/rename.1.adoc | 12 ++++++------
misc-utils/rename.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/misc-utils/rename.1.adoc b/misc-utils/rename.1.adoc
index b8ea2bfdf..fc7df4f1c 100644
--- a/misc-utils/rename.1.adoc
+++ b/misc-utils/rename.1.adoc
@@ -20,11 +20,11 @@ rename - rename files
== SYNOPSIS
-*rename* [options] _expression replacement file_...
+*rename* [options] _substring replacement file_...
== DESCRIPTION
-*rename* will rename the specified files by replacing the first occurrence of _expression_ in their name by _replacement_.
+*rename* will rename the specified files by replacing the first occurrence of _substring_ in their name by _replacement_.
== OPTIONS
@@ -38,10 +38,10 @@ Show which files were renamed, if any.
Do not make any changes; add *--verbose* to see what would be made.
*-a*, *--all*::
-Replace all occurrences of _expression_ rather than only the first one.
+Replace all occurrences of _substring_ rather than only the first one.
*-l*, *--last*::
-Replace the last occurrence of _expression_ rather than the first one.
+Replace the last occurrence of _substring_ rather than the first one.
*-o*, *--no-overwrite*::
Do not overwrite existing files. When *--symlink* is active, do not overwrite symlinks pointing to existing targets.
@@ -57,9 +57,9 @@ The renaming has no safeguards by default or without any one of the options *--n
== EDGE CASES
-If the _expression_ is empty, then by default _replacement_ will be added to the start of the filename. With *--all*, _replacement_ will be inserted in between every two characters of the filename, as well as at the start and end.
+If _substring_ is empty, then by default _replacement_ will be added to the start of the filename. With *--all*, _replacement_ will be inserted in between every two characters of the filename, as well as at the start and end.
-Normally, only the final path component of a filename is updated. (Or with *--symlink*, only the final path component of the link.) But if either _expression_ or _replacement_ contains a _/_, the full path is updated. This can cause a file to be moved between folders. Creating folders, and moving files between filesystems, is not supported.
+Normally, only the final path component of a filename is updated. (Or with *--symlink*, only the final path component of the link.) But if either _substring_ or _replacement_ contains a _/_, the full path is updated. This can cause a file to be moved between folders. Creating folders, and moving files between filesystems, is not supported.
== INTERACTIVE MODE
diff --git a/misc-utils/rename.c b/misc-utils/rename.c
index bb2e3103d..d7bf4c5d7 100644
--- a/misc-utils/rename.c
+++ b/misc-utils/rename.c
@@ -251,7 +251,7 @@ static void __attribute__((__noreturn__)) usage(void)
FILE *out = stdout;
fputs(USAGE_HEADER, out);
fprintf(out,
- _(" %s [options] <expression> <replacement> <file>...\n"),
+ _(" %s [options] <substring> <replacement> <file>...\n"),
program_invocation_short_name);
fputs(USAGE_SEPARATOR, out);
base-commit: c8e5b8a818323af30ec656f079c7feadaeeb13c3
--
2.49.0
^ permalink raw reply related
* Re: [PATCH] rename: change "expression" to "original"
From: Haelwenn (lanodan) Monnier @ 2025-07-01 16:03 UTC (permalink / raw)
To: Karel Zak; +Cc: Benno Schulenberg, util-linux
In-Reply-To: <fkvvnjmv7r4uchsmr3qjr23omaw4iixuphblmko3uiczdwimzb@q4gxzqfmx4ix>
[2025-06-30 14:08:01+0200] Karel Zak:
>On Sun, Jun 22, 2025 at 05:51:39PM +0200, Benno Schulenberg wrote:
>>
>> Op 22-06-2025 om 01:26 schreef Haelwenn (lanodan) Monnier:
>> > == SYNOPSIS
>> > -*rename* [options] _expression replacement file_...
>> > +*rename* [options] _original replacement file_...
>
>Yes, the current situation ("expression") is unreadable.
>
>> > == DESCRIPTION
>> > -*rename* will rename the specified files by replacing the first occurrence of _expression_ in their name by _replacement_.
>> > +*rename* will rename the specified files by replacing the first occurrence of the _original_ substring in their name by _replacement_.
>>
>> Instead of using the word "original" (where I would first think: original
>> what?), why not use "substring"? It describes what the thing actually is,
>> and fits better in the rest of the existing wording.
>
>It seems that in documentation for replace-like functions, it's common
>to use "substring", sometimes the function itself uses "substring" in its name
>(e.g., awk gsub()).
>
>Haelwenn, do you want to update the patch?
>
> Karel
Yeah, sent a V2, wanted to wait a bit in case there were additional feedback
Best regards
^ permalink raw reply
* Re: [PATCH 1/2] script: (man,usage) correct the markup of the synopsis
From: Karel Zak @ 2025-07-01 15:55 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux, WanBingjiang
In-Reply-To: <20250627120408.11036-1-bensberg@telfort.nl>
On Fri, Jun 27, 2025 at 02:04:07PM +0200, Benno Schulenberg wrote:
> term-utils/script.1.adoc | 5 +++--
> term-utils/script.c | 8 ++++----
> 2 files changed, 7 insertions(+), 6 deletions(-)
Applied (both patches), thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/2] chrt: (man) correct the short form of --ext, from -d to -e
From: Karel Zak @ 2025-07-01 15:55 UTC (permalink / raw)
To: Benno Schulenberg; +Cc: util-linux
In-Reply-To: <20250625080948.6064-1-bensberg@telfort.nl>
On Wed, Jun 25, 2025 at 10:09:47AM +0200, Benno Schulenberg wrote:
> schedutils/chrt.1.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied (both patches), thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH 4/4] chrt: do not try to interpret any other option as a PID either
From: Benno Schulenberg @ 2025-07-01 13:52 UTC (permalink / raw)
To: Madadi Vineeth Reddy, util-linux
In-Reply-To: <500d8587-136f-46a9-b34e-ca4456f754a0@linux.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 956 bytes --]
Op 01-07-2025 om 07:21 schreef Madadi Vineeth Reddy:
> On 30/06/25 14:10, Benno Schulenberg wrote:
>> When doing, for example, `chrt --pid --max`, it would report:
>>
>> chrt: invalid PID argument: '--max'
>>
>
> But --max is part of options right?
>
> According to help text,
> chrt [options] --pid <priority> <pid>
>
> It should come before --pid right?
Sure. But the synopses of a command often don't (or even cannot)
fully express all possible arrangements of options and arguments.
So the user ought to be forgiven (when possible) for trying some
unspecified order.
(When I forget the exact invocation of a tool, I normally tack a
--help onto the previous attempt, and this usually prints the help
text, ignoring any other options. It would be nice if that worked
here too.)
Also, the '--max' is obviously an option, why try to interpret it
as a PID? Why make the tool obtuser than it needs to be?
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] chrt: simplify the other check for too few arguments
From: Benno Schulenberg @ 2025-07-01 13:39 UTC (permalink / raw)
To: Madadi Vineeth Reddy, util-linux
In-Reply-To: <4e545c8f-8e74-462f-8416-3c1cbde81b2e@linux.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 608 bytes --]
Op 01-07-2025 om 07:16 schreef Madadi Vineeth Reddy:
> Nit: I think we could still have "Try 'chrt --help' for more information."
> along with your "too few arguments" so that user knows exactly how
> many arguments are needed.
The reason I don't want to see "Try 'chrt --help' for more information."
when I make a mistake is that it means that I have to read two lines:
the error message plus the "Try...". It takes me more time, _and_ the
second line doesn't add any information -- it just states the obvious.
It reminds me of Clippy: so eager to help that it becomes obnoxious.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] chrt: do not try to interpret the --pid option itself as a PID
From: Benno Schulenberg @ 2025-07-01 13:34 UTC (permalink / raw)
To: Madadi Vineeth Reddy, util-linux
In-Reply-To: <79eaa2c0-65be-4370-b44f-2e8a1730b671@linux.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1493 bytes --]
Hello Vineeth,
Op 01-07-2025 om 07:05 schreef Madadi Vineeth Reddy:
> On 30/06/25 14:10, Benno Schulenberg wrote:
>> When not specifying a PID with --pid, `chrt` would report:
>>
>> chrt: invalid PID argument: '--pid'
>>
>> That was silly. After this change, `chrt --pid` will report:
>>
>> chrt: too few arguments
>
> IMO, the current message is already helpful, and I'm not sure
> the proposed one is much clearer.
>
> Maybe something like --pid requires an argument would be clearer?
There's no need for that, because when the user specified -p or --pid
without any further argument, then saying "too few arguments" will be
enough. No need to spell it out. The advantage of this short message
is that it allows folding the messages for "too few arguments" into a
single one in the overnext commit. Furthermore, the message is already
used in a few other util-linux tools, so it won't burden translators.
> Also, I noticed that currently more than one pid can't be passed
> if someone wants to update the custom slice for multiple pids at
> once. I can look into adding support for that if it's helpful.
I don't think that is a good idea: the current interface is already
confusing in that _gets_ info when a single argument follows --pid,
and that it _sets_ something when there a two arguments. Allowing
to set something for multiple PIDs at once while it's not possible
to query multiple PIDs at once... is more confusing.
Benno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* [PATCH v2] taskset: Accept 0 pid for current process
From: Jesse Rosenstock @ 2025-07-01 6:35 UTC (permalink / raw)
To: util-linux
Fixed comment style and expanded man page example.
https://github.com/util-linux/util-linux/compare/2c585534e8350aaaa2a1958a619d67febb613dc7..7591728c7f2a4c04c7faa0cc1141ee6df9ecc45b
https://github.com/util-linux/util-linux/pull/3637
This is useful to print the current mask without using `$$`: `taskset -p 0`.
It is also helpful to test taskset: `taskset -c 1-4 taskset -p 0`.
This is not easy with `$$`.
sched_setaffinity(2)/sched_getaffinity(2) accept 0 for the calling
thread, so this seems consistent.
As an implementation detail, we replace 0 with getpid(), so the existing
pid != 0 <==> "will exec" logic continues to work unchanged.
A reasonable alternative would be to interpret just `taskset` (currently
an error) as printing the current mask. This seems less orthogonal,
and a better use may be found for plain `taskset` in the future.
Signed-off-by: Jesse Rosenstock <jmr@google.com>
---
schedutils/taskset.1.adoc | 8 ++++++++
schedutils/taskset.c | 14 +++++++++++++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/schedutils/taskset.1.adoc b/schedutils/taskset.1.adoc
index 9773303f73..c919f82ec6 100644
--- a/schedutils/taskset.1.adoc
+++ b/schedutils/taskset.1.adoc
@@ -77,6 +77,7 @@
*-p*, *--pid*::
Operate on an existing PID and do not launch a new task.
+If PID is zero, then operate on the *taskset* process.
include::man-common/help-version.adoc[]
@@ -134,6 +135,13 @@
$ echo $? +
1 +
+== EXAMPLES
+
+Print the current CPU affinity as a list.
+
+$ taskset -pc 0 +
+pid 1355988's current affinity list: 0-47 +
+
== AUTHORS
Written by Robert M. Love.
diff --git a/schedutils/taskset.c b/schedutils/taskset.c
index b52cd4338b..dfcf291edb 100644
--- a/schedutils/taskset.c
+++ b/schedutils/taskset.c
@@ -186,7 +186,19 @@
all_tasks = 1;
break;
case 'p':
- pid = strtopid_or_err(argv[argc - 1],
_("invalid PID argument"));
+ /*
+ * Like strtopid_or_err() but accept 0 for this process,
+ * like sched_getaffinity()/sched_setaffinity() do.
+ */
+ pid = (pid_t) str2num_or_err(
+ argv[argc - 1], 10, _("invalid PID argument"),
+ 0, SINT_MAX(pid_t));
+ if (pid == 0)
+ pid = getpid();
+ /*
+ * After this point, pid == 0 means "no pid" and that
+ * we will exec a command.
+ */
break;
case 'c':
ts.use_list = 1;
^ permalink raw reply related
* Re: [PATCH 4/4] chrt: do not try to interpret any other option as a PID either
From: Madadi Vineeth Reddy @ 2025-07-01 5:21 UTC (permalink / raw)
To: Benno Schulenberg, util-linux; +Cc: Madadi Vineeth Reddy
In-Reply-To: <20250630084052.11041-4-bensberg@telfort.nl>
On 30/06/25 14:10, Benno Schulenberg wrote:
> When doing, for example, `chrt --pid --max`, it would report:
>
> chrt: invalid PID argument: '--max'
>
But --max is part of options right?
According to help text,
chrt [options] --pid <priority> <pid>
It should come before --pid right?
Thanks,
Madadi Vineeth Reddy
> This mistakenly gave the impression that the PID argument has to follow
> directly after the --pid option.
>
> Avoid this by delaying the parsing of a PID until after all options have
> been parsed. Temporarily set 'ctl->pid' to zero to indicate that a PID
> needs to be read.
>
> After this change, `chrt --pid --max` will simply report the minimum and
> maximum valid priorities. And `chrt --pid -v`:
>
> chrt: too few arguments
>
> Also, add a missing call of gettext() for the other error message.
>
> CC: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
> ---
> schedutils/chrt.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/schedutils/chrt.c b/schedutils/chrt.c
> index f5ecae6e1..f358bb273 100644
> --- a/schedutils/chrt.c
> +++ b/schedutils/chrt.c
> @@ -474,11 +474,7 @@ int main(int argc, char **argv)
> policy_given = true;
> break;
> case 'p':
> - if (argc - optind == 0)
> - errx(EXIT_FAILURE, _("too few arguments"));
> - errno = 0;
> - /* strtopid_or_err() is not suitable here; 0 can be passed.*/
> - ctl->pid = strtos32_or_err(argv[argc - 1], _("invalid PID argument"));
> + ctl->pid = 0; /* indicate that a PID is expected */
> break;
> case 'r':
> ctl->policy = SCHED_RR;
> @@ -507,18 +503,20 @@ int main(int argc, char **argv)
> }
> }
>
> - if (argc - optind < (ctl->pid > -1 ? 1 : 2))
> + if (argc - optind < (ctl->pid == 0 ? 1 : 2))
> errx(EXIT_FAILURE, _("too few arguments"));
>
> - /* pid exists but priority not given */
> - if (ctl->pid > -1 && argc - optind == 1) {
> - /* Error if priority is missing for a policy that requires it */
> - if (policy_given && need_prio)
> - errx(EXIT_FAILURE, ("policy %s requires a priority argument"),
> + /* If option --pid was given, parse the very last argument as a PID. */
> + if (ctl->pid == 0) {
> + if (need_prio && argc - optind < 2)
> + errx(EXIT_FAILURE, _("policy %s requires a priority argument"),
> get_policy_name(ctl->policy));
> + errno = 0;
> + /* strtopid_or_err() is not suitable here, as 0 can be passed. */
> + ctl->pid = strtos32_or_err(argv[argc - 1], _("invalid PID argument"));
>
> - /* If no policy specified, show current settings */
> - if (!policy_given) {
> + /* If no policy nor priority was given, show current settings. */
> + if (!policy_given && argc - optind == 1) {
> show_sched_info(ctl);
> return EXIT_SUCCESS;
> }
^ permalink raw reply
* Re: [PATCH 3/4] chrt: simplify the other check for too few arguments
From: Madadi Vineeth Reddy @ 2025-07-01 5:16 UTC (permalink / raw)
To: Benno Schulenberg, util-linux; +Cc: Madadi Vineeth Reddy
In-Reply-To: <20250630084052.11041-3-bensberg@telfort.nl>
On 30/06/25 14:10, Benno Schulenberg wrote:
> Without option --pid, always at least two arguments are needed:
> the <priority> value and a <command>. (The 'need_prio' variable
> is relevant only for the --pid case.)
>
> Also, make the error message more informative, and do not annoyingly
> suggest that the user try `chrt --help`.
Nit: I think we could still have "Try 'chrt --help' for more information."
along with your "too few arguments" so that user knows exactly how
many arguments are needed.
As is also is fine.
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Thanks,
Madadi Vineeth Reddy
>
> CC: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
> ---
> schedutils/chrt.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/schedutils/chrt.c b/schedutils/chrt.c
> index 8ed4d69f3..f5ecae6e1 100644
> --- a/schedutils/chrt.c
> +++ b/schedutils/chrt.c
> @@ -507,11 +507,8 @@ int main(int argc, char **argv)
> }
> }
>
> - if (((ctl->pid > -1) && argc - optind < (need_prio ? 1 : 0)) ||
> - ((ctl->pid == -1) && argc - optind < (need_prio ? 2 : 1))) {
> - warnx(_("bad usage"));
> - errtryhelp(EXIT_FAILURE);
> - }
> + if (argc - optind < (ctl->pid > -1 ? 1 : 2))
> + errx(EXIT_FAILURE, _("too few arguments"));
>
> /* pid exists but priority not given */
> if (ctl->pid > -1 && argc - optind == 1) {
> @@ -530,11 +527,10 @@ int main(int argc, char **argv)
> if (ctl->verbose)
> show_sched_info(ctl);
>
> - errno = 0;
> -
> - if (need_prio || argc - optind > 1)
> + if (argc - optind > 1) {
> + errno = 0;
> ctl->priority = strtos32_or_err(argv[optind], _("invalid priority argument"));
> - else
> + } else
> ctl->priority = 0;
>
> if (ctl->runtime && !supports_runtime_param(ctl->policy))
^ permalink raw reply
* Re: [PATCH 2/4] chrt: do not try to interpret the --pid option itself as a PID
From: Madadi Vineeth Reddy @ 2025-07-01 5:05 UTC (permalink / raw)
To: Benno Schulenberg, util-linux; +Cc: Madadi Vineeth Reddy
In-Reply-To: <20250630084052.11041-2-bensberg@telfort.nl>
On 30/06/25 14:10, Benno Schulenberg wrote:
> When not specifying a PID with --pid, `chrt` would report:
>
> chrt: invalid PID argument: '--pid'
>
> That was silly. After this change, `chrt --pid` will report:
>
> chrt: too few arguments
IMO, the current message is already helpful, and I'm not sure
the proposed one is much clearer.
Maybe something like --pid requires an argument would be clearer?
Also, I noticed that currently more than one pid can't be passed
if someone wants to update the custom slice for multiple pids at
once. I can look into adding support for that if it's helpful.
Thanks,
Madadi Vineeth Reddy
>
> CC: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
> ---
> schedutils/chrt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/schedutils/chrt.c b/schedutils/chrt.c
> index 4c45eae80..8ed4d69f3 100644
> --- a/schedutils/chrt.c
> +++ b/schedutils/chrt.c
> @@ -474,6 +474,8 @@ int main(int argc, char **argv)
> policy_given = true;
> break;
> case 'p':
> + if (argc - optind == 0)
> + errx(EXIT_FAILURE, _("too few arguments"));
> errno = 0;
> /* strtopid_or_err() is not suitable here; 0 can be passed.*/
> ctl->pid = strtos32_or_err(argv[argc - 1], _("invalid PID argument"));
^ permalink raw reply
* Re: [PATCH 1/4] chrt: with more than one argument, interpret first argument as priority
From: Madadi Vineeth Reddy @ 2025-07-01 4:57 UTC (permalink / raw)
To: Benno Schulenberg, util-linux; +Cc: Madadi Vineeth Reddy
In-Reply-To: <20250630084052.11041-1-bensberg@telfort.nl>
Hi Benno,
On 30/06/25 14:10, Benno Schulenberg wrote:
> The first argument is a priority not only for `chrt --pid <prio> <pid>`
> but also for `chrt <prio> <command> [<argument>...]`.
>
> This fixes an oversight in recent commit e7a2d62434.
>
> CC: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
> ---
> schedutils/chrt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/schedutils/chrt.c b/schedutils/chrt.c
> index 0bcdd1a1e..4c45eae80 100644
> --- a/schedutils/chrt.c
> +++ b/schedutils/chrt.c
> @@ -530,7 +530,7 @@ int main(int argc, char **argv)
>
> errno = 0;
>
> - if (need_prio || argc - optind == 2)
> + if (need_prio || argc - optind > 1)
> ctl->priority = strtos32_or_err(argv[optind], _("invalid priority argument"));
> else
> ctl->priority = 0;
LGTM.
Without this patch:
chrt 12 grep boo README
chrt: unsupported priority value for the policy: 0: see --max for valid range
With this patch:
chrt 12 grep boo README
See: http://vger.kernel.org/majordomo-info.html#taboo
Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Tested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Thanks,
Madadi Vineeth Reddy
^ permalink raw reply
* [PATCH] man: Replace RETURN VALUE with EXIT STATUS in section 1
From: Jesse Rosenstock @ 2025-06-30 18:59 UTC (permalink / raw)
To: util-linux
According to man-pages(7), sections 1 and 8 should normally use
EXIT STATUS, while sections 2 and 3 should use RETURN VALUE.
https://man7.org/linux/man-pages/man7/man-pages.7.html
https://github.com/util-linux/util-linux/pull/3638
Signed-off-by: Jesse Rosenstock <jmr@google.com>
---
schedutils/coresched.1.adoc | 2 +-
schedutils/taskset.1.adoc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/schedutils/coresched.1.adoc b/schedutils/coresched.1.adoc
index 997b6ab36e..483fff9929 100644
--- a/schedutils/coresched.1.adoc
+++ b/schedutils/coresched.1.adoc
@@ -96,7 +96,7 @@
Retrieving or modifying the core scheduling cookie of a process
requires *PTRACE_MODE_READ_REALCREDS* ptrace access to that process.
See the section "Ptrace access mode checking" in *ptrace*(2) for more
information.
-== RETURN VALUE
+== EXIT STATUS
On success, *{command}* returns 0.
If *{command}* fails, it will print an error and return 1.
diff --git a/schedutils/taskset.1.adoc b/schedutils/taskset.1.adoc
index 9773303f73..9384347372 100644
--- a/schedutils/taskset.1.adoc
+++ b/schedutils/taskset.1.adoc
@@ -106,7 +106,7 @@
A user can change the CPU affinity of a process belonging to the same
user. A user must possess *CAP_SYS_NICE* to change the CPU affinity of
a process belonging to another user. A user can retrieve the affinity
mask of any process.
-== RETURN VALUE
+== EXIT STATUS
*taskset* returns 0 in its affinity-getting mode as long as the
provided PID exists.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox