Issue #22097 has been updated by Leonardo Mello.
This was already fixed on github pull request https://github.com/puppetlabs/facter/pull/497 With a long description of why the problem was solved using LC_ALL. lmello commented 17 days ago @daniel-pittman: I had studied it better since your last comment, and figured that the behaviour of the locale is a well established standard on Unix-Like systems, and it is defined in the POSIX Specification as follows: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html Section 8.2 Internationalization Variables "This section describes environment variables that are relevant to the operation of internationalized interfaces described in IEEE Std 1003.1-2001. Users may use the following environment variables to announce specific localization requirements to applications. Applications can retrieve this information using the setlocale() function to initialize the correct behavior of the internationalized interfaces. The descriptions of the internationalization environment variables describe the resulting behavior only when the application locale is initialized in this way. The use of the internationalization variables by utilities described in the Shell and Utilities volume of IEEE Std 1003.1-2001 is described in the ENVIRONMENT VARIABLES section for those utilities in addition to the global effects described in this section. LANG This variable shall determine the locale category for native language, local customs, and coded character set in the absence of the LC_ALL and other LC_* ( LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so on. LC_ALL This variable shall determine the values for all locale categories. The value of the LC_ALL environment variable has precedence over any of the other environment variables starting with LC_ ( LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) and the LANG environment variable. .... " This behaviour is also true on all Unix Like Systems that try to follow the POSIX Standard, I had checked the documentation of Linux (GNU GETTEXT), Oracle Solaris (http://docs.oracle.com/cd/E19253-01/817-2521/overview-39/index.html ), freebsd recommends setting the lang environment variable on documentation (http://www.freebsd.org/doc/handbook/using-localization.html#adm-setup), but the manpage of setlocale on freebsd behaves like posix. There could be programs that does not use setlocale posix function and only check for the value of LANG, because of this it is advise to set LC_ALL AND LANG. After configuring LC_ALL , there is no need to set LC_*, because LC_ALL will override the values of LC_*. The variable LANGUAGE is ignored when LC_ALL is configured and is not defined in posix. http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html I will change this pull request to set LC_ALL and LANG variables, that would solve the problem and will cover both the posix case and the edge cases. ---------------------------------------- Bug #22097: facter should use LC_ALL not LANG when setting the C locale https://projects.puppetlabs.com/issues/22097#change-96287 * Author: Guido Gúnther * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Keywords: * Branch: * Affected Facter version: ---------------------------------------- # LC_MESSAGES=de_DE.UTF-8 LANG=C ifconfig eth0 Link encap:Ethernet Hardware Adresse 52:54:00:0E:3F:E5 inet Adresse:10.174.252.56 Bcast:10.174.255.255 Maske:255.255.252.0 See the Adresse vs. the expected addr, whereas: # LC_MESSAGES=de_DE.UTF-8 LC_ALL=C ifconfig eth0 Link encap:Ethernet HWaddr 52:54:00:0E:3F:E5 inet addr:10.174.252.56 Bcast:10.174.255.255 Mask:255.255.252.0 See http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html Pull request forthcoming. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
