It certainly seems like that change happened some time ago.
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add new page based on Debian localedef(1) page.
Cowritten-by: Richard Braakman <richard.braakman@jollamobile.com>
Cowritten-by: Alastair McKinstry <mckinstry@computer.org>
Cowritten-by: Lars Wirzenius <liw@iki.fi>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
yesstr/nostr in LC_MESSAGES are planned to be changed at some
point [1], so it's better to provide an example which won't
be obsoleted by that change.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16975
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Helpful for three purposes, 1) shows the expected naming scheme,
2) shows where to point LOCPATH to, and 3) gives an idea to the
attentive how to use a more generic, location independent
directory with location dependent, more specific ones.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Installing the man pages to /usr may not be the preferred option
when working on a system with a packaging system like apt or yum,
where /usr is reserved for packages and /usr/local or /opt is used
for user addons.
README should explain how to install to a path different to /usr.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
mmap() and msync() were already described as not leading to
inotify events. This patch adds munmap(). I created and executed
a test to verify this.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This example of the usage of the inotify API shows the
usage of inotify_init1(2) and inotify_add_watch(2) as well
as polling and reading from the inotify file descriptor.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Example from https://sourceware.org/glibc/wiki/Locales
After modifying a locale, make sure it compiles, and install it to a
temporary directory for testing:
unset LC_ALL
LOCALE=fi_FI
export I18NPATH=$HOME/locale-test/
export LOCPATH=$HOME/locale-test/
mkdir -p $LOCPATH
localedef --no-archive -f localedata/charmaps/UTF-8 -i localedata/locales/$LOCALE $I18NPATH/$LOCALE.UTF-8
LC_TIME=$LOCALE.UTF-8 locale -ck LC_TIME
LC_TIME=$LOCALE.UTF-8 locale -ck date_fmt
LC_TIME=$LOCALE.UTF-8 date
LC_CTYPE=$LOCALE.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT < translit-test-input.txt
LC_COLLATE=$LOCALE.UTF-8 sort < sorting-test-input.txt
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
am_pm should be defined only if AM/PM convention is used to signal
applications they should not try to print them when using them in
unwanted.
Same for all LC_NAME keywords expect for name_fmt which should be
always defined.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some information that was here will move to locale(7).
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Keld Simonsen in the lib-locales@sourceware mailing
list:
https://sourceware.org/ml/libc-locales/2014-q2/msg00008.html
From: Keld Simonsen <keld at rap dot rap dot dk>
To: Marko Myllynen <myllynen at redhat dot com>
Date: Tue, 29 Apr 2014 17:02:09 +0200
lang_term reflects ISO 639-2/T (terminology) codes, while
lang_lib reflects ISO 639-2/B (bibliographic) codes.
lang_term is preferred over lang_lib codes for locale names.
There are 20 specific ISO 639-2/B codes.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_setaffinity_np() and
pthread_getaffinity_np() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function pthread_equal() is thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function pthread_getcpuclockid() is thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_setconcurrency() and
pthread_getconcurrency() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk pointed me to alignment issues which may
arise when reading misaligned integers.
On some systems integer values can only be read if they are
correctly aligned. Other system have a lower performance when
reading from or writing to misaligned memory positions.
Therefore, the buffer used to call read(2) for a fanotify
file descriptor should have the same alignment as
struct fanotify_event_metadata.
Due to the casting to char* inside the macros
FAN_EVENT_OK and FAN_EVENT_NEXT we can use any
data structure for the buffer.
With the patch an array of struct fanotify_event_metadata is
used as buffer which seems a natural choice to ensure proper
alignment.
It should be remembered that the offset between events is given
by field event_len and iterating over the array may not be
allowable in future. Instead the macros should be used.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The rootp argument to tfind is "void * const *",
not "const void **".
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The alphasort and versionsort functions take arguments of type const
struct dirent **, not const void *.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fix const- and signedness of various char* parameters.
Also, there is no "struct state", but _res is a struct
__res_state. (Actually, _res is errno-like in that it is really a
macro expanding to (*__res_state()).)
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove const qualifiers from arguments to key_decryptsession,
key_encryptsession, and key_setsecret.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk