Maxime Devos <maximede...@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
