[ClusterLabs] ocf scripts shell and local variables

Vladislav Bogdanov bubble at hoster-ok.com
Mon Aug 29 16:27:50 EDT 2016

On August 29, 2016 11:07:39 PM GMT+03:00, Lars Ellenberg <lars.ellenberg at linbit.com> wrote:
>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
>Users mailing list: Users at clusterlabs.org
>Project Home: http://www.clusterlabs.org
>Getting started:
>Bugs: http://bugs.clusterlabs.org

Maybe #!/bin/ocfsh symlink provided by resource-agents package?

More information about the Users mailing list