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

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

[RjjdBae]

"ls -l|more" in the shell window omits the <RET> if the <RET> falls on
column 80.
"ls -l" works fine.

Any thoughts on how to get "more" to behave in the shell window?

I've seen this for years and years.

I am
GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2003-02-20 on porky.devel.redhat.com

Regards, Bob

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

[Barry Margolin]

In article <1150411474.595005.130180@p79g2000cwp.googlegroups.com>,
 "RjjdBae" <rjjd@tds.net> wrote:

> "ls -l|more" in the shell window omits the <RET> if the <RET> falls on
> column 80.
> "ls -l" works fine.
> 
> Any thoughts on how to get "more" to behave in the shell window?

Why do you use "more" in a shell window?  "more" requires a video 
terminal (or emulator), and a shell window is not one of these.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

[Tim X]

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <1150411474.595005.130180@p79g2000cwp.googlegroups.com>,
>  "RjjdBae" <rjjd@tds.net> wrote:
>
>> "ls -l|more" in the shell window omits the <RET> if the <RET> falls on
>> column 80.
>> "ls -l" works fine.
>> 
>> Any thoughts on how to get "more" to behave in the shell window?
>
> Why do you use "more" in a shell window?  "more" requires a video 
> terminal (or emulator), and a shell window is not one of these.
>

I wonder why you would use it at all when you could just get a dired
listing - in fact, the main reason I stopped using M-x shell in favor
of M-x eshell was the great ease of running emacs commands from within
the eshell without the need to switch windows to execute dired or find
file etc.

Of course, if you really must use more, I guess M-x term would be a
better solution than M-x shell.


Tim
-- 
tcross (at) rapttech dot com dot au

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

[RjjdBae]

I use "more" in the shell window because I use the shell window, and I
want to pause output conveniently.

The first time I heard of eshell and term is today!  I tried each:
eshell exits when I execute a script that contains an "exit".  term
doesn't pass ^H to emacs.  And eshell didn't get my .cshrc right; some
commands didn't work, e.g. "set".

The only problems I have with shell is this column 80 thing,
current-directory's getting lost, and having to execute "dirs" upon
changing directory from within a script.

So, any thoughts on how I can tell whatever generates the <RET> not to
be afraid to put one in column 80?

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

[Tim X]

"RjjdBae" <rjjd@tds.net> writes:

> I use "more" in the shell window because I use the shell window, and I
> want to pause output conveniently.
>
> The first time I heard of eshell and term is today!  I tried each:
> eshell exits when I execute a script that contains an "exit".  term
> doesn't pass ^H to emacs.  And eshell didn't get my .cshrc right; some
> commands didn't work, e.g. "set".
>
> The only problems I have with shell is this column 80 thing,
> current-directory's getting lost, and having to execute "dirs" upon
> changing directory from within a script.
>
> So, any thoughts on how I can tell whatever generates the <RET> not to
> be afraid to put one in column 80?
>

It is a bit difficult to provide accurate advice here as it isn't
clear exactly what you are trying to do. From what you have outlined,
I also suspect you really need to read the emacs manual and use the
various C-h options to know what the features and limitations are of
the various emacs interfaces tot he underlying OS.

Some basic rules of thumb and advice which I hope will help

1. Don't try to use emacs as if it was equivalent to one of the
   standard shells like bash, tcsh or (gasp) csh. While emacs provides
   various ways of doing interaction at this level, you are much
   better off using equivalent emacs features when possible i.e.
   dired, M-x locate, M-x grep, M-x cd etc. 

2. When using one of emacs' shell interfaces, keep in mind that it is
   often necessary to have some escape key sequence to either access
   shell commands that conflict with normal emacs interpreted commands
   or you need to use an escape sequence within the shell buffer to
   access emacs commands. Also, note that some shell interfaces, like
   M-x term have different operating modes - a line mode and a
   terminal mode.

3. M-x shell is a *very* basic shell interface along the lines of a
   dumb terminal. It is designed for doing very simple quick shell
   level operations. It will not work reliably (if at all) with any
   script or program which relies on the characteristics of more
   intelligent shells that use terminfo/termcap etc. 

4. M-x term is a more sophisticated shell interface that is able to
   handle terminal IO a bit more intelligently. It supports both line
   and character type interaction and can be used to run things like
   top.

5. M-x eshell is a shell written in emacs lisp. It has significant
   limitations over shells like bash, but has the advantage of a
   direct interface into the emacs interpreter. You can easily extend
   eshell with simple elisp functions and have direct access to elisp
   functions from the eshell command line. 

