[ClusterLabs] ocf scripts shell and local variables

[Lars Ellenberg]

On Mon, Aug 29, 2016 at 04:37:00PM +0200, Dejan Muhamedagic wrote:
> Hi,
> 
> On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
> > I think the main issue is the usage of the "local" operator in ocf*
> > I'm not an expert on this operator (never used!), don't know how hard it is to replace it with a standard version.
> 
> Unfortunately, there's no command defined in POSIX which serves
> the purpose of local, i.e. setting variables' scope. "local" is,
> however, supported in almost all shells (including most versions
> of ksh, but apparently not the one you run) and hence we
> tolerated that in /bin/sh resource agents.

local variables in shell:

  dash (which we probably need to support) knows about "local",
  and as far as I know, nothing else.

  Some versions of dash treat "local a=A b=B"
  different from "local a=A; local b=B;"

  bash knows about typeset (which it considers obsolete),
  declare (which is the replacement for typeset)
  and local (which is mostly, but not completely, identical to declare).

  ksh can do function local variables with "typeset",
  but only in functions defined with the function keyword,
  NOT in functions that are defined with the "name()" syntax.

function definitions in shell:

  ksh treats "function x {}" and "x() {}" differently (see above)
  bash knows both "function name {}" syntax, and "name() { }" syntax,
  and treats them identically,
  but dash only knows "name() {}" syntax. (at least in my version...)

that's all broken.  always was.

The result is that it is not possible to write shell scripts
using functions with local variables that run in
dash, bash and ksh.

And no, I strongly do not think that we should "fall back" to the
"art" of shell syntax and idioms that was force on you by the original"
choose-your-brand-and-year-and-version shell, just because some
"production systems" still have /bin/sh point to whatever it was
their oldest ancestor system shipped with in the 19sixties...

Maybe we should simply put some sanity check into
ony of the first typically sourced helper "include" scripts,
and bail out early with a sane message if it looks like it won't work?

And also package all shell scripts with a shebang of
/opt/bin/bash (or whatever) for non-linux systems?

    Lars