Re: [Xen-devel] xendomains init script

[Florian Kirstein <xenlist@xxxxxxx>]

Hi,

first: thanks for the nice script :)

I had a (more cosmetic) problem with it:

> The init script is somewhat SUSE-ish, but it should work on LSB
> compliant and on RH based distros as well.
Almost for the LSB-Part: LSB defines that the ini script functions
like "log_success_msg" can be defined as shell aliases:
http://www.linuxbase.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html

The problem with that: shell aliases are usually not enabled in scripts
(so I'll have to blame LSB for allowing this in init script functions)
and the real problem, they are never used (at least for bash) in
if/then/else blocks or functions, which is exactly what your script
does.

So, IF a distribution decides to implement log_success_msg LSB conforming
as alias, as current RedHat distributions (like RHEL4 and including
FC5) do, this will fail and give "log_success_msg: command not found".
I think this is a bad idea (see above), but can't blame RedHat for
following LSB by the word. And as you check for LSB first and then
for redhat, newer redhat distributions will take the LSB case.

I don't think there's a nice way to make this fully LSB compatible
as these funtions are usually called within functions, but I'd
highly suggest to use a "specific before generic" approach for the
"distribution specific emulations". Means: test for the redhat
specific part first and then use LSB. For the LSB part I'd add
an if-test to check if log_success_msg is an alias and use the
generic emulation in case it is (assuming log_error_msg would be an
alias too when log_success_msg is).

I attached a patch doing exactly this, resulting in a clean run on the
redhat based distributions and fixing it for possible others using an
alias in their LSB conformity scripts, leaving it unchanged for the
rest. Hopefully :) 

@Kurt: as this is your init-script, would you like to review the patch
and in case you think it's OK submit it to the official source tree?
Or whoever is responsible for this :)

(:ul8er, r@y

Attachment: init.d-xendomains.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel