help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request: Make undefined variables an error


From: Mark Burgess
Subject: Re: Feature request: Make undefined variables an error
Date: Thu, 14 Jul 2005 08:43:12 +0200

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 -





reply via email to

[Prev in Thread] Current Thread [Next in Thread]