Mailing List Archive: Linux-HA: Dev

Cope with empty $RANDOM

Index | Next | Previous | View Threaded

horms at verge

Aug 6, 2008, 3:21 AM

Post #1 of 16 (887 views)
Permalink

Cope with empty $RANDOM

In some environments, such as dash, $RANDOM is empty.
This fixes up the last two references that I could find
in the tree to $RANDOM to make sure they are sensible in
this case.

Signed-off-by: Simon Horman <horms[at]verge.net.au>

Index: heartbeat/resources/OCF/.ocf-shellfuncs.in
===================================================================
--- heartbeat.orig/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:13.000000000 +1000
+++ heartbeat/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:23.000000000 +1000
@@ -58,6 +58,13 @@ ocf_is_root() {
esac
}

+ocf_maybe_random() {
+ local rnd="$RANDOM"
+ # Something sane-ish in case a shell doesn't support $RANDOM
+ [ -n "$rnd" ] || rnd=$$
+ echo $rnd
+}
+
# Portability comments:
# o The following rely on Bourne "sh" pattern-matching, which is usually
# that for filename generation (note: not regexp).
@@ -208,19 +215,15 @@ ocf_pidfile_status() {
}

ocf_take_lock() {
- lockfile=$1
-
- if [ ! -n $RANDOM ]; then
- # Something sane-ish in case a shell doesn't support $RANDOM
- RANDOM=$$
- fi
+ local lockfile=$1
+ local rnd=$(ocf_maybe_random)

- sleep 0.$RANDOM
+ sleep 0.$rnd
while
ocf_pidfile_status $lockfile
do
ocf_log info "Sleeping until $lockfile is released..."
- sleep 0.$RANDOM
+ sleep 0.$rnd
done
echo $$ > $lockfile
}
Index: heartbeat/resources/OCF/EvmsSCC
===================================================================
--- heartbeat.orig/resources/OCF/EvmsSCC 2008-08-06 20:05:13.000000000 +1000
+++ heartbeat/resources/OCF/EvmsSCC 2008-08-06 20:05:23.000000000 +1000
@@ -151,7 +151,7 @@ EvmsSCC_start_notify_common()
while [ -n "$EVMS_OUTPUT" ] ; do
EVMS_OUTPUT=`evms_activate 2>&1`
if [ -n "$EVMS_OUTPUT" ] ; then
- SLEEP_TIME=$(($RANDOM % 40))
+ SLEEP_TIME=$(($(ocf_maybe_random) % 40))
ocf_log info "EvmsSCC: Evms call failed - sleeping for $SLEEP_TIME seconds and then trying again."
sleep $SLEEP_TIME
else
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

t.d.lee at durham

Aug 6, 2008, 6:42 AM

Post #2 of 16 (868 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Wed, 6 Aug 2008, Simon Horman wrote:

> In some environments, such as dash, $RANDOM is empty.
> This fixes up the last two references that I could find
> in the tree to $RANDOM to make sure they are sensible in
> this case.

(Disclaimer: my mind is even less focussed than usual, having had a week's
sick-leave...)

Sounds OK in principle. But a detail:

