[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
varcheck.patch
Description: Text Data
signature.asc
Description: This is a digitally signed message part