>From your description, I don't really understand what the issue is you
are trying to resolve. I develop quite a lot of scripts under emacs
and don't seem to have the issues you have, but I operate in a
completely different way, so I probably don't trip over the same
limitations you do. 

For example, your description of losing directories when changing
directories within a script has me a bit confused. A script executes
in its own shell - it does inherit various settings and values from
the parent, but when the script completes execution, the subshell it
was executing within will also exit and any variables modified during
the script execution will be lost unless you have used the shells
"export" function and even then, the values may not persist as
exported shell values usually only affect sub-shells and not parent
shells. 

I suspect you may need to re-examine some of your assumptions as well
and verify them correct. It is extremely easy to see a
behavior/problem and convince yourself it is due to one thing when in
fact it is something else. For example, I've not noticed a problem
with executing scripts under eshell that wold cause eshell to exit
just because the sub-shell executing the script exits. However, I have
seen parent shells exit when a sub-shell process exits with a failure
because the shell (talking bash here) has set -e in its configuration. 

I also suspect your conclusion that the problems are due to the script
not being able to execute a newline at column 80 is incorrect. There
is a very slim chance that maybe in your configuration emacs fill mode
may be causing some unexpected behavior, but I strongly doubt it. I
often execute scripts which have lines longer than 80 characters
without any problems at all. However, please note that as we are
talking about emacs, the worlds most configurable and customisable
kitchen sink, its impossible to be certain.

I'd suggest going back to basics and possibly providing more specific
details of what you are attempting to do and the behavior you are
observing. Either someone will recognise the problem and know the
solution or know of a different way of approaching the task which
avoids the problem altogether.

HTH

Tim


-- 
tcross (at) rapttech dot com dot au

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

[Peter Dyballa]

Am 16.06.2006 um 16:42 schrieb RjjdBae:

> I use "more" in the shell window because I use the shell window, and I
> want to pause output conveniently.

Learn to use isearch! In Emacs you can scroll up and down, what not  
every terminal emulation allows. It's inappropriate using more in an  
Emacs shell.

>
> The first time I heard of eshell and term is today!  I tried each:
> eshell exits when I execute a script that contains an "exit".  term
> doesn't pass ^H to emacs.  And eshell didn't get my .cshrc right; some
> commands didn't work, e.g. "set".

Add some if's to .cshrc! This way your eshell can bypass codes that  
only makes sense in an xterm or such.

There is some way to bind the backspace key to the delete-backward- 
char function. I do not know by heart how to.

How is it when your shell scripts exit a particular positive non-zero  
numerical value? The shell script's interpreter usually returns a  
return value of 0 when during execution nothing failed ...

>
> The only problems I have with shell is this column 80 thing,
> current-directory's getting lost, and having to execute "dirs" upon
> changing directory from within a script.

I am using the simple shell in GNU Emacs since decades, because it's  
sufficient for almost all purposes. Its TERM value is dumb and I do  
not have an 80 columns problem, at least I do not use silly utilities  
that can make me aware of such a "restriction." Set up your  
environment correctly! Think of .emacs_<shell interpreter>!

The value of cwd can get lost, I know, this happens to me, too. Do  
you set some cdpath? Do you have directories with non-ASCII  
components in the name? SPACE should work. I think when cwd gets lost  
it has to do with incorrect customisation, but I never tracked this  
down, I either killed the *shell* buffer and created a new one or re- 
launched whole GNU Emacs. With session or desktop the old layout  
buffers are restored ...


It might be useful to use the info function and read a bit about  
shell, term, and eshell.

