You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A similar issue has been reported a couple of years ago: #113
But it seems that the problem is still there.
Example:
exec{ 'wrong single quoted string containing a variable':
command => '/bin/bash "/opt/software/software-bin.${SOME_ENVIRONMENT_VARIABLE}/binary do-something"',
}
In this particular case the software has a directory for each version and the current version is stored in a an environment variable.
But the use case is totally irrelevant for this issue.
The reported issue is Single Quoted String Containing Variables.
Yet this should not be triggered, because the whole string is enclosed in single quotes. Therefore we INTENTIONALLY are preventing variable substitution.
If we made a mistake and the intended behavior should have been variable substitution DURING a puppet run and not during bash execution, it should be found by tests and not by linting.
The text was updated successfully, but these errors were encountered:
A similar issue has been reported a couple of years ago: #113
But it seems that the problem is still there.
Example:
In this particular case the software has a directory for each version and the current version is stored in a an environment variable.
But the use case is totally irrelevant for this issue.
The reported issue is
Single Quoted String Containing Variables
.Yet this should not be triggered, because the whole string is enclosed in single quotes. Therefore we INTENTIONALLY are preventing variable substitution.
If we made a mistake and the intended behavior should have been variable substitution DURING a puppet run and not during bash execution, it should be found by tests and not by linting.
The text was updated successfully, but these errors were encountered: