On 2008-08-07T09:41:25, David Lee <[EMAIL PROTECTED]> wrote:
> var1=XXX
> var2=YYY
>
> my_function() {
> _mf_v1=$1
> _mf_v2=$2
> }
>
> your_function() {
> _yf_v1=$1
> _yf_v2=$2
> }
>
> Pragmatically most sh-programming things are fine with such conventions;
> the quantities of potentially interacting functions are manageable by
> adoption of such conventions.
But we don't have to rewrite the resource agents for this, do we?
> Just to confirm: I'm happy that individual OCFs be 'bash' (so long as
> they say "#!/bin/bash", not "!#/bin/sh"). And they can happily use
> 'local' withing themselves. But what we're talking about here are the
> utility functions shared by all OCFs. So (sadly but realistically) I
> think there has to be an element on 'lowest common denominator' just in
> this particular context.
>
> Does that seem OK?
I'm not sure. The above work-around is too ugly for me to even
contemplate thinking about. If someone wants to port heartbeat to a
system from 1980s, should we go back to K&R C? I think we need to draw a
line somewhere, and this pushes me personally over the edge.
My personal preference in this case would be to leave it to the ports
maintainers. They can require bash or they can apply a patch to the
code; but not all compatibility should live in the main code.
I mean, how many users will we have on Solaris (without bash installed)?
Is that a worthwhile basis to aim for?
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