--
Greetings

   Pete

      _o    o         o   o
    _<<     \\_/\_,   \\_ \\_/\_,
   (*)/(*) (*)   (*) (*) `-    (*)

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

[David Combs]

In article <87slm4p8sx.fsf@tiger.rapttech.com.au>,
Tim X  <timx@nospam.dev.null> wrote:
>...

>Some basic rules of thumb and advice which I hope will help
>
>1. Don't try to use emacs as if it was equivalent to one of the
>   standard shells like bash, tcsh or (gasp) csh. While emacs provides

M-x shell
   (then, in *shell*):
tcsh

Works *absolutely* fine -- ie the same as in a dtterm (no emacs).

(of course, no "more", etc, but grep, find, etc all work
      exactly as expected.  Likewise pushd, popd, dirs, etc.
    (Although from time to time it gets confused, at which
      point you simply do  M-x dirs )

>   various ways of doing interaction at this level, you are much
>   better off using equivalent emacs features when possible i.e.
>   dired, 
      of course (plus with dired-x, too).

M-x locate, M-x grep, M-x cd etc. 
Huh?

About M-x grep, I find it very useful to use normal
   grep/egrep/etc, *with -n*, and on *at least 2 files*
    (eg if just one to be grepped, then append /dev/null to
      get to the 2-or-more-files -- so as to get file-names
      at the left of the grep-output)
   and then, if desired, hack that file to remove lines,
     add marks to certain lines, etc,
   and THEN do M-x grep, and change the offered args to
    "`cat mygrep.out`"


>
>2. When using one of emacs' shell interfaces, keep in mind that it is
>   often necessary to have some escape key sequence to either access
>   shell commands that conflict with normal emacs interpreted commands

I don't understand, so: Please expain, ie show examples where necessary.


>   or you need to use an escape sequence within the shell buffer to
                           HUH?  Explain?

>   access emacs commands. Also, note that some shell interfaces, like
>   M-x term have different operating modes - a line mode and a
>   terminal mode.
>

Thanks!

David

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

[David Combs]

In article <mailman.2970.1150533187.9609.help-gnu-emacs@gnu.org>,
Peter Dyballa  <Peter_Dyballa@Web.DE> wrote:
>
>Am 16.06.2006 um 16:42 schrieb RjjdBae:
>
>> I use "more" in the shell window because I use the shell window, and I
>> want to pause output conveniently.
>
>Learn to use isearch! In Emacs you can scroll up and down, what not  
>every terminal emulation allows. It's inappropriate using more in an  
>Emacs shell.
>
>>
>> The first time I heard of eshell and term is today!  I tried each:
>> eshell exits when I execute a script that contains an "exit".  term
>> doesn't pass ^H to emacs.  And eshell didn't get my .cshrc right; some
>> commands didn't work, e.g. "set".
>
>Add some if's to .cshrc! This way your eshell can bypass codes that  
>only makes sense in an xterm or such.

Examples?  (eg from your .cshrc?)   THANKS


>
>There is some way to bind the backspace key to the delete-backward- 
>char function. I do not know by heart how to.
>
...
>
>The value of cwd can get lost, I know, this happens to me, too. Do  
>you set some cdpath? Do you have directories with non-ASCII  
>components in the name? SPACE should work. I think when cwd gets lost  
>it has to do with incorrect customisation, but I never tracked this  
>down, I either killed the *shell* buffer and created a new one or re- 
>launched whole GNU Emacs. With session or desktop the old layout  
>buffers are restored ...
>

How about a simple "M-x dirs" -- seems to re-sync *shell*
to know where it *really* is.  Works for me.
>

Thanks,

David

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

[Tim X]

dkcombs@panix.com (David Combs) writes:

> In article <87slm4p8sx.fsf@tiger.rapttech.com.au>,
> Tim X  <timx@nospam.dev.null> wrote:
>>...
>
>>Some basic rules of thumb and advice which I hope will help
>>
>>1. Don't try to use emacs as if it was equivalent to one of the
>>   standard shells like bash, tcsh or (gasp) csh. While emacs provides
>
> M-x shell
>    (then, in *shell*):
> tcsh
>
> Works *absolutely* fine -- ie the same as in a dtterm (no emacs).
>
No, its not the same as in a term because it is initialised as a dumb
terminal - i.e. it does not have any concept of a "screen" (rows,
columns). This was the OPs initial problem and why programs like less
don't operate correctly. Also, on most Linux systems, the shell used
will be bash, which has most of the features of tcsh these days, so
little will be gained IMO by running a second shell inside the
original one.



> (of course, no "more", etc, but grep, find, etc all work
>       exactly as expected.  Likewise pushd, popd, dirs, etc.
>     (Although from time to time it gets confused, at which
>       point you simply do  M-x dirs )

This is no different to just M-x shell unless your default shell is a
very old or basic sh or similar. Even then, these commands should
still work fine.

If the shell constantly loses track of directory locations etc, it
might be worth looking at the various variables which are used to
match the commands and which the inferior shell process uses to keep
track of the directory. i.e.

Variables `shell-cd-regexp', `shell-chdrive-regexp', `shell-pushd-regexp'
and `shell-popd-regexp' are used to match their respective commands,
while `shell-pushd-tohome', `shell-pushd-dextract' and `shell-pushd-dunique'
control the behavior of the relevant command.


>>   various ways of doing interaction at this level, you are much
>>   better off using equivalent emacs features when possible i.e.
>>   dired, 
>       of course (plus with dired-x, too).
>
> M-x locate, M-x grep, M-x cd etc. 
> Huh?
>
Not sure what the Huh? refers to. 

