As noted by Alan Curry:
According to man2/lseek.2,
This document's use of whence is incorrect English, but
maintained for historical reasons.
What is the grammatical objection?
From WordNet (r) 3.0 (2006) [wn]:
whence
adv 1: from what place, source, or cause
Wiktionary:
[edit] Adverb
whence (not comparable)
1. From where; from which place or source.
lseek's second parameter is a distance to be traveled, and
the third parameter chooses the starting point from which
that distance is measured. How is that not a "whence"?
Looking at some man page archives, I found that the accusation
of incorrect English goes back to before 4.4BSD. It survives
not just in the linux-man-pages but also in recent versions
of {Net,Open,Free}BSD. The name "whence" for this parameter
goes back at least to V7.
Of all the people who have read this page over the years,
am I the only one wondering... what's this about? Who decided
that "whence" was incorrect and put that note in the man page?
Was there ever anything wrong, or do we have someone's
20-year-old unresearched pet peeve lingering in the man pages?
Reported-by: Alan Curry <pacman@kosh.dhis.org>
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Now that the underlying system call rt_sigqueueinfo(2) is
properly documented, move sigqueue() to Section 3, since
it is really a library function.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This replaces the previous '.so' man page link file for
rt_sigqueueinfo.2, which linked to ths sigqueue() man page.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
We've recently discovered that GDB will fail to attach to any
process that sets itself non-dumpable. Tested on kernel 2.6.32,
with:
int main(int argc, char *argv[])
{
if (prctl(PR_SET_DUMPABLE, 0, 0, 0) != 0) {
perror("prctl");
}
printf("Run gdb %s %d\n", argv[0], getpid());
sleep(20);
abort();
}
./a.out
Run gdb ./a.out 30476
gdb -q ./a.out 30476
Reading symbols from /tmp/a.out...done.
Attaching to program: /tmp/a.out, process 30476
ptrace: Operation not permitted.
/tmp/30476: No such file or directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The man pages for cacos(), cacosh(), catan(), catanh()
contain incorrect formulae describing the functions.
As reported by Richard B. Kreckel:
cacos, cacosf, cacosl:
The formula given in the man page
cacos(z) = -i clog(z + csqrt(z * z - 1))
gives wrong results in second and fourth quadrant of
complex plain.
The formula
cacos(z) = -i clog(z + I*csqrt(1 - z * z))
gives correct results.
catan, catanf, catanl:
The formula given in the man page
catan(z) = 1 / 2i clog((1 + iz) / (1 - iz))
gives wrong results on the negative imaginary axis beginning
at -I (along one of the two branch cuts). Besides, the formula
is written in an ambiguous way.
The formula
catan(z) = (clog(1 + iz) - clog(1 - iz)) / 2i
gives correct results.
cacosh, cacoshf, cacoshl:
The formula given in the man page
cacosh(z) = (0.5) * clog((1 + z) / (1 - z))
gives wrong results everywhere in the complex plain.
(The formula seems to be copied from the one for catanh,
where it is sometimes correct.)
The formula
cacosh(z) = 2 * clog(csqrt((z + 1)/2) + csqrt((z - 1)/2))
gives correct results.
catanh, catanhf, catanhl:
The formula given in the man page
catanh(z) = 0.5 * clog((1 + z) / (1 - z))
gives wrong results on the positive real axis beginning at 1
(along one of the two branch cuts).
The formula
catanh(z) = 0.5 * (clog(1 + z) - clog(1 - z))
gives correct results.
I've also checked casin, casinf, casinl, casinh, casinhf, and
casinhl and the formulae given there
casin(z) = -i clog(iz + csqrt(1 - z * z))
casinh(z) = clog(z + csqrt(z * z + 1))
are actually correct.
Reported-by: Richard B. Kreckel <kreckel@ginac.de>
Reviewed-by: Andries Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current version of the page says (under ERRORS):
> EBUSY (not on Linux)
> The file pathname cannot be unlinked because it is being
> used by the system or another process and the
> implementation considers this an error.
But if you look in the kernel source file fs/namei.c
at routine may_delete() you'll see two occasions where
an EBUSY is generated. So the above "not on Linux" is wrong.
I suggest that this '(not on Linux)' be removed. It may
also improve the page if the commentary is reworded to give a
better description of the two situations. Something along
the lines of:
> The file pathname cannot be unlinked because it is being used
> by the system, e.g. if some (relative) rootdir is mounted upon it,
> or because the NFS client software created it to represent an
> active but otherwise nameless inode ("NFS silly renamed").
Just FYI: the NFS silly rename (you'll find this term mentioned
in the kernel source code) is described at:
http://nfs.sourceforge.net/#section_d
under section D2. The reason I found this manpage bug is because
I stumbled upon one of these silly renamed files, and an strace
of the rm-command revealed the EBUSY return errno.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux 3.0 (commit f8df13e0a901fe55631fed66562369b4dba40f8b)
implements \E[3J to allow scrambling content of console
including scroll-back buffer
(http://thread.gmane.org/gmane.linux.kernel/1125792).
This is useful at terminal lock to disallow attacker to scroll
visible window back and to see sensitive data. Other \E[J sequences
do not blank history.
\E[3J is superset of \E[2J. In other words, it clears visible screen too.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk