(Sorry for delay, away on family holiday and other things; back today.)
On Mon, 11 Aug 2008, Lars Marowsky-Bree wrote:
> 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?
Correct. This principle would self-contained (in our context) within
".ocf-shellfuncs.in".
>
> > 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?
No-one is suggesting K&R C!
Most of the above is basically OK with me. We had an earlier discussion a
few weeks ago about this.
I think the general consensus was:
o Recognition that "sh" has a much smaller footprint and code-base than
"bash" (on OSes where those two are different). Hence the KISS principle
for an RA sways gently towards "sh".
o Current Solaris releases have a "bash" package available. (This may
not be installed by default, but it is available as part of Solaris.)
o Permit some RAs to be in "bash" if they wish.
o An RA _must_ have an accurate "#!/bin/xxx" designation. (For instance
if it claims to be "sh" it must not have bashisms.)
The ".ocf-shellfuncs.in" discussion that started this thread is about a
set of library functions, shared by multiple RAs, historical and new,
which may well be in a variety of "sh"-like dialects. So in this
particular case (that is, within this set of library functions), we need
to be Bourne-compliant for the moment. But RAs themselves (callers of
this library) could be "bash", or "ksh" or ...
Of course, if we KNOW that all RAs (both ours and those of end-users) are
entirely (and only) in "bash", then at that point the ".ocf-shellfuncs.in"
library could itself become "bash".
And I think we can easily achieve all the above without (shudder) "ports
maintainers [having to] apply a patch to the code".
Lars, I think we are agreeing!
o Let RAs gently evolve to "bash" if they wish;
o Ensure that an RA's "#!/bin/xxx" is accurate about itself;
o Meanwhile keep ".ocf-shellfuncs.in" itself as "sh".
Agreed?
(That should be OK for Linux and Solaris. What, if any, are the *BSD
aspects?)
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
