help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "more", "ls -l", and column 80 in shell


From: Peter Dyballa
Subject: Re: "more", "ls -l", and column 80 in shell
Date: Mon, 26 Jun 2006 10:33:43 +0200


Am 26.06.2006 um 02:37 schrieb Miles Bader:

Peter Dyballa <Peter_Dyballa@Web.DE> writes:
I had to prevent the colourising feature, now I actually have to
turn it on actively!  GNU's ls is not that careful -- and it cannot
display UTF-8 characters!

Huh?  Neither of these things seem to be true....

It is true for a *shell* buffer in GNU Emacs 22.0.50: I see ``a<empty
box>´´ instead of ``ä´´, as in dired. In GNU Emacs 23.0.0 it all looks
right.

Sounds like your environment is messed up. What do you have LANG set to?

Yes. It's LANG=de_DE.UTF-8. It's valid in Mac OS X.


Emacs will use LANG to try and set the correct decoding for process
output (look at the mode-line of the *shell* buffer: there should be a
"u:" at the beginning if your system is using utf-8).

I did not succeed to make my *shell* buffers display the u: in the mode-line. The best I can achieve is *scratch* or *Help* with ``u:´´ and this in .emacs (although it might not be necessary, because without this modification *shell* seems to behave the same):

        (modify-coding-system-alist 'process "\\*shell\\*\\'"   'utf-8)


Also I think (but only based on observation) that ls will only output
raw characters if they are valid in the locale named by LANG, and AFAIK,
"valid" means listed in "/etc/locale.gen".


This file was not installed from the Fink package. Strings does not reveal such a string in the GNU ls binary, only /sw/share/locale, where the localised messages are located.


I've also tried to set ``(modify-coding-system-alist 'process "\\*.* output\\*\\'" 'iso-8859-15-unix)´´ (usual TeX is at an 8bit level) to make AUCTeX output readable. The modifications for both get recorded in process-coding-system-alist, but they do not seem to effect more. One thing *is* true: UTF-8 output from commands in *shell* is correctly presented. I cannot say it's a bug, or two, so I stay with it.

--
Greetings

  Pete

Real Time, adj.:
Here and now, as opposed to fake time, which only occurs there and then.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]