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: Wed, 13 Jul 2005 10:58:32 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

I can understand the desire to avoid gazillions of getopts, but I don't see a good way around it if we are to avoid a behavior change.

I think at the very least a warning should be dumped ("Warning, variable $(foo) not expanded") or whatever, with a switch that enables such warnings to be fatal. (We could probably have a general purpose "Warnings are fatal" option, so that similar changes in the future won't need to further pollute the getoptery.)

Alexander Jolk wrote:

Eric Sorenson wrote:

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?


Well, I actually do rely on it in some way. I often copy: files from my server according to some variable's value. As an example, an X11 driver will be copied to /usr/X11R6/lib/modules/drivers/nvidia_drv.so from $(fileserver)/linux/$(nvdrv)/nvidia_drv.so-$(nvver), where the variable nvver is defined according to which version I want to install on a particular client. Now I simply don't have to worry about this code for any machine that doesn't properly define $(nvver), the copy will just silently fail, but the rest of the config goes on correctly.

Of course, I can work around this particular instance by
AllowRedefinitionOf = ( nvver )
nvver = ( undefined )
classes::
nvver = ( nv7174 )


Alex




--

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






reply via email to

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