Similar to PR12580, in effort to internationalize systemtap any remote execution clients should be aware of the I18N variables: setlocale, bindtextdomain, textdomain. As a point of reference, LC values are set in main via the following lines: setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); where PACKAGE and LOCALEDIR are defined in config.
ssh does not pass LC_* / LANG env vars already, so /remote.cxx and runtime/staprun/stapsh.c will need to agree on a protocol extension to pass those environment variables to the remote staprun.
ssh actually can send those automatically, and it's configured for this by default in Fedora's /etc/ssh/ssh_config: > Host * [...] > # Send locale-related environment variables > SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES > SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT > SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE > SendEnv XMODIFIERS So IMO it's reasonable to leave this choice to the system's & user's ssh configs, but we could explicitly add our own "-o SendEnv..." to the ssh command lines to force it. It still may not be a bad idea for stapsh to have an environment command, so we're prepared for other transports. Perhaps just "env VAR coded=20value". That may need some heuristic though to manage stapsh's own I18N initialization.
Aha, in my tests, fedora didn't pass the variables because I don't use the default /etc/ssh*_config files. RHEL6 does the same. I'm good with leaving it to a wiser-than-I sysadmin. Let's close this bug then, unless a better argument is made for environment variable controls.
Closed, pending further motivation...