Bug#940626: uxterm: please lessen dependency on locales
On Tue, 17 Sep 2019, Thomas Dickey wrote:
> > Please apply the following patch (which is _not_ suitable for
> > upstream as the C.UTF-8 locale is my invention and not shipped
>
> really?
Sure, introduced in eglibc 2.13-1, see #609306 for 240 lynx screen
pages of 113x34 for the discussions around that following my fea‐
ture request for such locale.
> (I forget exactly, but my first sighting of this was from the Cygwin crowd -
> there was a long thread on austin-review a few years later).
After reading your eMail I thought “huh, Cygwin doesn’t have locale
support *at all*” and checked and apparently, they added it in the
1.7 version, which is much more recent (and which I’ve never installed).
> > in all operating systems):
>
> still, a bad idea regarding interoperability (in case one uses ssh,
> passing the locale settings from one machine to another).
I’ve had enough grief with en_US.{utf8,UTF-8} in mksh’s testsuite
to request a C.UTF-8 locale. Considering “most” remote systems are
Debian or comparable¹ nowadays, locales-all is not normally installed
and d-i does not generate the en_US.UTF-8 locale, a switch to C.UTF-8
would actually i̲m̲p̲r̲o̲v̲e̲ this situation.
① Added to Arch Linux in task 59737, Red Hat BZ#902094, Fedora too,
and OpenSuSE also carries it… oh, PEP 538 even talks about the
glibc developers (upstream) “are working towards making the C.UTF-8
locale universally available”… seems my idea gained traction.
And many systems just do a !stristr(setlocale(…), "UTF-8").
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Reply to: