Commands like ls(1) does not emits color sequences in 25.0.50.1

Commands like ls(1) does not emits color sequences in 25.0.50.1

[Dmitry Igrishin]

Hello,

Recently I've build Emacs 25.0.50.1 and noticed that ls(1)
even with --colors=always option does not emits color sequences.
Setting the environment variable XTERM to "ansi" directly from the inferior
shell affects the behavior of ls(1) in this case and ls --colors
works as expected in *shell* buffer. Is it new expected behavior for
comint shell?

To workaround this problem I've tried to add
(setenv "TERM" "ansi") to the init.el, but Emacs resets the TERM
variable to "dumb" upon the startup. Is this expected?

Thanks!

-- 
// Dmitry.

Re: Commands like ls(1) does not emits color sequences in 25.0.50.1

[Random832]

Dmitry Igrishin <dmitigr@gmail.com> writes:

> To workaround this problem I've tried to add
> (setenv "TERM" "ansi") to the init.el, but Emacs resets the TERM
> variable to "dumb" upon the startup. Is this expected?

Yes, it is expected. You can see where it does this in the comint-exec-1
function. You can test for the EMACS environment variable in your shell
(it will be set to "t" if running within emacs) and reset the TERM in
your e.g. bashrc file.

if [ "$TERM" = dumb ] && [ "$EMACS" = t ]; then
        TERM=dumb-emacs-ansi
fi  

I would tend to use a handcrafted terminfo entry (provided below) that
has only the color codes (and bold, italic, underline), and nothing
else, so that full-screen apps don't think they will work. Many
applications (top and vim both do on my machine) will assume they can
anyway, though.

dumb-emacs-ansi|Emacs dumb terminal with ANSI color codes,
	am,
	colors#8, it#8, ncv#13, pairs#64,
	bold=\E[1m, cud1=^J, ht=^I, ind=^J, op=\E[39;49m,
	ritm=\E[23m, rmul=\E[24m, setab=\E[4%p1%dm,
	setaf=\E[3%p1%dm, sgr0=\E[m, sitm=\E[3m, smul=\E[4m,

Note: 'ncv' is set to disallow reverse, blink, and standout, since these
are mapped by default to faces that set the foreground color (C-h v
ansi-color-faces-vector), but also does not provide codes to use them in
the first place - only color, bold, italic, and underline are provided.

I couldn't find any way to actually indicate the behavior that emacs has
when given a backspace or carriage return (it actually deletes
characters, rather than moving backwards to overtype them), so I omitted
these codes. So, in that sense, this entry is even dumber than dumb.

Re: Commands like ls(1) does not emits color sequences in 25.0.50.1

[Dmitry Igrishin]

2015-09-08 0:58 GMT+03:00 Random832 <random832@fastmail.com>:

> Dmitry Igrishin <dmitigr@gmail.com> writes:
>
> > To workaround this problem I've tried to add
> > (setenv "TERM" "ansi") to the init.el, but Emacs resets the TERM
> > variable to "dumb" upon the startup. Is this expected?
>
> Yes, it is expected. You can see where it does this in the comint-exec-1
> function. You can test for the EMACS environment variable in your shell
> (it will be set to "t" if running within emacs) and reset the TERM in
> your e.g. bashrc file.


> if [ "$TERM" = dumb ] && [ "$EMACS" = t ]; then
>         TERM=dumb-emacs-ansi
> fi
>
I see. But in Emacs 25.0.50.1 the $EMACS variable is not intialized,
when running shell, but the INSIDE_EMACS is:
$ env | grep EMACS
INSIDE_EMACS=25.0.50.1,comint

Also I've noticed that exporting COLORTERM with value "dumb"
forces ls(1) to emit color sequences in my case. So, I've added the
following
line to .bashrc:
(echo -n $INSIDE_EMACS | grep comint) > /dev/null && export COLORTERM=dumb

Shrug...


> I would tend to use a handcrafted terminfo entry (provided below) that
> has only the color codes (and bold, italic, underline), and nothing
> else, so that full-screen apps don't think they will work. Many
> applications (top and vim both do on my machine) will assume they can
> anyway, though.
>
> dumb-emacs-ansi|Emacs dumb terminal with ANSI color codes,
>         am,
>         colors#8, it#8, ncv#13, pairs#64,
>         bold=\E[1m, cud1=^J, ht=^I, ind=^J, op=\E[39;49m,
>         ritm=\E[23m, rmul=\E[24m, setab=\E[4%p1%dm,
>         setaf=\E[3%p1%dm, sgr0=\E[m, sitm=\E[3m, smul=\E[4m,
>
> Note: 'ncv' is set to disallow reverse, blink, and standout, since these
> are mapped by default to faces that set the foreground color (C-h v
> ansi-color-faces-vector), but also does not provide codes to use them in
> the first place - only color, bold, italic, and underline are provided.
>
> I couldn't find any way to actually indicate the behavior that emacs has
> when given a backspace or carriage return (it actually deletes
> characters, rather than moving backwards to overtype them), so I omitted
> these codes. So, in that sense, this entry is even dumber than dumb.
>
Thank you! These solution can be useful indeed!



-- 
// Dmitry.

Re: Commands like ls(1) does not emits color sequences in 25.0.50.1

[Stefan Monnier]

>> function.  You can test for the EMACS environment variable in your shell

That's been deprecated for ages.  And that won't work in Emacs-25 any more.
You want to use $INSIDE_EMACS instead (whose value is not just "t", either).


        Stefan

Re: Commands like ls(1) does not emits color sequences in 25.0.50.1

[Random832]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> >> function.  You can test for the EMACS environment variable in your shell
> 
> That's been deprecated for ages.

I don't know how I would have discovered that - there's no documentation for
this function, which I found by searching for "TERM". There's no
documentation of that fact anywhere inside comint.el.

It's mentioned in the manual at
https://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html
, but that page doesn't come up for any reasonable search on how Emacs sets
TERM.

> And that won't work in Emacs-25 any more.
> You want to use $INSIDE_EMACS instead (whose value is not just "t", either).