[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 -