Re: Feature request: Make undefined variables an error

[Eric Sorenson]

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 -

cf-die-on-undef-var.patch
Description: Text document