Issue #11860 has been updated by Chris Price.
Considerations: It seems like the main code path in question here is the "execute" method in Puppet::Util. This is currently being called for both intentions (i.e., via the implementation for user 'exec' commands via provider/exec.rb, and directly by several other puppet-owned providers which may have a valid need for forcing the LANG to 'C'). This "execute" method currently *always* sets the LANG to 'C' (at least for posix). 1) Should we create a new (second) "execute" method (e.g. "execute_with_lang" or "execute_for_parsing", or add an additional parameter (with a default value) to the existing method signature. (The additional parameter would be used to indicate whether or not we should override the LANG var.) My inclination is towards the latter. 2) Should this additional functionality / expressiveness when calling the execute method(s) be restricted to LANG? Or provide the ability to override other environment variables as well? If we go with the "additional parameter to the existing 'execute' method" approach, the answer to this question would determine the type of the new parameter. If we're only concerned about LANG, then the new param could simply be a boolean. If we want to allow other environment variables to be overridden, the new parameter might be a map. My inclination is to use a boolean to keep things simple; we'd probably default it to "false", meaning "do not override the LANG var by default". 3) One other option would be to remove the LANG override from the execute method entirely. In this case, we'd need to go find all of the existing providers that are parsing command output and use a "withenv" to wrap the call to "execute"; in this case each provider would be responsible for explicitly requesting that the LANG var be set appropriately. This is probably the cleanest solution as far as the implementation of the "execute" method is concerned, but would result in some duplicate code across the providers and would require a bit more up-front knowledge on the part of a provider developer (i.e. they need to be aware of the LANG issue, and know the correct value to set it to... but this might not be an unreasonable expectation?). Concerns: a) documentation b) ensuring that we don't break existing puppet providers. In any of the solutions above, it seems that the most sane default behavior of the "execute" method should be to *not* override LANG, as this seems like an unexpected side effect. However, that implies that we must find all of the providers that might be depending on that behavior currently and update them to reflect the new solution. I suppose that it might be safer to leave the default behavior as-is (i.e. override LANG by default), and simply change the implementation of the 'exec' provider to explicitly turn this "off". There would be fewer potential unexpected side effects / consequences to this approach, but it feels less "clean" overall... it seems like the contract between the caller and the "execute" method should be that the caller needs to ask for the environment variable to be overridden if it needs it, rather than asking for it to *not* be overridden. feedback welcome, I'll post a final proposed solution after giving it a bit more thought (and hopefully getting some tests working). ---------------------------------------- Bug #11860: Puppet ovewriting the LANG environment variable. https://projects.puppetlabs.com/issues/11860 Author: Marek Marek Status: Accepted Priority: Urgent Assignee: Chris Price Category: exec Target version: Telly Affected Puppet version: 2.7.0 Keywords: Branch: As far as I can see puppet is changing system's LANG environment variable - this causes unexpected bahaviour of applications that use this setting (as LANG is different when you run /etc/init.d/foo stop/start/restart, and different when service is restarted by puppet!). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
