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: Christian Pearce
Subject: Re: Feature request: Make undefined variables an error
Date: Wed, 13 Jul 2005 12:04:08 -0400

I agree this should exist.  I have been burned before.  And it is very
difficult to debug.  All that aside there needs to be a parameter to
turn it on or off.  Or a setting inside the code.  I know for a fact I
have bits of code that use $() or ${} that expand in shell.  (At least I
think I do)

I would like to have:

control:

   strict = ( on )

But that won't work in the code because the variable are expanded before
the options are set.

So I made a switch -r which turns strict checking off.  Iadded it to
both cfexecd and cfagent.

I also made the output give the variable name and the line number.

There are a few other goodies in the way of output in cfexecd.

BTW: I think Mark is on holiday.

Can some one test it?


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 -
> _______________________________________________ Help-cfengine mailing list 
> Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
-- 
Christian Pearce
Perfect Order, Inc.
http://www.sysnav.com
http://www.perfectorder.com

Attachment: varcheck.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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