<groff: iso_8859-2.7>:89: warning: can't find special character `shc'
This is the only "iso_8859-*.7" file that has this (now)
undefined character. The code in column four in "iso_8859-1.7" is
"0x2D" ("HYPHEN, MINUS SIGN" or "HYPHEN-MINUS") instead of "0xAD".
See Debian bug 156154 (or package "manpages").
There should be an explanation for this graphic character and the
code should be 0xAD in iso_8859-1.7 (as in all others), even
though "[gn]roff" does not display a "HYPHEN" in that position of
the table.
The line with "SOFT HYPHEN" gets a footnote and a short
explanation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rasmus:
Both my system's man-pages (3.22) and the latest online
(3.41) show:
int mprotect(const void *addr, size_t len, int prot);
as the prototype for mprotect(2). However, POSIX [1] and the
actual sys/mman.h (on all the systems I checked) do not have
the const qualifier on the first argument.
Reported-by: Rasmus Villemoes <Rasmus.Villemoes@decode.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The syntax .UR http://example.com paired with .UE will create
links which one can interact, if the pager allows that. One
way to see the effect is ask the man(1) command to use browser
display, e.g.:
man -H man7/uri.7
("\:" is optional groff syntax to permit hyphenless line breaks.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
uri(7) documents that "Older documents suggested inserting the
prefix 'URL:' just before the URI, but this form has never
caught on." and advise to "enclosed in angle brackets" (and a
few other alternatives).
This patch removes an instance of 'URL:' from the page.
Reported-By: Denis Barbier <bouzim@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I didn't like ithe "SIGKILL operates similarly, with exceptions"
phrase (if it's different, then it's not "similar", right?),
and now I got around to changing it. Now it says simply:
"SIGKILL does not generate signal-delivery-stop and therefore
the tracer can't suppress it."
Replaced "why WNOHANG is not reliable" example with a more
realistic one (the one which actually inspired to add this
information to man page in the first place): we got
ESRCH - process is gone! - but waitpid(WNOHANG) can still
confusingly return 0 "no processes to wait for".
Replaced "This means that unneeded trailing arguments may
be omitted" part with a much better recommendation
to never do that and to supply zero arguments instead.
(The part about "undocumentedness" of gcc behavior was bogus,
btw - deleted).
Expanded BUGS section with the explanation and an example
of visible strace behavior on the buggy syscalls which
exit with EINTR on ptrace attach. I hope this will lead
to people submitting better bug reports to lkml about
such syscalls.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For IOPRIO_WHO_PROCESS, who==0 means operate on the caller.
For IOPRIO_WHO_PGRP, who==0 means operate on the caller's
process group.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652443
Reported-by: Марк Коренберг <socketpair@gmail.com>
Reported-by: Kalle Olavi Niemitalo <kon@iki.fi>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Herbert Xu, these should not be considered as PIDs.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383296
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The man page formerly noted the bash(1) v1 command to do this.
Reported-by: Aaron Peschel <aaron.peschel@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Mainly rewording things like "is delivered" to "becomes pending",
which is more accurate terminology.
Reported-by: Daniel Zingaro <daniel.zingaro@utoronto.ca>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This system call was never visible to user space, so it makes
sense to move it out of the main table of system calls into
the notes below the table.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reduce the chance that the reader may be misled into thinking
that there is a wrapper function for this system call by noting
explicitly in the SYNOPSIS that there is no glibc wrapper and
pointing the reader to NOTES for further details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk