Hi,
Jan Stary wrote on Tue, Jun 22, 2021 at 11:24:15AM +0200:
> On Jun 20 18:58:31, ffuentes@texto-plano.xyz wrote:
>> I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine
>> with it. However, my date is expressed directly as it comes from date(1).
>> This is confirmed by their docs
>> https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make date to
>> work with my language.
>>
>> This is my locale:
>>
>> LANG=es_CL.UTF-8
>> LC_COLLATE="es_CL.UTF-8"
>> LC_CTYPE="es_CL.UTF-8"
>> LC_MONETARY="es_CL.UTF-8"
>> LC_NUMERIC="es_CL.UTF-8"
>> LC_TIME="es_CL.UTF-8"
>> LC_MESSAGES="es_CL.UTF-8"
>> LC_ALL=es_CL.UTF-8
> man locale
>
> Programs in the OpenBSD base system ignore the locale except
> for the character encoding, and it is not recommended to
> use any of these variables except that the following
> non-default setting is supported as an option:
>
> export LC_CTYPE=en_US.UTF-8
>
> OpenBSD's date(1) ignores your locale setting.
That's the correct answer, and there are no plans to change that in
the future.
The reason is that we prioritize simplicity and maintainablity
of the C library, and consequently correctness and security,
over localization of base system facilities. On top of that,
even if you do not take the horrible complication of the library
code that LC_* support would imply into account, LC_* also poses
some security risks from the user perspective, in particular in
system administration and maintenance contexts. Predicatbility
of output, and consistent parsing of input, is more valuable for
low-level work than localization.
Perspectives may vary, but my personal opinion is that adding all
those LC_* variables to POSIX was a mistake. The C library is
not a reasonable place to handle higly specialized and highly
complicated topics like localization. They belong into
specialized programs like typesettung software, UI libraries
and the like, not into a general-purpose operating system.
In general, we try to follow POSIX because standardization and
portability have significant advantages. But there are limits.
If standards requirements are too bad, we may decide to ignore
them in some (rare) cases. Hence, on OpenBSD, you can rely on
predictable output from strftime(3) and on predictable parsing
by strptime(3).
All this is mostly documented, for example:
STRFTIME(3) Library Functions Manual
[...]
CAVEATS
On systems other than OpenBSD, the LC_TIME locale(1) category can
cause erratic output; see CAVEATS in setlocale(3) for details.
SETLOCALE(3) Library Functions Manual
[...]
CAVEATS
On systems other than OpenBSD, calling setlocale() or uselocale(3)
with a category other than LC_CTYPE can cause erratic behaviour
of many library functions. For security reasons, make sure
that portable programs only use LC_CTYPE.
For example, the following functions may be affected. The
list is probably incomplete. For example, additional library
functions may be impacted if they directly or indirectly call
affected functions, or if they attempt to imitate aspects of
their behaviour. Functions that are not standardized may be
affected too.
LC_COLLATE
glob(3), strcoll(3), strxfrm(3), wcscoll(3), wcsxfrm(3),
and the functions documented in regexec(3)
LC_MESSAGES
catgets(3), catopen(3), nl_langinfo(3), perror(3),
psignal(3), strerror(3), strsignal(3), and the functions
documented in err(3)
LC_MONETARY
localeconv(3), nl_langinfo(3), strfmon()
LC_NUMERIC
atof(3), localeconv(3), nl_langinfo(3), strfmon(), and
the functions documented in printf(3), scanf(3),
strtod(3), wcstod(3), wprintf(3), wscanf(3). This
category is particularly dangerous because it can cause
bugs in the parsing and formatting of numbers, for
example failures to recognize or properly write decimal
points.
LC_TIME
getdate(), nl_langinfo(3), strftime(3), strptime(3).
Similarly, this is prone to causing bugs in the parsing
and formatting of date strings.
LC_CTYPE
On systems other than OpenBSD, this category may affect
the behaviour of additional functions, for example:
btowc(3), isalnum(3), isalpha(3), isblank(3), iscntrl(3),
isdigit(3), isgraph(3), islower(3), isprint(3),
ispunct(3), isspace(3), isupper(3), isxdigit(3),
mbsinit(3), strcasecmp(3), strcoll(3), strxfrm(3),
tolower(3), toupper(3), vis(3), wcscoll(3), wcsxfrm(3),
wctob(3)
Yours,
Ingo
No comments:
Post a Comment