Re: 2.1.17 having issue with ExecResult() using pipelines

[christian pearce]

Ghosts maybe, casting aspersions I hope not.

I am attempting to use 2.1.17 and the latest.  And I am running into
issues with these changes.  I am not certain there it happened.  I
have been looking through code to trying an figure it out.

>From what I can tell these two function

ExecResult|ReturnZero(/bin/sh -c "what ever your want") have worked
for quite some time.  And in most cases I want to use my own shell so
I can do things like >/dev/null etc.  (Maybe I can do this with
ExecShellResult result but I don't see any point in adding this since
sh worked great)

As far as the guy with piping problems *shrug* I have piped stuff
before without issue:

cf.portal:    orca_running   = ( ReturnsZero(${sh} -c '${ps} -aef |
grep -v grep | grep ${navigator_home}/orca/bin/orca >/dev/null 2>&1')
cf.portal:                       ReturnsZero(${sh} -c '${ps} -auxwww
2>/dev/null | grep -v grep | grep ${navigator_home}/orca/bin/orca
>/dev/null 2>&1') )

What sucks right now is that I have to change the way I am doing
quotes if I want to make use of the latest cfengine binary for what
ever reason.  And for why I am not certain?  I can't find it in the
code.  I can't find when it changed in the code.  But the following
use to work and now doesn't:

cf.binaries:        getent   = ( ExecResult(/bin/sh -c "PATH=${path}
${which} getent 2>/dev/null || echo \'no getent\'") )

Here is a comparison on the functions debugged:

-ExpandVarstring(/bin/sh -c "PATH=${path} ${which} getent 2>/dev/null
|| echo \'no getent\'")
-ExtractInnerVarString(path} ${which} getent 2>/dev/null || echo \'no
getent\'") - syntax verify
+HandleFunction: ExecResult(/bin/sh -c "PATH=${path} ${which} getent
2>/dev/null || echo \'no getent\'")
+FunctionStringToCode(ExecResult)
+ExpandVarstring(/bin/sh -c PATH=${path} ${which} getent 2>/dev/null
|| echo \'no getent\')
+ExtractInnerVarString(path} ${which} getent 2>/dev/null || echo \'no
getent\') - syntax verify

Notice in the second set of output the quote (") is missing around
PATH and getent\'.

So what I am suppose to do is this:

       at       = ( ExecResult("/bin/sh -c \"PATH=${path} ${which} at
2>/dev/null || echo \'no at\'\"") )

Now what I have is a situation where I am damned if I do and damned if
I don't.  If I upgrade the cfengine my code stops working.  If I
change the code my current cfengine binaries can't handle it.  So I
don't know how to move forward.

Can someone help me find in the code where it changed so I can at
least patch my binaries to remove this?

Why are we breaking the parser so late in the game?  Especially with
the start of Cfengine 3.  Was this change an accident or what it
purposeful?  I did as much reading on this change as I could find.

I would really like to see Cfengine 2 freeze except critical bugs.

On 11/12/05, Mark Burgess <Mark.Burgess@iu.hio.no> wrote:
>
> One of the reasons for the svn repository is so that people can answer
> these questions transparently. I cannot see any changes to relevant code
> between those two versions, so my guess is that you are seeing ghosts as
> a result of other issues.
>
> If there is a problem I will fix it, but casting uncritical aspersions
> just leads to a build up of frustrations in everyone.
>
> M
>
> On Fri, 2005-11-11 at 16:33 -0600, Chip Seraphine wrote:
> > Brendan Strejcek wrote:
> >
> > > You might be able to replace most of the awk '{print $1}'-type calls
> > >
> > >with "cut" invocations:
> > >
> > >    $ cut -d" " -f1 </proc/loadavg
> > >    0.00
> > >
> > >
> >
> > There's various workarounds, but I'm frankly a lot more concerned about
> > the behavior change with respect to quoting (aka bug) between
> > 2.1.15/2.1.16. :)
> >
> >
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-cfengine
>
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
>
>
> Perfect Order has changed its name to Versatile, which more
> correctly represents the combined capabilities of Versatile
> Mobile Systems and Perfect Order.  From the data center to
> users on the move, Versatile turns data into knowledge.
>
> Please visit our new web site at http://www.versatile.com
>


--
Christian Pearce