[klibc] klibc sh doesn't support switching LC_* during a script/session

[Christoph Anton Mitterer]

Hey Thorsten.

On Tue, 2022-01-25 at 06:05 +0000, Thorsten Glaser wrote:
> It does, but the change must not affect the way the script is
> parsed (interesting requirement…),
Does seem to make sense, it seems.
Just out of curiosity... where does it say that?


> but it only requires support
> for the C locale; klibc can just declare to support only that.

But then it should also be always in C (or perhaps C.UTF-8)... and so
at least the command-substitution-with-trailing-newlines-trick should
be guaranteed to work.


> (mksh does, for POSIX conformance enquiries, it only supports
> the C locale and its UTF-8 mode is an extension.)
> 
> klibc, AFAICT, doesn’t do locales anyway, as it’s a very limited
> execution environment.

But it (klibc sh) does seem to support Unicode (or at least UTF-8)?!

So by that I'd have guessed that the "runtime-switching" of LC_* must
also be supported (which it doesn't), at least for the character
encoding and to switch back to C?

> 

On Tue, 2022-01-25 at 06:19 +0000, Thorsten Glaser wrote:
> Just add a trailing period or slash; POSIX requires them to
> be identically encoded across all supported locales:
> 
>      * The encoded values associated with <period>, <slash>,
> <newline>,
>        and <carriage-return> shall be invariant across all locales
>        supported by the implementation.
> 
> And:
> 
>    […] Likewise, the byte values used to encode <period>, <slash>,
>    <newline>, and <carriage-return> shall not occur as part of any
> other
>    character in any locale.

Interesting... so that (i.e. the 2nd point) should already guarantee
that removing '.' or '/' would always be removed "byte mode" (because
it's not allowed that they're part of any other (multi-byte)
representation in any encoding)...
And because they're also the same encoding in any locale, it's even
guaranteed that "." will look like the same everywhere.

 
> I’ve been using an x myself, but will probably switch to… hmm…
> a period (more flexible to use).

But it should work equally with both...

 
> x=$(somecommand; echo .); x=${x%.}

Are you going to add that to the answers at stackexchange? If not I
could do it... (and give you credit if you desire so).


> (Note the ‘.’ is not a regular expression there.) This will
> result in exactly the output of “somecommand”, truncated at
> the first NUL, if any, with trailing newlines preserved.

But the truncation only because of the variable assignment,... not
because of the substitution, which seems to be free to do as it likes,
when it encounters NUL?!


Thanks,
Chris.