On August 29, 2016 11:07:39 PM GMT+03:00, Lars Ellenberg <lars.ellenb...@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@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? _______________________________________________ Users mailing list: Users@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