On Fri, Sep 21, 2007 at 06:27:54AM +0200, Roland Mainz wrote: > Nicolas Williams wrote: > > On Fri, Sep 21, 2007 at 03:27:57AM +0200, Roland Mainz wrote: > > > David Powell wrote: > > > > It simply means that if you assume the *parseable* output of this > > > > command is using the caller's encoding and character set, you are > > > > wrong. > > > > > > Erm, my concern is not about "parseable" output. My point is that the > > > output cannot be processed. If you put the into a file and then let the > > > shell read it it may not be able to recover from this kind of error > > > > Stop right there. If you put UTF-8 into a file that will be read > > elsewhere (or even in the same process) in a context where something > > else is expected, well, then you lose. That has nothing to do with > > svcprop. > > If files do not work and shell variables do not work either... who is > actually able to use this interface ? AFAIK there is noone left, right ?
You missed the point. If I have an interface A that produces UTF-8 and an interface B that consumes UTF-8, both regardless of current locale, then I can feed A's output to B. If I have an interface C that consumes only text in the codeset of the current locale then I can use iconv to convert the output of A before feeding it to C. Similarly, if I have an interface D that produces only text in the current locale's codeset then I can use iconv to convert it to UTF-8 prior to feeding it to B. Having interfaces that deal only in UTF-8 regardless of the current locale is NOT a problem. Such interfaces require that their consumers be capable of doing any codeset conversions they might have to. There is a point to such interfaces: avoiding data loss. A's output can be fed to B without codeset conversion, and therefore without any data loss. Interfaces that perform automatic codeset conversion are, of course, friendlier to use, but sometimes you just absolutely need interfaces that don't do that. Nico --
