I think debugging does that now... I suppose there would be a way to add a warning like:
cfengine::/var/cfengine/inputs/cf.binaries:91: Warning: Redefinition of
macro pkill=/bin/false
But I don't understand why some variables are done defined they are
parsed. Maybe this has something to do with:
kill = ( ExecResult('/usr/bin/which kill') )
So the code to do this might be a pain. But I haven't look into it
enough. If it wasn't I suppose we could add the strict setting, but
based on Mark's response it isn't doable.
On Thu, 2005-07-14 at 09:21 -0500, Chip Seraphine wrote:
> Ick.
>
> I'd settle for something as crude as just looking for expanded strings
> that still look like variables and coughing up a warning. That would at
> least let me get some troubleshooting in.
>
>
> Mark Burgess wrote:
>
> >Unfortunately this patch will break variable expansion without a major
> >rewrite (cfengine 3). Sometimes variables are not
> >defined when they are parsed -- and they are then parsed
> >again later. A fatal error is too drastic a response to this.
> >
> >This issue is tied together with lots of others. I don't think we should
> >try a quick fix at this stage.
> >
> >M
> >
> >On Wed, 2005-07-13 at 00:33 -0700, Eric Sorenson wrote:
> >
> >
> >>Tracker ID: [ 1236867 ] Failed variable expansion should be an error
> >>
> >>On Fri, 8 Jul 2005, Chip Seraphine wrote:
> >>
> >>
> >>
> >>>For about the one bajillionth time, I troubleshot a problem in my
> >>>environment
> >>>and it came back to some variable being undefined. Rather than put
> >>>explicit
> >>>tests (strcmps and whatnot) for every variable I ever set, I would be much
> >>>happier if I could pass some sort of switch to cfengine that would cause
> >>>it to
> >>>simply fail with a useful error message whenever a variable went undefined
> >>>rather than handling as a string that happens to begin with '$'. It is far
> >>>safer and more secure to abort than to run commands with garbage inputs....
> >>>
> >>>I'm quite comfortable using $(dollar) when I need to, so I can't think of a
> >>>downside of tis...
> >>>
> >>>
> >>I found where this is happening, and it seems like it'd be easy to
> >>croak on an undefined variable -- A Patch is attached. But I just made
> >>this the default instead of adding YET ANOTHER getopt. This might be
> >>too big of a change, if people are used to this silently succeeding (?!).
> >>
> >>On my test case, before the patch I ended up with a file named
> >>/tmp/$(testvar) which, truly I can't imagine being the desired
> >>behavior. It seems like fixing this would really be a good way to catch
> >>typos and so forth. Does anybody on the list rely on the current behavior?
> >>
> >>Mark, any opinion? Should we croak on the use of an uninitialzed
> >>variable? What was the original reasoning behind passing the variable
> >>through as-is? (in the 'if varstring ...' section deleted in my patch)
> >>
> >>
> >>
> >>--
> >> - Eric Sorenson - N37 17.255 W121 55.738 - http://eric.explosive.net -
> >> - Personal colo with a professional touch - http://www.explosive.net -
> >>
> >>
>
>
--
Christian Pearce
Perfect Order, Inc.
http://www.sysnav.com
http://www.perfectorder.com
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
