Re: Feature request: Make undefined variables an error

[Mark Burgess]

Cfengine orginally expanded variables at the start, performing all
observations before acting. this has proven to be a bad decision,
for various reasons. Over time, patches have been necessary so that
some expansion is performed later. The situation is now inconsistent.

In cfengine 3, variable expansion will be performed at the last minute.

Mark

On Thu, 2005-07-14 at 10:33 -0400, Christian Pearce wrote:
> 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 -
> > >>    
> > >>
> > 
> >