> About M-x grep, I find it very useful to use normal
>    grep/egrep/etc, *with -n*, and on *at least 2 files*
>     (eg if just one to be grepped, then append /dev/null to
>       get to the 2-or-more-files -- so as to get file-names
>       at the left of the grep-output)
>    and then, if desired, hack that file to remove lines,
>      add marks to certain lines, etc,
>    and THEN do M-x grep, and change the offered args to
>     "`cat mygrep.out`"

I find using direds facilities makes this very easy.

>
>>
>>2. When using one of emacs' shell interfaces, keep in mind that it is
>>   often necessary to have some escape key sequence to either access
>>   shell commands that conflict with normal emacs interpreted commands
>
> I don't understand, so: Please expain, ie show examples where necessary.
>
>
>>   or you need to use an escape sequence within the shell buffer to
>                            HUH?  Explain?
>

Think about it for a second. Your in M-x shell and you want to
interrupt a process you have started in that shell. Normally, when in
a terminal, you could send a C-c, but within emacs M-x shell, emacs
will grab the first C-c, so you need to send it again. However, in M-x
term, the situation is reversed. You need to send a different prefix
(escape) to access emacs commands that are not part of term mode. 

>>   access emacs commands. Also, note that some shell interfaces, like
>>   M-x term have different operating modes - a line mode and a
>>   terminal mode.
>>
Actually, I should have said a line mode and a character mode.


What I was trying to point out tot he OP is that emacs has at least
three different shell interfaces and they all have their strengths and
weaknesses. Therefore, it is important to know what does what in order
to select the best shell for the job you want to do. For example, the
problem the OP was having with a screen oriented program indicated M-x
term would probably be a better choice than M-x shell, which is good
for simple line oriented programs than don't need the concept of a
screen. Likewise, M-x eshell offers other strengths, such as being
able to execute elisp from the command line and call emacs functions
to operate on the place/directory where you are etc.

Tim
-- 
tcross (at) rapttech dot com dot au

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

[Peter Dyballa]

Am 25.06.2006 um 02:30 schrieb David Combs:

> In article <mailman.2970.1150533187.9609.help-gnu-emacs@gnu.org>,
> Peter Dyballa  <Peter_Dyballa@Web.DE> wrote:
>>
>>>
>>> The first time I heard of eshell and term is today!  I tried each:
>>> eshell exits when I execute a script that contains an "exit".  term
>>> doesn't pass ^H to emacs.  And eshell didn't get my .cshrc right;  
>>> some
>>> commands didn't work, e.g. "set".
>>
>> Add some if's to .cshrc! This way your eshell can bypass codes that
>> only makes sense in an xterm or such.
>
> Examples?  (eg from your .cshrc?)   THANKS

	if ($?TERM) then
	    if (($TERM == xterm) | ($TERM == nxterm)) then
	        setenv TERM	xterm-color
	        setenv TERMCAP	/usr/X11R6/lib/X11/etc/xterm.termcap
	####        tty > /dev/null
	####        if ($status == 0) stty erase '^?'
	    endif
	    if (! $?DISPLAY) setenv DISPLAY :0.0
	    set path=(~/bin $path) #/usr/local/bin /usr/local/teTeX/bin/ 
powerpc-apple-darwin-current)
	    set ignore = (.o a.out)
	    set prompt = "`echo $user` ! /\\ "
	endif

You could also check if $TERM is "emacs" ... If your ls does not  
colourise its output by default, you could switch that on in such a  
clause as above. I have to switch this off in ~/.emacs_tcsh because  
in *shell* buffer I would see a lot of ANSI Esc sequences to switch  
colour or brightness on or off.

>>
>> The value of cwd can get lost, I know, this happens to me, too. Do
>> you set some cdpath? Do you have directories with non-ASCII
>> components in the name? SPACE should work. I think when cwd gets lost
>> it has to do with incorrect customisation, but I never tracked this
>> down, I either killed the *shell* buffer and created a new one or re-
>> launched whole GNU Emacs. With session or desktop the old layout
>> buffers are restored ...
>>
>
> How about a simple "M-x dirs" -- seems to re-sync *shell*
> to know where it *really* is.  Works for me.

Whenever this happened M-x dirs did not always cure it. Changing  
working directory and returning could make GNU Emacs forget about the  
current working directory. It did not happen this year, and I have to  
admit that I am working in unstable Emacsen. This might explain my  
failures.

--
Greetings

   Pete

“One cannot live by television, video games, top ten CDs, and dumb  
movies alone”
       (Amiri Baraka 1999)

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

[Peter Dyballa]

Am 25.06.2006 um 04:39 schrieb Tim X:

