GNU bug report logs -
#20202
24.3; Comint mode sets a bad $EMACS
Previous Next
Reported by: Eli Barzilay <eli <at> barzilay.org>
Date: Wed, 25 Mar 2015 21:46:02 UTC
Severity: minor
Found in version 24.3
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#20202: 24.3; Comint mode sets a bad $EMACS
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 20202 <at> debbugs.gnu.org.
--
20202: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20202
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> Yeah, that's what I thought. FWIW, to avoid it for now, I've made my
> Emacs set it to "emacs" and it looks like that works fine for builds.
I've just installed the patch below into master, which should fix this
problem,
Stefan
diff --git a/lisp/comint.el b/lisp/comint.el
index 31649ff..2769c87 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -816,8 +816,6 @@ series of processes in the same Comint buffer. The hook
(format "COLUMNS=%d" (window-width)))
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width))))
- (unless (getenv "EMACS")
- (list "EMACS=t"))
(list (format "INSIDE_EMACS=%s,comint" emacs-version))
process-environment))
(default-directory
diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index f59c5fb..3f006e8 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -496,7 +496,6 @@ as given in your `~/.profile'."
(defcustom tramp-remote-process-environment
`("TMOUT=0" "LC_CTYPE=''"
,(format "TERM=%s" tramp-terminal-type)
- "EMACS=t" ;; Deprecated.
,(format "INSIDE_EMACS='%s,tramp:%s'" emacs-version tramp-version)
"CDPATH=" "HISTORY=" "MAIL=" "MAILCHECK=" "MAILPATH=" "PAGER=cat"
"autocorrect=" "correct=")
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 362bbf5..9d36e91 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1666,11 +1666,7 @@ Returns the compilation buffer created."
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:"
(window-width))))
- ;; Set the EMACS variable, but
- ;; don't override users' setting of $EMACS.
- (unless (getenv "EMACS")
- (list "EMACS=t"))
- (list "INSIDE_EMACS=t")
+ (list (format "INSIDE_EMACS=%s,compile" emacs-version))
(copy-sequence process-environment))))
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
diff --git a/lisp/term.el b/lisp/term.el
index 43138fa..4c82986 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1505,11 +1505,6 @@ Using \"emacs\" loses, because bash disables editing if $TERM == emacs.")
(format "TERMINFO=%s" data-directory)
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; We are going to get rid of the binding for EMACS,
- ;; probably in Emacs 23, because it breaks
- ;; `./configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
[Message part 3 (message/rfc822, inline)]
I was surprised to see that compiling some random Emacs code via a
Makefile fails when running inside Emacs with an obscure
/bin/sh: t: command not found
I found this setting in comint.el:
(unless (getenv "EMACS")
(list "EMACS=t"))
And that would obviously break such Makefile uses (and IIUC, $EMACS is
a popular choice for specifying which emacs binary to use).
It looks like this was done in this commit:
commit cfefbbf4404963cdf042fb794e0456503aa8b591
Author: Chong Yidong <cyd <at> stupidchicken.com>
Date: 2006-11-18 21:01:33 +0000
(comint-exec-1): Set EMACS and INSIDE_EMACS to t.
Before this commit, EMACS was set with
(concat "EMACS=" invocation-directory invocation-name)
which doesn't look like a good idea either (if you happen to use some
other Emacs version, you still expect the shell to be a plain shell),
but it at least didn't break it. But this change was done shortly
after:
commit 4b1aaa8b07cf2797b5a57e2a1fd88f3ec0aa41e2
Author: Paul Eggert <eggert <at> twinsun.com>
Date: 2006-09-12 16:43:25 +0000
* etc/NEWS: In terminal-oriented subshells, the EMACS environment
variable now defaults to Emacs's absolute file name, instead of
to "t".
and before that (all the way to the initial comint version in git), it
was always "t". It looks like this was intended as a way to tell if
you're running inside emacs, which was superseded by $INSIDE_EMACS --
misc.texi says
(It also sets the @env{EMACS} environment variable to @code{t}, if
that environment variable is not already defined. However, this
environment variable is deprecated; programs that use it should
switch to using @env{INSIDE_EMACS} instead.)
and the changelog dates this to the same date as the first commit
above.
So, since it has been deprecated for almost 8 years, it looks fine to
remove it. If not, then setting it back to the running Emacs would
work too, but better to not do such an unexpected change, so something
like "EMACS=emacs" is probably going to be unobtrusive.
Or if there's some motivation behind intentionally making it some
string that is not an executable, then "EMACS=some-descriptive-text"
would be better.
As a sidenote, misc/efaq.texi uses $EMACS still. (But for tcsh, so
not that anyone should care...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
This bug report was last modified 7 years and 39 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.