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: Chip Seraphine
Subject: Re: Feature request: Make undefined variables an error
Date: Thu, 14 Jul 2005 09:21:46 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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 -


--

Chip Seraphine
Unix Administrator
TradeLink, LLC
312-264-2048
chip@trdlnk.com






reply via email to

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