> Variables `shell-cd-regexp', `shell-chdrive-regexp', `shell-pushd- 
> regexp'
> and `shell-popd-regexp' are used to match their respective commands,
> while `shell-pushd-tohome', `shell-pushd-dextract' and `shell-pushd- 
> dunique'
> control the behavior of the relevant command.

I had `shell-pushd-regexp' set incorrectly for some time. It was  
corrected in last year's summer with the help of members of this  
list. In the end it could have been that really all occasions *shell*  
lost track of the directories I've visited was caused by my fault.  
This year nothing got lost yet ...

--
Greetings

   Pete

Make it simple, as simple as possible but no simpler.
                               Albert Einstein

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

[Tim X]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:



> You could also check if $TERM is "emacs" ... If your ls does not
> colourise its output by default, you could switch that on in such a
> clause as above. I have to switch this off in ~/.emacs_tcsh because
> in *shell* buffer I would see a lot of ANSI Esc sequences to switch
> colour or brightness on or off.
>

You can get the colour version of ls to work using the various
ansi-color-* functions and variables built into emacs. Try an apropos
for ansi.

I have also noticed there seems to be quite a few systems which have
the ls --color= option set "oddly" - the gnu version of lis has a
number of options for preventing colour escape codes being used if the
output is either a dumb terminal or it is being redirected to some
other device/file - this makes it easy to pipe ls output into other
programs and avoid issues from weird escape sequences etc.

Tim

-- 
tcross (at) rapttech dot com dot au

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

[Peter Dyballa]

Am 25.06.2006 um 11:42 schrieb Tim X:

> I have also noticed there seems to be quite a few systems which have
> the ls --color= option set "oddly" - the gnu version of lis has a
> number of options for preventing colour escape codes being used if the
> output is either a dumb terminal or it is being redirected to some
> other device/file - this makes it easy to pipe ls output into other
> programs and avoid issues from weird escape sequences etc.

I think the ls command in Apple's Mac OS X 10.4 (Tiger) is even  
better: it "knows" which terminals can set colours! Until Panther  
(Mac OS X 10.3) 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! GNU ls cannot be recommended.

(ansi-color-for-comint-mode-on) should be OK for modern Emacsen to  
allow the translation of ANSI codes into "SGR control sequences of  
comint output into text-properties" -- I think only the CVS versions  
offer this feature, for stable GNU Emacs 21.4 it was not included.

--
Greetings

   Pete

      _o    o         o   o
    _<<     \\_/\_,   \\_ \\_/\_,
   (*)/(*) (*)   (*) (*) `-    (*)

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

[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....

ls doesn't emit codes for "color"  unless you use the --color option.

ls obviously doesn't "display" anything; it does however, pass-through
utf8 characters just fine for your terminal (or Emacs) to display
(I just tested it by creating a file with a utf8 name -- it displayed
correctly in Emacs dired, M-x shell, and gnome-terminal).

[This is "ls (GNU coreutils) 5.96" ... Apple has a bit of a reputation
for using long out-of-date versions of things like that, so who knows
what they're including in osx...]

-miles
-- 
"An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god.  He only has to be someone who believes that the evidence
on the God question is at a similar level to the evidence on the werewolf
question."  [John McCarthy]

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

[Peter Dyballa]

Am 25.06.2006 um 23:44 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.


> [This is "ls (GNU coreutils) 5.96" ... Apple has a bit of a reputation
> for using long out-of-date versions of things like that, so who knows
> what they're including in osx...]
>

	ls (GNU coreutils) 5.94, from Fink distribution.

In Apple's ls I found with strings:

	$FreeBSD: src/bin/ls/cmp.c,v 1.12 2002/06/30 05:13:54 obrien Exp $
	$FreeBSD: src/bin/ls/ls.c,v 1.66 2002/09/21 01:28:36 wollman Exp $
	$FreeBSD: src/bin/ls/print.c,v 1.57 2002/08/29 14:29:09 keramida Exp $
	$FreeBSD: src/bin/ls/util.c,v 1.30 2002/06/30 05:13:54 obrien Exp $
	@(#)PROGRAM:ls  PROJECT:file_cmds-116.9  DEVELOPER:root  BUILT:Mon  
Mar 21 14:49:18 PST 2005

This old software does a better job in GNU Emacs 22.0.50's *shell*  
buffer.

--
Greetings

   Pete

“Computers are good at following instructions, but not at reading  
your mind.”
    - D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

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

[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?

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).

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".

[ I have: LANG="ja_JP.UTF-8" ]

I'm using Emacs 22.0.50 (of a week or so ago) too.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

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

[Peter Dyballa]

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.