Changes.old: tfix for 3.73 changelog

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
getgrent.3: Add ENOENT  and EAGAIN to error list

It's possible to get ENOENT returned from getgrent()
if the backend, for example say SSSD, isn't configured
or the daemon isn't running. The same can be said of any
of the NSS backend.

As POSIX does not list ENOENT, we can list it ourselves
and define it how we like.

I don't know how you handle errno values that are glibc
specific, but here is the patch that enhances getgrent(3)
to make users aware of what ENOENT is intended to mean
from glibc.

While I'm fixing one I might as well [add EAGAIN].

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
sched.7: SEE ALSO: add taskset(1)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
sched_setattr.2, sched_setscheduler.2: SEE ALSO: add chrt(1)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
realpath.3: SEE ALSO: add realpath(1)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
readlink.2: SEE ALSO: add realpath(3)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
euidaccess.3: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
namespaces.7: tfix: CLONE_IPC -> CLONE_NEWIPC

CLONE_NEWIPC is the correct constant, as can be seen in the detailed
list of namespaces & their corresponding constants, as well as the
clone(2) man page and include/uapi/linux/sched.h in the Linux source tree.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
execve.2: Remove unneeded ".sh" extension in interpreter script example

See https://bugzilla.kernel.org/show_bug.cgi?id=84701

As noted by C. Alex North-Keys:

1) Command name extensions considered harmful: Adding ".sh", or
any other unneeded extension, unnecessarily duplicates meta
information already present in the interpreter directive,
exposing an implementation detail that then ends up explicitly
part of other programs running this one.  Later, when such a
script is replaced with a new version in Python, C, etc., the
useless ".sh" has to be retained to avoid breaking those other
programs' calls to this one, and now has a stark antifunction
of lying about the script's content and occasionally causing
admins to run undefined experiments as root (like
"bash -x ./reallyperlscript.sh"). Such extensions, while fine
in DOS which ignores extensions explicitly, is a serious flaw
in Unix-targeted script writing.  Canonical documentation
from the Linux manual should not support such a flawed idiom -
recommending against it would be preferred.

A more extensive rant against them can be found at:
http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful

2) The space after "#!" in the interpreter directive is minor -
and the kernel's fs/binfmt_script.c specifically allows for it -
but versions of unix have length limits from ~30 characters to
Linux's 127 or so (if that number's correct) so the space does
have a cost.  Most scripts I've seen lack that space, and
there's no real reason to encourage it.

Reported-by: C. Alex North-Keys <erlkonig@talisman.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>