Amit Pinhas [Wed, 12 Feb 2025 20:56:20 +0000 (22:56 +0200)]
man/man2/kill.2: RETURN VALUE: Fix wording issue with sig=0
The DESCRIPTION says:
If *sig* is 0, then no signal is sent, but existence and
permission checks are still performed; this can be used to
check for the existence of a process ID.
On the other hand, the `RETURN VALUE` section contradicted that.
On success (at least one signal was sent), zero is returned. On
error, -1 is returned...
How can I get 0 when providing sig=0, if no signal was actually
sent, which is the criteria for success of this call???
Reported-by: Amit Pinhas <amitpinhass@gmail.com> Co-authored-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Amit Pinhas <amitpinhass@gmail.com>
Message-ID: <a4fa37e0fc89a3c99982ace3fe381991ebe85b00.1739393685.git.amitpinhass@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
GNUmakefile: help: Show only variables assigned with '?='
The others are internal stuff that most likely shouldn't be touched.
Cc: Sam James <sam@gentoo.org> Cc: Paul Smith <psmith@gnu.org> Cc: Guenther Noack <gnoack@google.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
share/mk/: Use ?= assignments for user-facing variables
This allows users specifying them as environment variables.
Cc: Sam James <sam@gentoo.org> Cc: Paul Smith <psmith@gnu.org> Cc: Guenther Noack <gnoack@google.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
GNUmakefile: Require the user to specify '-R' if their make(1) is too old
And everyone's make(1) is too old. :-)
This will allow us to use ?= assignments. Once a new GNU make(1)
release is done, we'll be able to rely on our setting of MAKEFLAGS+=-R
at the top of the GNUMakefile, but currently, that's not enough, and the
user must specify -R to unset implicit variables.
Cc: Sam James <sam@gentoo.org> Cc: Paul Smith <psmith@gnu.org> Cc: Guenther Noack <gnoack@google.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
GNU make(1) 4.2 seems to be interpreting those characters as the start
of a comment, so we need to escape them. That seems to calm those old
versions of make(1), and doesn't affect negatively the newer ones, and
doesn't affect negatively grep(1) either.
Fixes: 35a780a99bd8 (2024-07-20; "share/mk/: CPPFLAGS: Only define _FORTIFY_SOURCE if it's not already defined") Fixes: 2130162900ab (2024-11-03; "share/mk/, etc/shellcheck/: lint-sh: Add target to lint shell scripts") Reported-by: Boris Pigin <boris.pigin@gmail.com> Cc: Sam James <sam@gentoo.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Mark Harris [Sun, 9 Feb 2025 01:24:14 +0000 (17:24 -0800)]
man/man3/timespec_get.3: Correct return value and clarify description
- 0, not -1, is returned for an unsupported time base or error
(C23 7.29.2.6, 7.29.2.7; POSIX.1-2024 line 74358).
- Clarify that any supported value of base is always nonzero (i.e.,
there is no overlap between the two return value cases that may
require errno or some other source to disambiguate)
(C23 7.29.2.6, 7.29.2.7; POSIX.1-2024 line 74357).
- Clarify that timespec_getres(NULL, base) is a valid call to check
whether the specified time base is supported (C23 7.29.2.7).
- Clarify that the resolution for a particular time base is constant
for the lifetime of the process (i.e., there is no need to retrieve
it repeatedly) (C23 7.29.2.7).
- Calls to these functions are not technically equivalent to any
clock_* function call; at least the return value will be different.
Clarify that it is the time and resolution that are the same.
- The ERRORS section is removed, because it states only what is true
for every function that does not state otherwise (i.e., errno might
be affected by underlying system calls).
Fixes: 7bda5119fe5e (2024-09-08; "timespec_get.3, timespec_getres.3: Add page and link page") Cc: наб <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Mark Harris <mark.hsj@gmail.com>
Message-ID: <5f8dc5d2dc51f080a18de53e98610df43389b98b.1739063937.git.mark.hsj@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
man/man3/regex.3: EXAMPLES: Don't use z length modifier with unsigned int
GCC and Clang print warnings:
$ clang main.c -Wall
main.c:30:23: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'unsigned int' [-Wformat]
30 | printf("#%zu:\n", i);
| ~~~ ^
| %u
1 warning generated.
$ gcc main.c -Wall
main.c: In function ‘main’:
main.c:30:16: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 2 has type ‘unsigned int’ [-Wformat=]
30 | printf("#%zu:\n", i);
| ~~^ ~
| | |
| | unsigned int
| long unsigned int
| %u
The autogroup feature can be contolled at runtime when built into the
kernel. Disabling it in this case still creates autogroups and still
shows the autogroup membership for the task in /proc. The scheduler
code will just not use the the autogroup task group. This can be
confusing to users. Add a sentence to this effect to sched.7 to point
this out.
The kernel code shows how this is used. The sched_autogroup_enabled
toggle is only used in one place.
kernel/sched/autogroup.h:
static inline struct task_group *
autogroup_task_group(struct task_struct *p, struct task_group *tg)
{
extern unsigned int sysctl_sched_autogroup_enabled;
int enabled = READ_ONCE(sysctl_sched_autogroup_enabled);
if (enabled && task_wants_autogroup(p, tg))
return p->signal->autogroup->tg;
return tg;
}
task_wants_autogroup() is in kernel/sched/autogroup.c:
One can see that any group set other than root also bypasses the use of
the autogroup. All of the machinery around the creation of the
autogroup is not effected by the toggle.
From userspace:
0
/autogroup-112 nice 0
Note, systemd based system these days is not really using autogroups at
all anyway because any task in a non-root cgroup bypasses the autogroup
as well.
Cc: Carlos O'Donell <codonell@redhat.com> Signed-off-by: Phil Auld <pauld@redhat.com>
Message-ID: <20250116143747.2366152-1-pauld@redhat.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
man/man7/pathname.7: Pathnames are opaque C strings
On Mon, Jan 27, 2025 at 07:27:59PM +0100, наб wrote:
> Skimming the thread: UNIX paths are sequences of non-NUL bytes.
>
> It is never correct to expect to be able to have a (parse, unparse)
> operation pair for which unparse(parse(x)) = x for path x.
>
> It's obviously wrong to reject a pathname just because you dont like it.
>
> Thus, when displaying a path, either (a) dump it directly to the output
> (the user has configured their display device to understand the paths they use),
> or if that's not possible (b) setlocale(LC_ALL, "") + mbrtowc() loop
> and render the result (applying usual ?/� substitutions for mbrtowc()
> errors makes sense here).
>
> There are very few operations on paths that are actually reasonable
> to do, ever; those are: appending stuff, prepending stuff
> (this is just appending stuff with the arguments backwards),
> and cleaving at /es;
> the "stuff" better be copied whole-sale from some other path
> or an unprocessed argument (or, sure, the PFCS).
>
> If you're getting bytes to append to a path, do that directly.
>
> If you're getting characters to append to a path,
> then wctomb(3) is the only non-invalid solution,
> since that (obviously) turns characters into bytes in the current
> locale, which (ex def) is the operation desired.
>
> I don't understand what the UTF-32 dance is supposed to be.
>
> If you're recommending transcoding paths, don't.
>
> To re-iterate: paths are not character sequences.
> They do not represent characters.
> You can't meaningfully coerce them thusly without loss of precision
> (this is ok to do for display! and nothing else).
> If at any point you find yourself turning wchar_t -> char
> you are doing something wrong;
> if you find yourself doing char -> wchar_t for anything beside display
> you should probably reconsider.
>
> This is different under Win32 of course. But that concerns us naught.
The goal of this new manual page is to help people create programs that
do the right thing even in the face of unusual paths. The information
that I used to create this new manual page came from these sources:
Jason Yundt [Tue, 14 Jan 2025 21:14:25 +0000 (16:14 -0500)]
man/man7/man-pages.7: Stop telling contributors to write titles in all caps
Recently, I submitted my first patch to the Linux man-pages project. In
my patch, I had created a new manual page. On the manual page’s title
line, I had written the title of my new page in all caps because
man-pages(7) said that I should write it that way. It turns out that
man-pages(7) was wrong and that the title on the title line should have
matched the title in the manual page’s filename [1][2]. This commit
corrects man-pages(7) so that it does not tell contributors to use all
caps when writing titles on title lines.
The _exit(2) function is a better choice for exiting a child in many
cases. Most prominently it avoids calls of functions registered with
atexit(3) by the parent.
There are valid reasons to call exit(3) and the example is actually one
of them: flush FILE-based output. Since atexit(3) is never called, we
could just stay with exit(3).
In src/bin/duffman line 30:
cd $(git rev-parse --show-toplevel);
^-- SC2046 (warning): Quote this to prevent word splitting.
^---------------------------^ SC2312 (info): Consider invoking this command separately to avoid masking its return value (or use '|| true' to ignore).
So this was experienced by people for 5 months at best,
and could remotely be experienced for 3 years
(if you somehow wanted this bad behaviour and added it into your shell),
over 20 years ago.
No modern reader (or, frankly, non-modern reader)
has ever used this, or could use it, really.
Link to the removal note for completeness only.
Link: <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bf079e19f50d64aa5e05b5e17ec29afab9aabb20> Cc: Eugene Syromyatnikov <evgsyr@gmail.com> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Message-Id: <dwfybzlb5ydbsc4puo6igj7nm7iregquv6hxhhqb53bwrvqswb@tarta.nabijaczleweli.xyz>
[alx: Add break points in URI; minor tweaks to commit message too] Signed-off-by: Alejandro Colomar <alx@kernel.org>
man/man3/strverscmp.3: This is NOT the ordering used by ls -v
Compare, given:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int compar(const char **l, const char **r) {
return strverscmp(*l, *r);
}
int main(int argc, char ** argv) {
qsort(argv + 1, argc - 1, sizeof(*argv), compar);
for(int i = 1; i < argc; ++i)
puts(argv[i]);
}
yields:
$ /bin/ls -v1 a* # coreutils ls
a-1.0a
a-1.0.1a
$ ../vers a* # as above
a-1.0.1a
a-1.0a
$ ls -v1 a* # voreutils ls @ 5781698 with strverscmp()-equivalent sorting
a-1.0.1a
a-1.0a
compare also the results for real data like
netstat-nat-1.{0,1{,.1},2,3.1,4{,.{1,2,3,4,5,6,7,8,9,10}}}.tar.gz
Thus, coreutils ls -v (and sort -V) does NOT use strverscmp(3);
it uses a modified Debian version comparison algorithm with additional
suffix processing and `ls -v`-specific exceptions.
Ian Rogers [Fri, 6 Dec 2024 07:38:25 +0000 (23:38 -0800)]
proc_pid_fdinfo.5: Reduce indent for most of the page
When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph, move the
"since Linux 2.6.22" to a new HISTORY subsection.
Lorenzo Stoakes [Thu, 5 Dec 2024 10:41:25 +0000 (10:41 +0000)]
madvise.2: Add description of MADV_GUARD_INSTALL, MADV_GUARD_REMOVE
Lightweight guard region support has been added to Linux 6.13, which
adds MADV_GUARD_INSTALL and MADV_GUARD_REMOVE flags to the madvise()
system call. Therefore, update the manpage for madvise() and describe
these operations.
projects / thirdparty / man-pages.git / log
