RE: Improving the handling of system data (env, users, paths, ...)

[Rob Browning]

Maxime Devos <maximedevos@telenet.be> writes:

> I’d rather not. It’s rather stateful and hence non-trivial to compose.
> Also, locale is not only about the encoding of text [file name/env
> encodings/xattr/...], but also about language. Also setting the
> language is excessive in this case.

The proposal would be that you'd only change the "CTYPE" to Latin-1,
it's strictly for the purpose of getting *bytes* since Latin-1 will do
that with no possibility of crashing on unencodable data.

And of course there's no way of knowing what the *real* encoding is
without out of band information.  That's true for getenv, and also true
for say every call to get a user or group name from the system.  Each
user name *could* (but won't, outiside generative testing, you'd hope)
have a different encoding.

> This, OTOH, seems a bit better – ‘with-locale’ is like ‘parameterize’
> and hence pretty composable.  However, it still stuffers from the
> problem that it sets too much (also, there is no such thing as the
> “iso-8859-1” locale?).

Oh, I was just writing pseudo-code, and right, you'd only want to change
the CTYPE for the current purposes, and that's what I'd expect whatever
we end up with to make it easy/efficient/safe to do.

> IIRC, in ISO-88519-1 there is a direct correspondence between bytes and 
> characters
> (and Guile recognises this), so there is no cost beyond mere copying.

While it may change, I believe the current plan is to switch Guile to
UTF-8 internally, which is why I've been including that in
considerations.

> Here is an alternative solution:

Right, there are a lot of options if we're in the market for a "broader"
solution, but my impression was that we aren't right now (see my other
followup message).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4