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 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>
See http://bugs.debian.org/cgi-bin/bugreport.cgi?641513
timerfd_settime(2) states that "The old_value argument returns a
structure containing the setting of the timer that was current at
the time of the call"; however, it does not mention that the
caller can pass NULL to ignore that value. Only the example
shows that the caller can pass NULL.
Reported-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux kernel commit cc56f7de7f00d188c7c4da1e9861581853b9e92f
meant sendfile(2) can work with any output file.
Therefore the 'out_fd' of sendfile(2) can refer to any file
(since Linux 2.6.33).
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk