On 9/21/07, Nicolas Williams <Nicolas.Williams at sun.com> wrote: > 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.
How do you intend to write the value back? You cannot pass arguments to a process which contain invalid byte sequences in the current codeset, thus you can't pass them to svccfg. -- robert neville - it consultant
