[ClusterLabs] ocf scripts shell and local variables
Vladislav Bogdanov
bubble at hoster-ok.com
Mon Aug 29 20:27:50 UTC 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
>http://clusterlabs.org/mailman/listinfo/users
>
>Project Home: http://www.clusterlabs.org
>Getting started:
>http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>Bugs: http://bugs.clusterlabs.org
Maybe #!/bin/ocfsh symlink provided by resource-agents package?
More information about the Users
mailing list