(getenv "TERM) always returns "dumb"

(getenv "TERM) always returns "dumb"

[Peter Heslin]

Due to a recent change in startup.el, (getenv "TERM") now always
returns "dumb":

;; Subprocesses of Emacs do not have direct access to the terminal, 
;; so unless told otherwise they should only assume a dumb terminal. 
    (setenv "TERM" "dumb")

So what is now the correct way for an Emacs customization to determine
the original value of this environment variable?

(For another person who was recently bitten by this change, see the
thread in comp.emacs entitled "emacs -nw and 256 colors in xterm".)

Peter

Re: (getenv "TERM) always returns "dumb"

[Andreas Schwab]

Peter Heslin <usenet@heslin.eclipse.co.uk> writes:

> Due to a recent change in startup.el, (getenv "TERM") now always
> returns "dumb":
>
> ;; Subprocesses of Emacs do not have direct access to the terminal, 
> ;; so unless told otherwise they should only assume a dumb terminal. 
>     (setenv "TERM" "dumb")

I think we should revert that change unless Stefan comes up with a better
idea.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: (getenv "TERM) always returns "dumb"

[Stefan]

>> Due to a recent change in startup.el, (getenv "TERM") now always
>> returns "dumb":
>> 
>> ;; Subprocesses of Emacs do not have direct access to the terminal, 
>> ;; so unless told otherwise they should only assume a dumb terminal. 
>> (setenv "TERM" "dumb")

> I think we should revert that change unless Stefan comes up with a better
> idea.

I still think the change is basically right, but I agree that we should
probably revert it since noone seems to have the time or inclination to do
the additional necessary changes (i.e. keep TERM set until after running
the terminal-specific config file and stash the original TERM value
somewhere so that a new `terminal-type' function can return it to code that
needs it).


        Stefan

Re: (getenv "TERM) always returns "dumb"

[Peter Heslin]

On 2004-08-31, Stefan <monnier@iro.umontreal.ca> wrote:
> > I think we should revert that change unless Stefan comes up with a better
> > idea.
> 
>  I still think the change is basically right, but I agree that we should
>  probably revert it since noone seems to have the time or inclination to do
>  the additional necessary changes (i.e. keep TERM set until after running
>  the terminal-specific config file and stash the original TERM value
>  somewhere so that a new `terminal-type' function can return it to code that
>  needs it).

It might be worth looking at the multi-tty branch, to see if it
already provides for such a function.

Peter

Re: (getenv "TERM") always returns "dumb"

[Davis Herring]

> I still think the change is basically right, but I agree that we should
> probably revert it since noone seems to have the time or inclination to do
> the additional necessary changes (i.e. keep TERM set until after running
> the terminal-specific config file and stash the original TERM value
> somewhere so that a new `terminal-type' function can return it to code that
> needs it).

How about a variable `process-terminal-type' (default: "dumb") that is
automatically subbed into `process-environment' when starting a
subprocess?  This would be best done in `child_setup' (callproc.c) like
PWD is now, but it could even be done in Lisp.  Several packages already
do tricks like this (`man.el' let-binds `process-environment' to do
exactly this; `comint.el' let-binds it to a constructed sequence with new
TERM settings), so it shouldn't cause any problems.  However, that would
necessitate a(nother) wrapper layer for `start-process', `call-process',
and `call-process-region'.

On the subject of PWD in callproc.c, why are some environment references 
done with egetenv() and others with plain getenv()?  There are no comments 
describing the inconsistency, and while I can understand wanting the 
"original" value of a variable (particularly in uses where Lisp is not 
aware that the environment is being consulted, so there are no issues of 
surprise), there is not even consistency among the uses of single 
variables (like TMPDIR).

Davis Herring

-- 
This product is sold by volume, not by mass.  If it seems too dense or too 
sparse, it means mass-energy conversion has occurred during shipping.

Re: (getenv "TERM") always returns "dumb"

[Richard Stallman]

    How about a variable `process-terminal-type' (default: "dumb") that is
    automatically subbed into `process-environment' when starting a
    subprocess?

It would be simpler just to revert the change that was already made.
What was the purpose of that change, anyway?  What problem was it
intended to fix?

Re: (getenv "TERM") always returns "dumb"

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> It would be simpler just to revert the change that was already made.
> What was the purpose of that change, anyway?  What problem was it
> intended to fix?

Most processes started from within Emacs do not talk to a smart
terminal, but they believe they do.  Setting $TERM to "dumb" would fix
that; then the processes believe they talk to a dumb terminal.

I had this problem in Tramp.  People were using fancy shell prompts on
the remote systems that were confusing Tramp.  Now Tramp explicitly
sets $TERM to "dumb" before invoking the remote shell, and the remote
shell init files can detect this situation and provide a
Tramp-friendlier prompt in this case.  (And users seem to buy the
argument that it makes no sense to use smart prompts on dumb terminals;-)

So I think it would be good to distinguish between two terminals: one
is the terminal type that Emacs itself is talking to, and the other
one is the terminal type that subprocesses of Emacs are talking to.

A side remark: Emacs running in a window system appears to inherit the
terminal type from the terminal it was started from.  That is, this
Emacs has (getenv "TERM") => "linux" because it was started from
~/.xinitrc, but an Emacs started from an xterm will have (getenv
"TERM") => "xterm".  But in both cases, M-x shell RET provides the
same terminal capabilities.  It does not make sense, IMVHO, that the
shell started from M-x shell RET should behave differently for these
two Emacs instances.

Kai

Re: (getenv "TERM") always returns "dumb"

[Richard Stallman]

    Most processes started from within Emacs do not talk to a smart
    terminal, but they believe they do.

Why do they believe they do?  Is it because the Lisp code that starts
them does not specify "dumb" as the terminal type?
If so, the straightforward solution is to change the Lisp code
that invokes them.

It may seem inelegant, but at least it doesn't cause any problems.

So I have reverted the change.

    A side remark: Emacs running in a window system appears to inherit the
    terminal type from the terminal it was started from.  That is, this
    Emacs has (getenv "TERM") => "linux" because it was started from
    ~/.xinitrc, but an Emacs started from an xterm will have (getenv
    "TERM") => "xterm".  But in both cases, M-x shell RET provides the
    same terminal capabilities.

Yes, and M-x shell (through comint) sets TERM to `dumb' or `emacs'.

Re: (getenv "TERM") always returns "dumb"

[Stefan Monnier]

>     Most processes started from within Emacs do not talk to a smart
>     terminal, but they believe they do.

> Why do they believe they do?  Is it because the Lisp code that starts
> them does not specify "dumb" as the terminal type?
> If so, the straightforward solution is to change the Lisp code
> that invokes them.

Right, but *none* of the subprocesses can talk directly to the terminal on
which Emacs was started, so every single piece of elisp that starts
a process should change the TERM variable.  It seems preferable to change it
once and forall, doesn't it?


        Stefan

Re: (getenv "TERM") always returns "dumb"

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>     Most processes started from within Emacs do not talk to a smart
>>     terminal, but they believe they do.
>
>> Why do they believe they do?  Is it because the Lisp code that starts
>> them does not specify "dumb" as the terminal type?
>> If so, the straightforward solution is to change the Lisp code
>> that invokes them.
>
> Right, but *none* of the subprocesses can talk directly to the terminal on
> which Emacs was started, so every single piece of elisp that starts
> a process should change the TERM variable.  It seems preferable to change it
> once and forall, doesn't it?

If there is a real need to preserve the initial environment, the whole
initial `process-environment' could be copied to some new special
variable.

OTOH, if modifying the TERM variable is only needed for subprocesses,
all low-level functions that invoke subprocesses could append the TERM
variable to `process-environment' locally from some new user option
which specifies additional environment variables for subprocesses, e.g.

(defcustom exec-variables '("TERM=dumb" ...) ...)



BTW, there is one problem in the `setenv' function - it modifies
`process-environment' destructively, and so the global value becomes
modified even for let-bound variables:

(getenv "TERM") -> "dumb"
(let ((process-environment process-environment)) (setenv "TERM" "xterm")) -> "xterm"
(getenv "TERM") -> "xterm"

Of course, `copy-sequence' might be used in this case, but there are
many places in Emacs where the copy is not created for let-bound
`process-environment'.  This is too error-prone.

I think, unless there are reasons not to do so, to replace `setcar'
in `setenv' with code deleting the old element and adding a new one
to the head of the list.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: (getenv "TERM") always returns "dumb"

[Richard Stallman]

    Right, but *none* of the subprocesses can talk directly to the terminal on
    which Emacs was started, so every single piece of elisp that starts
    a process should change the TERM variable.  It seems preferable to change it
    once and forall, doesn't it?

It would be more elegant, but the change causes problems.

Re: (getenv "TERM") always returns "dumb"

[Stefan]

>     Right, but *none* of the subprocesses can talk directly to the
>     terminal on which Emacs was started, so every single piece of elisp
>     that starts a process should change the TERM variable.  It seems
>     preferable to change it once and forall, doesn't it?

> It would be more elegant, but the change causes problems.

Yes, as I said in an ealier email, it needs more work (i.e. stash the
original value and make it available through a new function
`terminal-type'), and as long as noone does it, it's better to revert the
change,


        Stefan