bug#19251: 24.4; LANG not applied in shell command

bug#19251: 24.4; LANG not applied in shell command

[Sebastien Vauban]

Hello,

I'm trying to automate the update of some Git project with:

--8<---------------cut here---------------start------------->8---
  (defun config-update ()
    "Update config."
    (interactive)
    (message "Updating config...")
    (cd config--directory)
    (let ((ret (shell-command-to-string "LANG=en_US git pull --rebase")))
      (if (string-match "Already up-to-date." ret)
          (message "Configuration already up-to-date.")
        (princ ret)
        (message "Configuration updated."))))
--8<---------------cut here---------------end--------------->8---

On my machine (Windows 8 with Cygwin), that works as expected.

On one friend's machine (some Linux variant), whatever the answer of
`git pull' (something new or nothing new), he will always have the
impression that the project has just been updated:

  ┌────
  │ Updating config...
  │ La branche courante master est à jour.
  │ 
  │ Configuration updated.
  └────

This is because my function looks for the string "Already up-to-date" in
Git's output, and his output is in French -- while I forced LANG to
en_US.

So, why is LANG not respected in `shell-command-to-string'?

Best regards,
  Seb

-- 
Sebastien Vauban

bug#19251: 24.4; LANG not applied in shell command

[Ivan Shmakov]

>>>>> Sebastien Vauban writes:

[…]

 > This is because my function looks for the string "Already up-to-date"
 > in Git's output, and his output is in French – while I forced LANG to
 > en_US.

 > So, why is LANG not respected in `shell-command-to-string'?

	The LC_ALL environment variable takes precedence over LANG (or
	any other LC_ variables, for that matter.)  Back a decade ago,
	I’ve seen RedHat-derived distributions using LC_ALL (instead of
	LANG) to set the locale, so that could be the issue.

	My suggestion would be to use LC_ALL=C instead of a LANG
	override.

	BTW, on GNU/Linux, the ‘locale’ command helps troubleshooting
	such issues.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19251: 24.4; LANG not applied in shell command

[Sebastien Vauban]

Ivan Shmakov wrote:
>> Sebastien Vauban writes:
>
>> This is because my function looks for the string "Already up-to-date"
>> in Git's output, and his output is in French – while I forced LANG to
>> en_US.
>>
>> So, why is LANG not respected in `shell-command-to-string'?
>
> The LC_ALL environment variable takes precedence over LANG (or
> any other LC_ variables, for that matter.)  Back a decade ago,
> I’ve seen RedHat-derived distributions using LC_ALL (instead of
> LANG) to set the locale, so that could be the issue.
>
> My suggestion would be to use LC_ALL=C instead of a LANG
> override.

I first tried LC_ALL=en_US. No success.

Your suggestion LC_ALL=C did work. Thanks!

(This can be closed -- and Emacs did the right thing btw)

Best regards,
  Seb

-- 
Sebastien Vauban

bug#19251: 24.4; LANG not applied in shell command

[Ivan Shmakov]

tags  19251 + notabug
close 19251
thanks

>>>>> Sebastien Vauban writes:
>>>>> Ivan Shmakov wrote:

[…]

 >> My suggestion would be to use LC_ALL=C instead of a LANG override.

 > I first tried LC_ALL=en_US.  No success.

 > Your suggestion LC_ALL=C did work.  Thanks!

	Setting LC_ALL to en_US requests that specific locale, which may
	or may not be available on the target system.  (E. g., per [1].)
	On the contrary, LC_ALL=C effectively requests any localizations
	to be disabled.

[1] http://manpages.debian.net/cgi-bin/man.cgi?format=html&manpath=testing&sektion=5&query=locale.gen

 > (This can be closed – and Emacs did the right thing btw)

	ACK; closing as ‘notabug’.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A