The quote_char is used to quote the entire setting when it is modified
as a result of changes to some subsettings.
For an example let's assume we have a setting of this form:
JAVA_ARGS=-Xmx256m
and we want to add the '-Xms' parameter to the setting, for that purpose
we define a resource like this:
ini_subsetting { '-Xms':
ensure => present,
path => '/some/config/file',
section => '',
setting => 'JAVA_ARGS',
subsetting => '-Xms'
value => '256m',
}
which results into the following setting:
JAVA_ARGS=-Xmx256m -Xms256m
But this is not what we intended - if this setting is read by the bash
shell the '-Xms256m' parameter is interpreted as a command to be
executed rather than a value to be assigned to the JAVA_ARGS variable.
To fix this problem the quote_char parameter was added to the
ini_subsetting resource type, and we'll take advantage of it to fix the
problem in the above example like so:
ini_subsetting { '-Xms':
ensure => present,
path => '/some/config/file',
section => '',
setting => 'JAVA_ARGS',
quote_char => '"',
subsetting => '-Xms'
value => '256m',
}
which will result into:
JAVA_ARGS="-Xmx256m -Xms256m"
which is what we intended.
Our new state variable `@quote_char` was not being initialized
property if you used `ini_subsetting` for a setting that did
not yet exist. This fixes that bug.
Prior to this commit, the `ini_subsetting` type assumed that
all of the settings strings were quoted, and always wrote
out the modified value with double-quotes around it.
This commit adds tests for the case where the original setting
is not quoted, and intelligently writes the modified setting
with the same quote character (or lack thereof) that the
original setting used.
