Nicolas Williams wrote:
> On Fri, Sep 21, 2007 at 12:33:34AM +0200, Roland Mainz wrote:
> > I've attached a small toy/demo script called "svcproptree1.ksh.txt"
> > which loads the SMF properly tree into a shell compound variable (a
> > compound variable is a single variable which contains several other
> > variables (the closest equivalent may be |struct| in C/C++, however
> > compound variables go a bit further than that, e.g. some people have
> > interpreted the compound variables as "tree variable")), e.g. $ ksh93
> > svcproptree1.ksh '*' tree # will result in the tree shown in
> > http://opensolaris.pastebin.ca/raw/705213
>
> Very nice!
Do you have any suggestions for improvements ?
> > Would such a thing somehow usefull for the SMF project, for example
> > build a loadable shell function which loads the properties for a
> > specific service as part of the method scripts instead of letting all
> > scripts do "manual" parsing of the SMF properties (e.g. $ ksh93
> > svcproptree1.ksh 'finger' list # loads all properties for the "finger"
> > servce into a "tree" variable and the script could then access the
> > properly "tm_man_in_fingerd/manpath" via
> > manpath="${svc.proptree[network/finger:default/].properties[tm_man_in_fingerd/manpath].value}"
> > (the actual variable path could be shortend via "nameref" usage)) ?
BTW: I forgot to show the "nameref" shortcut:
-- snip --
nameref p=svc.proptree["network/finger:default/"].properties
manpath="${p["tm_man_in_fingerd/manpath"].value}"
inetd_name="${p["inetd/name"].value}"
-- snip --
> I'd like all our method scripts to be ksh93,
Erm, it would require to move ksh93 from the "/usr" filesystem to the
root filesystem... this isn't difficult (from the technical point of
view (and "yes"m this includes even the issues about
backwards-compatibity with existing bourne shell scripts (short: it
works without problems))) but we would need a "good reason" for that.
The original drafts for PSARC 2006/550 proposed to put ksh93 on the root
filesystem (e.g. a 32bit copy of the ksh93 frontend (the frontend is
only a 5k wrapper which calls directly into libshell (which contains the
ksh93 core)) was stored in /sbin/ksh93 and all the ksh93 libraries
(libshell, libcmd, libdll and libast) were put into /lib) but it was
removed because we didn't had any consumers. Putting it back would AFAIK
be easy if someone would say "we need it" and then wave with a sword and
defend the ARC case with sword, teeth, claws and poisonous sting in the
tail...
> yes, this kind of thing is
> very convincing :)
One of the ideas was to have an "unified" way to read the SMF properties
without calling /usr/bin/svcprop for each single property. AFAIK it may
be easier (and maybe faster, too) to dump the matching part of the
property tree into a compound variable in one step and then let the
shell script pick it's consumers.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
