Re: Feature request: Make undefined variables an error

[Christian Pearce]

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