The Puppet Labs Issue Tracker has Moved:

Feature #4408

A 'strict' variable mode should be added

Added by Stig Sandbeck Mathisen over 4 years ago. Updated over 2 years ago.

Status:DuplicateStart date:07/30/2010
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:0.25.1 Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


This is an issue reported in the Debian Bug Tracker at [[]].


The puppet manifest language uses empty variables the same way then undefined ones. Many languages, for example perl and sql, have shown in the past that this behaviour produces hard to find errors all over the code. Example: lsb* are undefined if lsb-release is missing. A definition using this needs to explicitely check for the lack of a value. It would be obvious if it bails out on the variable access. This is also different from the behaviour of the templating language, erb bails out on undefined variables.

Related issues

Related to Puppet - Feature #1198: alter parser to throw an error on use of an undefined, un... Accepted
Duplicated by Puppet - Feature #4987: Support for 'strict' mode when evaluating puppet variables Closed 10/12/2010


#1 Updated by James Turnbull over 4 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies

I am pretty much tempted to say WONTFIX here. But Luke?

#2 Updated by Peter Meier over 4 years ago

my 2c: this would break a lot of existing manifests, as they currently assume that an undef variable can be compared with an empty string and actually it was up to 2.6 the only way to do it. In 2.6 we can now compare undef variables to undef, which makes things a bit better and maybe also that change not anymore that necessary?

#3 Updated by Luke Kanies over 4 years ago

Didn’t we already update this to fail if an unset variable is by itself but to use an empty string if it’s quoted in a string?

#4 Updated by Jesse Wolfe over 4 years ago

There’s always the perl, bash, and javascript solution of declaring “use strict”

#5 Updated by donavan m over 4 years ago

+1 for an optional ‘strict’ mode.

I opened/closed 4987 with more details before seeing this.

#6 Updated by Luke Kanies over 4 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from Undefined variable equal to empty to A 'strict' variable mode should be added
  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Luke Kanies)

Is #4987 a duplicate of this?

#7 Updated by Robert Rothenberg almost 3 years ago

I’ve found what seems to be a related issue. The order of setting parameters values seems to be non-determistic, so the following is dangerous:

class foo(
  $prefix  = "/opt/${owner}",
  $etc_dir = "${prefix}/etc"
 ) {

    ensure => directory,
    owner  => $owner,
    group   => $owner,
    mode   => 0660,

Sometimes when it’s run, $etc_dir is instantiated before $prefix, which means it’s equal to “/etc”. Naturally restricting the ownership and permissions to etc will kill a server.

Fortunately, I found this issue while testing Puppet on disposable virtual machines rather than a live server.

Until this issue is fixed, warnings about the non-deterministic behaviour of parameters should be documented.

A related feature request might be to order the setting of parameters by their dependencies on one another.

#8 Updated by Ben Marcotte almost 3 years ago

Robert, that looks exactly like an issue that I submitted as bug #12567. That ticket has been accepted and is targeted to Telly, but I haven’t seen any updates on it for roughly two months. I started watching this ticket since the fallout from that bug is undefined variables, and I most wholeheartedly agree there needs to be some type of mechanism to assert that variables with undefined values cause some type of warning or error, so issues like this can be caught more easily.

#9 Updated by Henrik Lindberg over 2 years ago

This is related to #15329 – Puppet lacks a proper undefined value

#10 Updated by Henrik Lindberg over 2 years ago

This is really about the same problem as reported in #1198 (i.e. flag unknown variables as error).

#11 Updated by Henrik Lindberg over 2 years ago

  • Status changed from Accepted to Duplicate

This is a duplicate of #1198.

Comment 7 in this issue (4408) describes a problem that is by design – it is illegal to reference parameter values, the order of initialization is not defined. Arguably an error message to that effect should be produced instead of silent use of undefined value. That is not however what this issue is about.

Also available in: Atom PDF