Quoth Roland Mainz on Fri, Sep 21, 2007 at 12:37:28AM +0200:
> What happens with the value of a "ustring" (I assume this means "unicode
> string", right ?) value in a locale which may not be able to represent
> some characters in that value, e.g. charatcers outside the BMP (Basic
> Multilinguar Plane) when the current shell script runs in ja_JP.PCK ...
> or en_US.ISO8859-1 ?
I can't tell whether this thread came to a resolution or not, so let's
consider use cases. I'll propose one that I think should work, and if
it doesn't, we should file bugs. If other people can think of other use
cases, speak up.
The primary use case I think of for ustring properties is for
translations of strings in the repository, such as the "common name"
descriptions of services. It should be possible for developers to
deliver translated strings, and for a script to access and display them.
Assuming that a developer writes such a manifest by using the loctext
element, svccfg will create a property whose name is the language which
the developer specified. To test this, I modified my cron.xml and added
<loctext xml:lang='es'>
clock daemon (cro??)
</loctext>
to the common_name element. (That's supposed to be Spanish, which
I don't know very well, so I just replaced the 'n' in cron with the
tilde-ed version.) svccfg shows that importing this manifest works:
svc:/system/cron> listprop tm_com*
tm_common_name template
tm_common_name/C ustring "clock daemon (cron)"
tm_common_name/es ustring "clock daemon (cro??)"
Now when a developer's script goes to display the string, it should
retrieve the value of the property named by the user's current language.
svcprop -p tm_common_name/es in this case. For me this results in
wink% svcprop -p tm_common_name/es cron:default
clock\ daemon\ \(cro??\)
So the backslashes need to be stripped out. I believe the shell can do
this, particularly since it should be running in the Spanish locale.
Say, with
svcprop -p tm_common_name/es cron:default | read value v2; echo $value
Does this make sense?
David