> --- heartbeat.orig/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:13.000000000 +1000
> +++ heartbeat/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:23.000000000 +1000
> @@ -58,6 +58,13 @@ ocf_is_root() {
> esac
> }
>
> +ocf_maybe_random() {
> + local rnd="$RANDOM"
> [...]

That "local ..." construction: is that a true Bourne feature? In this
"shellfuncs" area, we need to be as portable as possible, avoiding
"bash-isms". (I think we accept that some particular OCFs could well be
"bash" these days, but these utility functions, shared across all OCFs,
need to be Bourne.)

> [...]
> ocf_take_lock() {
> - lockfile=$1
> -
> - if [ ! -n $RANDOM ]; then
> - # Something sane-ish in case a shell doesn't support $RANDOM
> - RANDOM=$$
> - fi
> + local lockfile=$1
> + local rnd=$(ocf_maybe_random)
> [...]

... that "local ..." again.

Hope that helps.

--

: 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[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Aug 6, 2008, 1:32 PM

Post #3 of 16 (862 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

Hi David,

On Wed, Aug 06, 2008 at 02:42:10PM +0100, David Lee wrote:
> On Wed, 6 Aug 2008, Simon Horman wrote:
>
> > In some environments, such as dash, $RANDOM is empty.
> > This fixes up the last two references that I could find
> > in the tree to $RANDOM to make sure they are sensible in
> > this case.
>
> (Disclaimer: my mind is even less focussed than usual, having had a week's
> sick-leave...)
>
> Sounds OK in principle. But a detail:
>
> > --- heartbeat.orig/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:13.000000000 +1000
> > +++ heartbeat/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:23.000000000 +1000
> > @@ -58,6 +58,13 @@ ocf_is_root() {
> > esac
> > }
> >
> > +ocf_maybe_random() {
> > + local rnd="$RANDOM"
> > [...]
>
> That "local ..." construction: is that a true Bourne feature? In this
> "shellfuncs" area, we need to be as portable as possible, avoiding
> "bash-isms". (I think we accept that some particular OCFs could well be
> "bash" these days, but these utility functions, shared across all OCFs,
> need to be Bourne.)
>
>
> > [...]
> > ocf_take_lock() {
> > - lockfile=$1
> > -
> > - if [ ! -n $RANDOM ]; then
> > - # Something sane-ish in case a shell doesn't support $RANDOM
> > - RANDOM=$$
> > - fi
> > + local lockfile=$1
> > + local rnd=$(ocf_maybe_random)
> > [...]
>
> ... that "local ..." again.
>
> Hope that helps.

The "local" keyword is I think in the POSIX standard. Is there a
platform with shell which doesn't comply with the POSIX at least?

Cheers,

Dejan

>
> --
>
> : 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[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

t.d.lee at durham

Aug 7, 2008, 1:41 AM

Post #4 of 16 (850 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Wed, 6 Aug 2008, Dejan Muhamedagic wrote:

> On Wed, Aug 06, 2008 at 02:42:10PM +0100, David Lee wrote:
> > > [...]
> > > + local rnd="$RANDOM"
> > > [...]
> >
> > That "local ..." construction: is that a true Bourne feature? In this
> > "shellfuncs" area, we need to be as portable as possible, avoiding
> > "bash-isms". (I think we accept that some particular OCFs could well be
> > "bash" these days, but these utility functions, shared across all OCFs,
> > need to be Bourne.)
> >
> > [...]
>
> The "local" keyword is I think in the POSIX standard. Is there a
> platform with shell which doesn't comply with the POSIX at least?

Sadly, yes. For instance I have just tested 'sh' on Solaris 8, 9 and 10
(Sun's currently supported releases): 'local' fails on all.

How to progress? Conventions for such local variables (i.e. variables
where the programmer's intention is to limit the scope to the block) to
avoid namespace clashes include using a leading "_" in the name (avoid
clash with 'main script' variables which don't use leading "_") and having
the name somehow reflect the function name (avoid clash amongst different
functions). For instance:

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.

Hope that helps.

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?

Best wishes.

--

: 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[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Aug 7, 2008, 12:40 PM

Post #5 of 16 (851 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Thu, Aug 07, 2008 at 09:41:25AM +0100, David Lee wrote:
> On Wed, 6 Aug 2008, Dejan Muhamedagic wrote:
>
> > On Wed, Aug 06, 2008 at 02:42:10PM +0100, David Lee wrote:
> > > > [...]
> > > > + local rnd="$RANDOM"
> > > > [...]
> > >
> > > That "local ..." construction: is that a true Bourne feature? In this
> > > "shellfuncs" area, we need to be as portable as possible, avoiding
> > > "bash-isms". (I think we accept that some particular OCFs could well be
> > > "bash" these days, but these utility functions, shared across all OCFs,
> > > need to be Bourne.)
> > >
> > > [...]
> >
> > The "local" keyword is I think in the POSIX standard. Is there a
> > platform with shell which doesn't comply with the POSIX at least?
>
> Sadly, yes. For instance I have just tested 'sh' on Solaris 8, 9 and 10
> (Sun's currently supported releases): 'local' fails on all.

Pity.

> How to progress? Conventions for such local variables (i.e. variables
> where the programmer's intention is to limit the scope to the block) to
> avoid namespace clashes include using a leading "_" in the name (avoid
> clash with 'main script' variables which don't use leading "_") and having
> the name somehow reflect the function name (avoid clash amongst different
> functions). For instance:
>
> 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.

Right.

> Hope that helps.
>
> 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?

Of course.

Cheers,

Dejan

> Best wishes.
>
>
> --
>
> : 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[at]lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Aug 11, 2008, 10:20 AM

Post #6 of 16 (802 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On 2008-08-07T09:41:25, David Lee <t.d.lee[at]durham.ac.uk> 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: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

pica1dilly at yahoo

Aug 12, 2008, 2:38 AM

Post #7 of 16 (791 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

Doesn't Solaris have ksh that shares more than 90% in common with bash ?

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

pica1dilly at yahoo

Aug 12, 2008, 3:52 AM

Post #8 of 16 (791 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

> > The "local" keyword is I think in the POSIX standard. Is there a
> > platform with shell which doesn't comply with the POSIX at least?

In posix sh, variables scope is always global.

> Sadly, yes. For instance I have just tested 'sh' on Solaris 8, 9 and 10
> (Sun's currently supported releases): 'local' fails on all.

'local' is bash specific. There is an equivalent in ksh known as 'typeset',
depending on what you specified as your default shell, the one that executes shabadabanged (#!/bin/sh) scripts:

- the old SysVr4 bourne defined as /usr/bin/sh,
- or the ksh88 or ksh93, either defined as /usr/xpg4/bin/sh

The bash like behavior in ksh88 where you would define a local variable in a function like this:

fn_name () {
typeset varname
}

was reverted in ksh93 to posix behavior, generates an error.

To use variable scope in ksh93, you must define your functions like this:

function fn_name () {
typeset varname
}

Thoroughly explained here:

usr/src/lib/libshell/common/COMPATIBILITY says about this issue:
-- snip --
Functions, defined with name() with ksh-93 are compatible with
the POSIX standard, not with ksh-88. No local variables are
permitted, and there is no separate scope. Functions defined
with the function name syntax, maintain compatibility.
This also affects function traces.
-- snip --
(this issue also affects /usr/xpg4/bin/sh in Solaris because it is based
on ksh88).

Or short: If you use function-local variables and "foo()" instead of
"function foo" you'll hit the problem that your variables are no longer
be "local" (and please don't complain... that's defined by the POSIX
shell spec and one of the rare items where even the bash people fully
agree that ksh93 is completely correct).

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

horms at verge

Aug 12, 2008, 4:29 PM

Post #9 of 16 (781 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Wed, Aug 06, 2008 at 10:32:21PM +0200, Dejan Muhamedagic wrote:
> Hi David,
>
> On Wed, Aug 06, 2008 at 02:42:10PM +0100, David Lee wrote:
> > On Wed, 6 Aug 2008, Simon Horman wrote:
> >
> > > In some environments, such as dash, $RANDOM is empty.
> > > This fixes up the last two references that I could find
> > > in the tree to $RANDOM to make sure they are sensible in
> > > this case.
> >
> > (Disclaimer: my mind is even less focussed than usual, having had a week's
> > sick-leave...)
> >
> > Sounds OK in principle. But a detail:
> >
> > > --- heartbeat.orig/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:13.000000000 +1000
> > > +++ heartbeat/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:23.000000000 +1000
> > > @@ -58,6 +58,13 @@ ocf_is_root() {
> > > esac
> > > }
> > >
> > > +ocf_maybe_random() {
> > > + local rnd="$RANDOM"
> > > [...]
> >
> > That "local ..." construction: is that a true Bourne feature? In this
> > "shellfuncs" area, we need to be as portable as possible, avoiding
> > "bash-isms". (I think we accept that some particular OCFs could well be
> > "bash" these days, but these utility functions, shared across all OCFs,
> > need to be Bourne.)
> >
> >
> > > [...]
> > > ocf_take_lock() {
> > > - lockfile=$1
> > > -
> > > - if [ ! -n $RANDOM ]; then
> > > - # Something sane-ish in case a shell doesn't support $RANDOM
> > > - RANDOM=$$
> > > - fi
> > > + local lockfile=$1
> > > + local rnd=$(ocf_maybe_random)
> > > [...]
> >
> > ... that "local ..." again.
> >
> > Hope that helps.
>
> The "local" keyword is I think in the POSIX standard. Is there a
> platform with shell which doesn't comply with the POSIX at least?

Yes, I believe local is POSIX, though I used it in a bashish way :-(

It should be

local blah
blah=foo

not

local blah=foo

I will fix this shortly.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

horms at verge

Aug 12, 2008, 5:19 PM

Post #10 of 16 (779 views)
Permalink

Re: Re: Cope with empty $RANDOM [In reply to]

On Tue, Aug 12, 2008 at 03:52:45AM -0700, Joe Bill wrote:
> > > The "local" keyword is I think in the POSIX standard. Is there a
> > > platform with shell which doesn't comply with the POSIX at least?
>
> In posix sh, variables scope is always global.
>
> > Sadly, yes. For instance I have just tested 'sh' on Solaris 8, 9 and 10
> > (Sun's currently supported releases): 'local' fails on all.
>
> 'local' is bash specific. There is an equivalent in ksh known as 'typeset',
> depending on what you specified as your default shell, the one that executes shabadabanged (#!/bin/sh) scripts:
>
> - the old SysVr4 bourne defined as /usr/bin/sh,
> - or the ksh88 or ksh93, either defined as /usr/xpg4/bin/sh
>
> The bash like behavior in ksh88 where you would define a local variable in a function like this:
>
> fn_name () {
> typeset varname
> }
>
> was reverted in ksh93 to posix behavior, generates an error.
>
> To use variable scope in ksh93, you must define your functions like this:
>
> function fn_name () {
> typeset varname
> }
>
>
> Thoroughly explained here:
>
> usr/src/lib/libshell/common/COMPATIBILITY says about this issue:
> -- snip --
> Functions, defined with name() with ksh-93 are compatible with
> the POSIX standard, not with ksh-88. No local variables are
> permitted, and there is no separate scope. Functions defined
> with the function name syntax, maintain compatibility.
> This also affects function traces.
> -- snip --
> (this issue also affects /usr/xpg4/bin/sh in Solaris because it is based
> on ksh88).
>
> Or short: If you use function-local variables and "foo()" instead of
> "function foo" you'll hit the problem that your variables are no longer
> be "local" (and please don't complain... that's defined by the POSIX
> shell spec and one of the rare items where even the bash people fully
> agree that ksh93 is completely correct).

Hi Joe,

I'm not sure if this is the correct specification, but I've just taken a
quick look over the "Shell & Utilities" volume of "IEEE Std 1003.1, 2004
Edition".

http://www.opengroup.org/austin/papers/posix_faq.html
-> http://www.unix.org/single_unix_specification/

It seems to indicate that the for a function is:

fname() compound-command[io-redirect ...]

It does not seem to make any mention of the function keyword,
which incidentally is not supported by dash, the /bin/sh de jour of
Debian and Ubuntu.

As for local and typedef, neither seem to be mentioned in the
specification - though I'm prepared to accept that I need to look
harder.

If we assume for a moment that they aren't part of the specification,
its probably best just to remove local from our code. I think it is
already used quite sparingly and likely isn't necessary. (Though
personally I feel nauseous about all variables being scoped globally.)
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

horms at verge

Aug 12, 2008, 5:24 PM

Post #11 of 16 (781 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Wed, Aug 13, 2008 at 09:29:47AM +1000, Simon Horman wrote:
> On Wed, Aug 06, 2008 at 10:32:21PM +0200, Dejan Muhamedagic wrote:
> > Hi David,
> >
> > On Wed, Aug 06, 2008 at 02:42:10PM +0100, David Lee wrote:
> > > On Wed, 6 Aug 2008, Simon Horman wrote:
> > >
> > > > In some environments, such as dash, $RANDOM is empty.
> > > > This fixes up the last two references that I could find
> > > > in the tree to $RANDOM to make sure they are sensible in
> > > > this case.
> > >
> > > (Disclaimer: my mind is even less focussed than usual, having had a week's
> > > sick-leave...)
> > >
> > > Sounds OK in principle. But a detail:
> > >
> > > > --- heartbeat.orig/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:13.000000000 +1000
> > > > +++ heartbeat/resources/OCF/.ocf-shellfuncs.in 2008-08-06 20:05:23.000000000 +1000
> > > > @@ -58,6 +58,13 @@ ocf_is_root() {
> > > > esac
> > > > }
> > > >
> > > > +ocf_maybe_random() {
> > > > + local rnd="$RANDOM"
> > > > [...]
> > >
> > > That "local ..." construction: is that a true Bourne feature? In this
> > > "shellfuncs" area, we need to be as portable as possible, avoiding
> > > "bash-isms". (I think we accept that some particular OCFs could well be
> > > "bash" these days, but these utility functions, shared across all OCFs,
> > > need to be Bourne.)
> > >
> > >
> > > > [...]
> > > > ocf_take_lock() {
> > > > - lockfile=$1
> > > > -
> > > > - if [ ! -n $RANDOM ]; then
> > > > - # Something sane-ish in case a shell doesn't support $RANDOM
> > > > - RANDOM=$$
> > > > - fi
> > > > + local lockfile=$1
> > > > + local rnd=$(ocf_maybe_random)
> > > > [...]
> > >
> > > ... that "local ..." again.
> > >
> > > Hope that helps.
> >
> > The "local" keyword is I think in the POSIX standard. Is there a
> > platform with shell which doesn't comply with the POSIX at least?
>
> Yes, I believe local is POSIX, though I used it in a bashish way :-(
>
> It should be
>
> local blah
> blah=foo
>
> not
>
> local blah=foo
>
> I will fix this shortly.

Sorry, I've poked around a bit further and I no longer think that
local is POSIX.

http://marc.info/?l=linux-ha-dev&m=121858676924998&w=2
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

pica1dilly at yahoo

Aug 13, 2008, 2:18 AM

Post #12 of 16 (775 views)
Permalink

Re: Re: Cope with empty $RANDOM [In reply to]

--- On Tue, 8/12/08, Simon Horman <horms[at]verge.net.au> wrote:

> Hi Joe,
>
> I'm not sure if this is the correct specification, but
> I've just taken a > quick look over the "Shell &
> Utilities" volume of "IEEE Std 1003.1, 2004 Edition".
>
> http://www.opengroup.org/austin/papers/posix_faq.html
> -> http://www.unix.org/single_unix_specification/

The website is right.

> It seems to indicate that the for a function is:
>
> fname() compound-command[io-redirect ...]
>
> It does not seem to make any mention of the function
> keyword, which incidentally is not supported by dash,
> the /bin/sh de jour of Debian and Ubuntu.

The 'function' keyword is ksh-93 specific.
It's not posix compatible.

> As for local and typedef, neither seem to be mentioned in
> the specification - though I'm prepared to accept that I
> need to look harder.

Neither 'local', nor 'typeset' are posix.

> If we assume for a moment that they aren't part of the
> specification, its probably best just to remove local
> from our code.

See the post I forwarded, Subj: "variables scoping".

It contains a link to a library of shell scripts to use with a posix sh, and that allows the declaration of variables as local, and function call management functions that include the saving of a pseudo stack to simulate the behavior of local variables.

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

horms at verge

Aug 13, 2008, 6:47 PM

Post #13 of 16 (756 views)
Permalink

Re: Re: Cope with empty $RANDOM [In reply to]

On Wed, Aug 13, 2008 at 02:18:37AM -0700, Joe Bill wrote:
>
>
>
> --- On Tue, 8/12/08, Simon Horman <horms[at]verge.net.au> wrote:
>
> > Hi Joe,
> >
> > I'm not sure if this is the correct specification, but
> > I've just taken a > quick look over the "Shell &
> > Utilities" volume of "IEEE Std 1003.1, 2004 Edition".
> >
> > http://www.opengroup.org/austin/papers/posix_faq.html
> > -> http://www.unix.org/single_unix_specification/
>
> The website is right.

Ok great, I was concerned that somone had slipped something in my drink.

> > It seems to indicate that the for a function is:
> >
> > fname() compound-command[io-redirect ...]
> >
> > It does not seem to make any mention of the function
> > keyword, which incidentally is not supported by dash,
> > the /bin/sh de jour of Debian and Ubuntu.
>
> The 'function' keyword is ksh-93 specific.
> It's not posix compatible.
>
> > As for local and typedef, neither seem to be mentioned in
> > the specification - though I'm prepared to accept that I
> > need to look harder.
>
> Neither 'local', nor 'typeset' are posix.
>
> > If we assume for a moment that they aren't part of the
> > specification, its probably best just to remove local
> > from our code.
>
> See the post I forwarded, Subj: "variables scoping".
>
> It contains a link to a library of shell scripts to use with a posix
> sh, and that allows the declaration of variables as local, and
> function call management functions that include the saving of a pseudo
> stack to simulate the behavior of local variables.

I think that is a nice approach, but I think that is is likely that we
can just get rid of local (I don't think it is used much) and save
ourselves the complexity of draging in that scoping code.

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Aug 16, 2008, 4:16 PM

Post #14 of 16 (704 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On 2008-08-13T10:24:14, Simon Horman <horms[at]verge.net.au> wrote:

> Sorry, I've poked around a bit further and I no longer think that
> local is POSIX.

People should simply chose whatever language it is they want to write
their scripts in and declare that in the #! line, be it bash, sh, ksh,
csh, python, Perl. Problem _solved_. ;-)

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: Linux-HA-Dev[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

t.d.lee at durham

Sep 1, 2008, 7:05 AM

Post #15 of 16 (515 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

(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 <t.d.lee[at]durham.ac.uk> 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[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

t.d.lee at durham

Sep 1, 2008, 7:22 AM

Post #16 of 16 (517 views)
Permalink

Re: Cope with empty $RANDOM [In reply to]

On Sun, 17 Aug 2008, Lars Marowsky-Bree wrote:

> On 2008-08-13T10:24:14, Simon Horman <horms[at]verge.net.au> wrote:
>
> > Sorry, I've poked around a bit further and I no longer think that
> > local is POSIX.
>
> People should simply chose whatever language it is they want to write
> their scripts in and declare that in the #! line, be it bash, sh, ksh,
> csh, python, Perl. Problem _solved_. ;-)

Sounds OK with me. Thanks, Lars.

o If a variant of "sh" (bash, ksh, etc.) the "#!/bin/xxx" should be
an accurate reflection;

o Within a sh-related support library (e.g. ".ocf-shellfuncs.in") we
should keep to pure Bourne;

o Be aware that several commercial OSes may not have certain languages or
shell dialects (for instance, Solaris still doesn't natively have
"python"). And for evolving languages the available version may not be
the lastest (for example Solaris-10:perl 5.8.4; Sol-8:"5.005_03").

Hope that helps.

--

: 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[at]lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com