Thank you for the detailed answer. I'll use this information to talk to xfce devs and the maintainer if they could do anything to keep a consistent experience in OpenBSD.
El June 25, 2021 5:28:00 PM UTC, Ingo Schwarze <schwarze@usta.de> escribió:
>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
--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
No comments:
Post a Comment