Menu
▾
▴
gnuplot-bugs
|
From: <Don...@st...> - 2006-09-11 03:47:37
|
I like to do my builds of almost anything from source under emacs Shell mode. But emacs Shell mode sets the environment variable EMACS to "t". This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...) to set EMACS="t", with the result that in any Makefile generated from EMACS = @EMACS@ in Makefile.in end up with the makefile variable EMACS set to "t". One example where this is a problem is the current (Sept 10) CVS version of gnuplot. It's not clear to me who should change: autoconf, emacs, developers using emacs as a built tool, or users like me. If it's one of the latter two, a warning would be nice. Perhaps the simplest solution would be for emacs Shell to either not set EMACS or set it to "emacs". emacs version: 21.3.1 autoconf version: 2.60 m4 version: 1.4.6 system: fedora core 1 gnu/linux |
|
From: Paul E. <eg...@CS...> - 2006-09-11 17:43:20
|
<Don...@st...> writes:
> I like to do my builds of almost anything from source under emacs Shell
> mode. But emacs Shell mode sets the environment variable EMACS to
> "t". This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...)
> to set EMACS="t", with the result that in any Makefile generated from
> EMACS = @EMACS@ in Makefile.in end up with the makefile variable EMACS
> set to "t".
>
> One example where this is a problem is the current (Sept 10) CVS
> version of gnuplot.
>
> It's not clear to me who should change: autoconf, emacs, developers
> using emacs as a built tool, or users like me. If it's one of the
> latter two, a warning would be nice. Perhaps the simplest solution
> would be for emacs Shell to either not set EMACS or set it to "emacs".
>
> emacs version: 21.3.1
> autoconf version: 2.60
> m4 version: 1.4.6
> system: fedora core 1 gnu/linux
Thanks for your bug report. Other people have run into this problem
as well, but I don't know of any fix for it yet. I like the simple
solution you suggested, but I think it'd be slightly better if EMACS
is set to Emacs's absolute file name, as that is less likely to cause
confusion later. Here is a proposed patch to CVS Emacs to implement
this.
2006-09-11 Paul Eggert <eg...@cs...>
* make-dist (EMACS): Exit and fail if the EMACS environment
variable is set to something other than an absolute file name.
* etc/NEWS: In terminal-oriented subshells, the EMACS environment
variable now defaults to Emacs's absolute file name, instead of
to "t".
* etc/PROBLEMS: Adjust tcsh advice for this.
* lisp/comint.el (comint-exec-1): Set EMACS to the full name of Emacs,
not to "t".
* lisp/progmodes/compile.el (compilation-start): Likewise.
* man/faq.texi (Escape sequences in shell output): EMACS is now set
to Emacs's absolute file name, not to "t".
(^M in the shell buffer): Likewise.
* man/misc.texi (Interactive Shell): Likewise.
Index: make-dist
===================================================================
RCS file: /cvsroot/emacs/emacs/make-dist,v
retrieving revision 1.221
diff -p -c -b -w -r1.221 make-dist
*** make-dist 5 Jul 2006 06:42:27 -0000 1.221
--- make-dist 11 Sep 2006 17:33:22 -0000
*************** if [ ! -d src -o ! -f src/lisp.h -o ! -d
*** 120,127 ****
fi
### Find where to run Emacs.
! ### (We don't accept EMACS=t as an answer, since that probably only means
! ### that the shell is running in an Emacs window.)
if [ $update = yes ];
then
unset EMACS_UNIBYTE
--- 120,126 ----
fi
### Find where to run Emacs.
! ### (Accept only absolute file names.)
if [ $update = yes ];
then
unset EMACS_UNIBYTE
*************** then
*** 129,139 ****
then
EMACS=`pwd`/src/emacs
else
! if [ "x$EMACS" = "x" -o "x$EMACS" = "xt" ];
! then
! echo You must specify the EMACS environment variable 2>&1
exit 1
! fi
fi
fi
--- 128,142 ----
then
EMACS=`pwd`/src/emacs
else
! case $EMACS in
! /*) ;;
! *)
! if [ ! -f "$EMACS" ]; then
! echo "$0: You must specify the EMACS environment variable " \
! "to an absolute file name." 2>&1
exit 1
! fi;;
! esac
fi
fi
Index: etc/NEWS
===================================================================
RCS file: /cvsroot/emacs/emacs/etc/NEWS,v
retrieving revision 1.1393
diff -p -c -b -w -r1.1393 NEWS
*** etc/NEWS 10 Sep 2006 13:48:42 -0000 1.1393
--- etc/NEWS 11 Sep 2006 17:33:22 -0000
*************** otherwise behaves quite similarly to the
*** 1434,1439 ****
--- 1434,1443 ----
`comint-use-prompt-regexp'. The old name has been kept as an alias,
but declared obsolete.
+ +++
+ *** The EMACS environment variable now defaults to Emacs's absolute
+ file name, instead of to "t".
+
** M-x Compile changes:
---
*************** it doesn't scroll the compilation output
*** 1490,1495 ****
--- 1494,1503 ----
no arrow is displayed and a value of nil means display the message at the top
of the window.
+ +++
+ *** The EMACS environment variable now defaults to Emacs's absolute
+ file name, instead of to "t".
+
** Occur mode changes:
+++
Index: etc/PROBLEMS
===================================================================
RCS file: /cvsroot/emacs/emacs/etc/PROBLEMS,v
retrieving revision 1.196
diff -p -c -b -w -r1.196 PROBLEMS
*** etc/PROBLEMS 10 Sep 2006 12:28:28 -0000 1.196
--- etc/PROBLEMS 11 Sep 2006 17:33:23 -0000
*************** on the flag to output ^M at the end of e
*** 540,546 ****
problem by adding this to your .cshrc file:
if ($?EMACS) then
! if ($EMACS == "t") then
unset edit
stty -icrnl -onlcr -echo susp ^Z
endif
--- 540,546 ----
problem by adding this to your .cshrc file:
if ($?EMACS) then
! if ("$EMACS" =~ /*) then
unset edit
stty -icrnl -onlcr -echo susp ^Z
endif
Index: lisp/comint.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/comint.el,v
retrieving revision 1.346
diff -p -c -b -w -r1.346 comint.el
*** lisp/comint.el 2 Jun 2006 02:04:15 -0000 1.346
--- lisp/comint.el 11 Sep 2006 17:33:24 -0000
*************** buffer. The hook `comint-exec-hook' is
*** 765,771 ****
(format "COLUMNS=%d" (window-width)))
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width))))
! (if (getenv "EMACS") nil (list "EMACS=t"))
process-environment))
(default-directory
(if (file-accessible-directory-p default-directory)
--- 765,772 ----
(format "COLUMNS=%d" (window-width)))
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width))))
! (unless (getenv "EMACS")
! (list (concat "EMACS=" invocation-directory invocation-name)))
process-environment))
(default-directory
(if (file-accessible-directory-p default-directory)
Index: lisp/progmodes/compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.405
diff -p -c -b -w -r1.405 compile.el
*** lisp/progmodes/compile.el 5 Sep 2006 14:53:24 -0000 1.405
--- lisp/progmodes/compile.el 11 Sep 2006 17:33:24 -0000
*************** Returns the compilation buffer created."
*** 1068,1074 ****
(window-width))))
;; Set the EMACS variable, but
;; don't override users' setting of $EMACS.
! (unless (getenv "EMACS") '("EMACS=t"))
(copy-sequence process-environment))))
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
--- 1068,1075 ----
(window-width))))
;; Set the EMACS variable, but
;; don't override users' setting of $EMACS.
! (unless (getenv "EMACS")
! (list (concat "EMACS=" invocation-directory invocation-name)))
(copy-sequence process-environment))))
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
Index: man/faq.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/faq.texi,v
retrieving revision 1.97
diff -p -c -r1.97 faq.texi
*** man/faq.texi 12 Aug 2006 14:13:31 -0000 1.97
--- man/faq.texi 11 Sep 2006 17:40:32 -0000
*************** shell init file. You have two alternati
*** 2683,2689 ****
@item
Make the alias conditioned on the @code{EMACS} variable in the
environment. When Emacs runs a subsidiary shell, it exports the
! @code{EMACS} variable with the value @code{t} to that shell. You can
unalias @code{ls} when that happens, thus limiting the alias to your
interactive sessions.
--- 2683,2690 ----
@item
Make the alias conditioned on the @code{EMACS} variable in the
environment. When Emacs runs a subsidiary shell, it exports the
! @code{EMACS} variable to that shell, with value equal to the absolute
! file name of Emacs. You can
unalias @code{ls} when that happens, thus limiting the alias to your
interactive sessions.
*************** file:
*** 2753,2759 ****
@example
if ($?EMACS) then
! if ("$EMACS" == t) then
if ($?tcsh) unset edit
stty nl
endif
--- 2754,2760 ----
@example
if ($?EMACS) then
! if ("$EMACS" =~ /*) then
if ($?tcsh) unset edit
stty nl
endif
Index: man/misc.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/misc.texi,v
retrieving revision 1.92
diff -p -c -b -w -r1.92 misc.texi
*** man/misc.texi 16 Aug 2006 05:14:31 -0000 1.92
--- man/misc.texi 11 Sep 2006 17:33:25 -0000
*************** Coding}.
*** 488,494 ****
@cindex @env{EMACS} environment variable
Unless the environment variable @env{EMACS} is already defined,
! Emacs defines it in the subshell, with value @code{t}. A shell script
can check this variable to determine whether it has been run from an
Emacs subshell.
--- 488,495 ----
@cindex @env{EMACS} environment variable
Unless the environment variable @env{EMACS} is already defined,
! Emacs defines it in the subshell, with value equal to Emacs's absolute
! file name. A shell script
can check this variable to determine whether it has been run from an
Emacs subshell.
|
|
From: Chet R. <che...@ca...> - 2006-09-11 20:59:57
|
> For a short-term correction, I think the easiest way is to change > Autoconf to ignore a value of `t' for this environment variable. > Autoconf maintainers, what do you think? > > For longer term, perhaps the best thing is to change Emacs to use a > different environment variable. Alas, I don't remember what software > checks that environment variable, or the motive for binding it. > > Is it Bash? I have cc'd the Bash maintainer so he can answer. Bash does inspect the EMACS environment variable as part of checking whether or not to turn off line editing even when the shell is interactive. It also checks for TERM==emacs. If the shell discovers it's running in an emacs buffer, it turns off readline. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU ch...@ca... http://tiswww.tis.case.edu/~chet/ |
|
From: <Don...@st...> - 2006-09-11 21:41:39
|
>>>>> "Chet" == Chet Ramey <che...@ca...> writes:
Chet> Bash does inspect the EMACS environment variable as part of
Chet> checking whether or not to turn off line editing even when
Chet> the shell is interactive. It also checks for TERM==emacs.
Chet> If the shell discovers it's running in an emacs buffer, it
Chet> turns off readline.
Maybe emacs should be in charge of turning readline off directly
instead expecting the shell to check envars to deal with special
cases. For example, emacs could send the shell something like "shopt
-u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone.
It might also be a good idea for AC_CHECK_COMMAND to at least give a
warning if shell variables have crazy-seeming values like "t", "0" or
"1". Better yet, when envars try to override command names it could
check whether the the command really exists. Or,
PROG=enval AC_CHECK_COMMAND(PROG, foo bar ...)
--> AC_CHECK_COMMAND(PROG, enval foo bar ...)
-Don
|
|
From: Richard S. <rm...@gn...> - 2006-09-11 19:58:01
|
I like to do my builds of almost anything from source under emacs Shell
mode. But emacs Shell mode sets the environment variable EMACS to
"t".
This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...)
to set EMACS="t", with the result that in any Makefile generated from
EMACS = @EMACS@ in Makefile.in end up with the makefile variable EMACS
set to "t".
One example where this is a problem is the current (Sept 10) CVS
version of gnuplot.
For a short-term correction, I think the easiest way is to change
Autoconf to ignore a value of `t' for this environment variable.
Autoconf maintainers, what do you think?
For longer term, perhaps the best thing is to change Emacs to use a
different environment variable. Alas, I don't remember what software
checks that environment variable, or the motive for binding it.
Is it Bash? I have cc'd the Bash maintainer so he can answer.
|
|
From: <Don...@st...> - 2006-09-11 21:10:56
|
>>>>> "rms" == Richard Stallman <rm...@gn...> writes:
rms> For a short-term correction, I think the easiest way is to
rms> change Autoconf to ignore a value of `t' for this environment
rms> variable. Autoconf maintainers, what do you think?
rms> For longer term, perhaps the best thing is to change Emacs to
rms> use a different environment variable. Alas, I don't remember
rms> what software checks that environment variable, or the motive
rms> for binding it.
rms> Is it Bash? I have cc'd the Bash maintainer so he can
rms> answer.
Yes, I think that's it. From the bash info pages:
`EMACS'
If Bash finds this variable in the environment when the shell
starts with value `t', it assumes that the shell is running in an
emacs shell buffer and disables line editing.
-Don
|
|
From: Richard S. <rm...@gn...> - 2006-09-12 15:28:09
|
Your fix is very clever, and I think it is a feature that running configure scripts in a shell under Emacs uses the same Emacs. So please install your change, and we can consider the problem fully solved. |
|
From: Miles B. <mi...@gn...> - 2006-09-13 13:58:42
|
<Don...@st...> writes: >For example, emacs could send the shell something like "shopt > -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone. Stuffing input to a subshell like that is in general not something you can do reliably. -miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde |
|
From: Chet R. <che...@ca...> - 2006-09-13 17:14:21
|
> <Don...@st...> writes: > >For example, emacs could send the shell something like "shopt > > -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone. > > Stuffing input to a subshell like that is in general not something you > can do reliably. Yeah, that's dicy, but you don't have to do it. Just invoke the shell with the `--noediting' option. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU ch...@ca... http://tiswww.tis.case.edu/~chet/ |
|
From: <no...@cu...> - 2006-09-13 22:12:09
|
Chet Ramey <che...@ca...> writes: >> <Don...@st...> writes: >> >For example, emacs could send the shell something like "shopt >> > -u -o emacs; shopt -u -o vi". Then emacs could leave EMACS alone. >> >> Stuffing input to a subshell like that is in general not something you >> can do reliably. > > Yeah, that's dicy, but you don't have to do it. Just invoke the shell > with the `--noediting' option. CVS emacs already uses --noediting -i for bash (see variable explicit-bash-args). -- Kim F. Storm http://www.cua.dk |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X