From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo de Moraes Serpa Subject: Re: [OT] Encoding error when calling a ruby script from Emacs using shell-command Date: Sat, 1 Sep 2012 12:29:26 -0500 Message-ID: References: <7522.1346442688@alphaville> <87d326rylb.fsf@Rainer.invalid> <9439.1346507592@alphaville> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae934098f0df49b04c8a740b9 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7rVh-000242-7M for emacs-orgmode@gnu.org; Sat, 01 Sep 2012 13:29:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T7rVf-0002cD-DX for emacs-orgmode@gnu.org; Sat, 01 Sep 2012 13:29:29 -0400 Received: from mail-iy0-f169.google.com ([209.85.210.169]:46314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T7rVf-0002bF-69 for emacs-orgmode@gnu.org; Sat, 01 Sep 2012 13:29:27 -0400 Received: by iagk10 with SMTP id k10so7260949iag.0 for ; Sat, 01 Sep 2012 10:29:26 -0700 (PDT) In-Reply-To: <9439.1346507592@alphaville> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: Achim Gratz , emacs-orgmode@gnu.org --14dae934098f0df49b04c8a740b9 Content-Type: text/plain; charset=ISO-8859-1 > > This is nonsense, may I suggest you read locale (1p)? If you set > LC_ALL, this overrides the other two settings no matter what they are > set to (and you may prevent some scripts trying to set LC_COLLATE or > something like that from functioning correctly). Unless you really need > such a big hammer, set LANG (this provides the default) and leave it at > that. I had no idea it worked like that. Thanks for the heads up. I don't understand why such a hammer is needed at all It was a simple labor of trial and error. I didn't want to spend more time on it, and since it worked, I left it as is, for now. And in that case, how/why does it work from a terminal? It works fine from the terminal (iTerm/zshell), and after I used setenv before the (shell-command), it worked just like it does from when ran from the terminal. I might get into it and try to figure out why emacs is not inheriting the setting from the shell (I'm using zshell on Mac OSX Lion, and emacs is "(GNU Emacs 23.4.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-01-29 on bob.porkrind.org)". But for now, I'll leave it as is, since it's working as expected. Thanks! - Marcelo. On Sat, Sep 1, 2012 at 8:53 AM, Nick Dokos wrote: > Achim Gratz wrote: > > > Marcelo de Moraes Serpa writes: > > > So, I did this: > > > > > > (defun test () > > > (setenv "LANG" "en_US.UTF-8") > > > (setenv "LC_ALL" "en_US.UTF-8") > > > (setenv "LC_CTYPE" "en_US.UTF-8") > > > (shell-command "/Users/myself/.rvm/bin/rvm ruby-1.9.3-p194 do > > > /usr/bin/rubyscript")) > > > > This is nonsense, may I suggest you read locale (1p)? If you set > > LC_ALL, this overrides the other two settings no matter what they are > > set to (and you may prevent some scripts trying to set LC_COLLATE or > > something like that from functioning correctly). Unless you really need > > such a big hammer, set LANG (this provides the default) and leave it at > > that. > > > > I don't understand why such a hammer is needed at all: if LANG (or > LC_ALL) is set in a login shell[fn:1] and exported, then all child > processes (including emacs and including any shells that emacs spawns) > will inherit the setting. So if setting it as above with setenv > (i.e. modifying the emacs environment and therefore the processes that > emacs spawns) makes a difference, that suggests that it is not set > globally. I doubt that that is a good idea in general. Even if you want > it just in the case of emacs, it's probably better to do the setenv > first thing in .emacs. > > And in that case, how/why does it work from a terminal? > > Nick > > Footnotes: > > [fn:1] Or some equivalent way for a graphical login. > > --14dae934098f0df49b04c8a740b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thi= s is nonsense, may I suggest you read locale (1p)? =A0If you set
LC_ALL, this = overrides the other two settings no matter what they are
set to (and you may prevent = some scripts trying to set LC_COLLATE or
something lik= e that from functioning correctly). =A0Unless you really need
such a big hammer, set = LANG (this provides the default) and leave it at
that.<= /blockquote>

I had no idea it worked like that. Thanks f= or the heads up.=A0

I don't understand why such a hammer is needed at all

It was a simple labor of trial and error. I didn't = want to spend more time on it, and since it worked, I left it as is, for no= w.

And in that case, ho= w/why does it work from a terminal?

It works fine from the terminal (iTerm/zshell), and after I used setenv bef= ore the (shell-command), it worked just like it does from when ran from the= terminal.=A0=A0

I might get into it and try to fi= gure out why emacs is not inheriting the setting from the shell (I'm us= ing zshell on Mac OSX Lion, and emacs is "(GNU Emacs 23.4.1 (x86_64-ap= ple-darwin, NS apple-appkit-1038.36) of 2012-01-29 on bob.porkrind.org)". But for now, I'll leave it = as is, since it's working as expected.

Thanks!

- Marcelo.

On Sat, Sep 1, 2012 at 8:53 AM, Nick Dokos <n= icholas.dokos@hp.com> wrote:
Achim Gratz <Stromeko@nexgo.de> wrote:

> Marcelo de Moraes Serpa writes:
> > So, I did this:
> >
> > (defun test ()
> > =A0(setenv "LANG" "en_US.UTF-8")
> > =A0(setenv "LC_ALL" "en_US.UTF-8")
> > =A0(setenv "LC_CTYPE" "en_US.UTF-8")
> > =A0(shell-command "/Users/myself/.rvm/bin/rvm ruby-1.9.3-p19= 4 do
> > /usr/bin/rubyscript"))
>
> This is nonsense, may I suggest you read locale (1p)? =A0If you set > LC_ALL, this overrides the other two settings no matter what they are<= br> > set to (and you may prevent some scripts trying to set LC_COLLATE or > something like that from functioning correctly). =A0Unless you really = need
> such a big hammer, set LANG (this provides the default) and leave it a= t
> that.
>

I don't understand why such a hammer is needed at all: if LANG (o= r
LC_ALL) is set in a login shell[fn:1] and exported, then all child
processes (including emacs and including any shells that emacs spawns)
will inherit the setting. So if setting it as above with setenv
(i.e. modifying the emacs environment and therefore the processes that
emacs spawns) makes a difference, that suggests that it is not set
globally. I doubt that that is a good idea in general. Even if you want
it just in the case of emacs, it's probably better to do the setenv
first thing in .emacs.

And in that case, how/why does it work from a terminal?

Nick

Footnotes:

[fn:1] Or some equivalent way for a graphical login.


--14dae934098f0df49b04c8a740b9--