Re: [systemd-devel] Additional Locale Variables for Units and Number Format

2023-08-31 Thread Lennart Poettering
On Di, 29.08.23 17:17, TJ Shipp (onezoo...@msn.com) wrote:

> I am trying to add in support for a separate variable to change our unit 
> system, and having both LANG and UNITS to identify the "locale" of the system.
> We are also not only looking for English versus Metric, but are looking for 
> mixed units as well (both Imperial and Metric hybrid), as well as looking to 
> add number formats (1,000.00 vs 1.000,00)
>
> And what is the best way to add support for a new system environment variable 
> such as UNITS?
>
> P.S. If anyone is interested in contracting to do this work, please send me a 
> private message outside this list.

systemd-devel is not the right forum for this. Not sure what a better
forum for this is, but systemd is way too low-level system stuff for
that.

Hence, I don't know who to suggest you to contact about this, but
maybe someone at the Linux Foundation can connect you.

Lennart

--
Lennart Poettering, Berlin


Re: [systemd-devel] Additional Locale Variables for Units and Number Format

2023-08-30 Thread Dave Howorth
On Wed, 30 Aug 2023 00:53:55 +
TJ Shipp  wrote:
> Thank you, I think LC_NUMERIC will work for the number formatting, my
> company is also looking for something along the lines of this, and
> hoping to use locale/systemd to handle it:
> 
> https://lists.freedesktop.org/archives/xdg/2023-August/014659.html
> 
> From: systemd-devel  on
> behalf of systemd-devel-requ...@lists.freedesktop.org
>  Sent: Tuesday, August
> 29, 2023 6:24 PM To: systemd-devel@lists.freedesktop.org
>  Subject: systemd-devel Digest,
> Vol 160, Issue 37
> 
> Send systemd-devel mailing list submissions to
> systemd-devel@lists.freedesktop.org

Please trim your replies, especially if replying to a digest!

What you're looking for sounds under-specified and potentially very
complex. I would recommend that you try to implement a freestanding
system that implements all the requirements you have, and only then
consider integrating it in whatever 'standard' you think is appropriate.

At present I don't think you'll find it easy to persuade people this is
something that is sensible to incorporate in some other system.


Re: [systemd-devel] Additional Locale Variables for Units and Number Format

2023-08-29 Thread TJ Shipp
Thank you, I think LC_NUMERIC will work for the number formatting, my company 
is also looking for something along the lines of this, and hoping to use 
locale/systemd to handle it:

https://lists.freedesktop.org/archives/xdg/2023-August/014659.html

From: systemd-devel  on behalf of 
systemd-devel-requ...@lists.freedesktop.org 

Sent: Tuesday, August 29, 2023 6:24 PM
To: systemd-devel@lists.freedesktop.org 
Subject: systemd-devel Digest, Vol 160, Issue 37

Send systemd-devel mailing list submissions to
systemd-devel@lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
systemd-devel-requ...@lists.freedesktop.org

You can reach the person managing the list at
systemd-devel-ow...@lists.freedesktop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of systemd-devel digest..."


Today's Topics:

   1. Re:  Additional Locale Variables for Units and Number Format
  (Mantas Mikul?nas)
   2. Re:  Why are the priorities of stdout and stderr the same
  (Nils Kattenbeck)
   3. Re:  Why are the priorities of stdout and stderr the same
  (Cecil Westerhof)
   4. Re:  oomd wake-up frequency (Christian Hergert)
   5. Re:  Bluetooth in a multiseat (via loginctl) setup
  (Christian Pernegger)


--

Message: 1
Date: Tue, 29 Aug 2023 23:19:19 +0300
From: Mantas Mikul?nas 
To: TJ Shipp 
Cc: Systemd 
Subject: Re: [systemd-devel] Additional Locale Variables for Units and
    Number Format
Message-ID:

Content-Type: text/plain; charset="utf-8"

It sounds like you're reinventing LC_NUMERIC.

The locale system has a lot more than just LANG; it already allows the
number format to be overridden separately from the "language". Take a look
at `locale -k LC_NUMERIC` and <
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html>.

Adding custom variables would require changing a lot ? I guess the main
consumers are libc (Glibc) and libstdc++ (GCC), but of course there are
many places which set the existing LC_* and expect things to change
accordingly, or which might implement the standard interfaces on their own
without using libc.

On Tue, Aug 29, 2023, 20:17 TJ Shipp  wrote:

> I am trying to add in support for a separate variable to change our unit
> system, and having both LANG and UNITS to identify the "locale" of the
> system.
> We are also not only looking for English versus Metric, but are looking
> for mixed units as well (both Imperial and Metric hybrid), as well as
> looking to add number formats (1,000.00 vs 1.000,00)
>
> And what is the best way to add support for a new system environment
> variable such as UNITS?
>
> P.S. If anyone is interested in contracting to do this work, please send
> me a private message outside this list.
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/systemd-devel/attachments/20230829/22c38e57/attachment-0001.htm>

--

Message: 2
Date: Tue, 29 Aug 2023 23:05:28 +0200
From: Nils Kattenbeck 
To: Cecil Westerhof 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Why are the priorities of stdout and
stderr the same
Message-ID:

Content-Type: text/plain; charset="UTF-8"

No, you can use systemd-cat to then invoke your script which applies
to every output of it.

Also, you can just use reply-all in gmail (or even set it as the
default in the settings) to have the correct behaviour of sending
mails also the the mailing list.

On Tue, Aug 29, 2023 at 10:25?PM Cecil Westerhof  wrote:
>
> Aargh, forgot again that gmail works differently when replying. :'-{
>
> Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof :
>>
>> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck :
>>>
>>> Hi, At least for simple cases you can use systemd-cat which allows
>>> setting different priorities for stdout and stderr. It even explicitly
>>> states that doing so will lose the ordering guarantees which are only
>>> possible when attaching stdout and stderr to the same fd (as Lennart
>>> said).
>>
>>
>> If I understand it correctly, that is on a statement basis, not for the 
>> complete script.
>
>
> --
> Cecil Westerhof


--

Message: 3
Date: Wed, 30 Aug 2023 00:10:22 +0200
From: Cecil Westerhof 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Why are the priorities of stdout and
stderr the same
Message-ID:

Content-Type: text/plain; charset="utf

Re: [systemd-devel] Additional Locale Variables for Units and Number Format

2023-08-29 Thread Mantas Mikulėnas
It sounds like you're reinventing LC_NUMERIC.

The locale system has a lot more than just LANG; it already allows the
number format to be overridden separately from the "language". Take a look
at `locale -k LC_NUMERIC` and <
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html>.

Adding custom variables would require changing a lot – I guess the main
consumers are libc (Glibc) and libstdc++ (GCC), but of course there are
many places which set the existing LC_* and expect things to change
accordingly, or which might implement the standard interfaces on their own
without using libc.

On Tue, Aug 29, 2023, 20:17 TJ Shipp  wrote:

> I am trying to add in support for a separate variable to change our unit
> system, and having both LANG and UNITS to identify the "locale" of the
> system.
> We are also not only looking for English versus Metric, but are looking
> for mixed units as well (both Imperial and Metric hybrid), as well as
> looking to add number formats (1,000.00 vs 1.000,00)
>
> And what is the best way to add support for a new system environment
> variable such as UNITS?
>
> P.S. If anyone is interested in contracting to do this work, please send
> me a private message outside this list.
>