Subject: bug#20202: closed (Re: EMACS=t Joy and Happiness)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 26 May 2018 20:55:02 +0000

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 [email-masked].

-- 
20202: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20202
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: EMACS=t Joy and Happiness
From: Paul Eggert <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: Eli Barzilay <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 26 May 2018 13:54:46 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Eli Zaretskii wrote:

> I like it because it is future proof, and makes our burden of
> remembering this issue easier.
> 
> Thanks.

You're welcome. Stefan privately emailed me some helpful comments that improved 
the patch (thanks!), and I installed the attached into master. In the hope that 
this has laid Bug#20202 to rest (at least on modern GNU systems running Bash 4.4 
or later), I'm boldly closing the bug report.
From 6fcab83600317e94ea7b915da7730a8c7e50226d Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Sat, 26 May 2018 13:29:06 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash=20i?=
 =?UTF-8?q?s=204.4=20or=20newer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

(Thanks to Stefan Monnier for improvements to this patch.)
* lisp/term.el (term--bash-needs-EMACS-status): New var.
(term--bash-needs-EMACSp): New function.
(term-exec-1): Use it instead of always setting EMACS.
---
 lisp/term.el | 34 ++++++++++++++++++++++++++++------
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index 017b022..19e68dd 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1489,6 +1489,31 @@ term-termcap-format
   ;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
   "Termcap capabilities supported.")
 
+;; This private hack is for backwards compatibility with Bash 4.3 and earlier.
+;; It can be useful even when running a program other than Bash, as the
+;; program might invoke Bash as an interactive subshell.  See this thread:
+;; https://lists.gnu.org/r/emacs-devel/2018-05/msg00670.html
+;; Remove this hack and its uses once Bash 4.4-or-later is reasonably
+;; universal, because it slows down execution slightly when
+;; term--bash-needs-EMACSp is first called.
+(defvar term--bash-needs-EMACS-status nil
+  "43 if Bash is so old that it needs EMACS set.
+Some other integer if Bash is new or not in use.
+Nil if unknown.")
+(defun term--bash-needs-EMACSp ()
+  "t if Bash is old, nil if it is new or not in use."
+  (eq 43
+      (or term--bash-needs-EMACS-status
+          (setf
+           term--bash-needs-EMACS-status
+           (let ((process-environment
+                  (cons "BASH_ENV" process-environment)))
+             (condition-case nil
+                 (call-process
+                  "bash" nil nil nil "-c"
+                  "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
+               (error 0)))))))
+
 ;; This auxiliary function cranks up the process for term-exec in
 ;; the appropriate environment.
 
@@ -1506,12 +1531,6 @@ term-exec-1
 	   (format term-termcap-format "TERMCAP="
 		   term-term-name term-height term-width)
 
-	   ;; This is for backwards compatibility with Bash 4.3 and earlier.
-	   ;; Remove this hack once Bash 4.4-or-later is common, 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))
@@ -1523,6 +1542,9 @@ term-exec-1
 	;; escape codes, so we need to see the raw output.  We will have to
 	;; do the decoding by hand on the parts that are made of chars.
 	(coding-system-for-read 'binary))
+    (when (term--bash-needs-EMACSp)
+      (push (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
+            process-environment))
     (apply 'start-process name buffer
 	   "/bin/sh" "-c"
 	   (format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
-- 
2.7.4

Subject: 24.3; Comint mode sets a bad $EMACS
From: Eli Barzilay <[email-masked]>
To: [email-masked]
Date: Wed, 25 Mar 2015 17:44:51 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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 <[email-masked]>
  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 <[email-masked]>
  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!