GNU bug report logs - #25496
25.1.91; INSIDE_EMACS env variable is not set in eshell

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25496 in the body.
You can then email your comments to 25496 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex Hutcheson <alexhutcheson <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Fri, 20 Jan 2017 17:32:44 -0500

The INSIDE_EMACS environmental variable is set for comint processes,
including M-x shell and ansi-term. However, it's not set for eshell or
for processes launched by eshell. This makes it difficult for scripts to
detect whether or not they are being run inside eshell.

The INSIDE_EMACS env variable should be set within eshell, or should at
least be set for processes launched by eshell.

In GNU Emacs 25.1.91.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars),  
modified by Debian
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Configured using:
 'configure --build x86_64-linux-gnu --build x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
  
--enable-locallisppath=/etc/google-emacs:/etc/emacs:/usr/local/share/emacs/25.1.91+gg1+1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1.91+gg1+1/site-lisp:/usr/share/emacs/site-lisp
 --with-crt-dir=/usr/lib/x86_64-linux-gnu --disable-build-details
 --disable-silent-rules --with-modules GOOGLE_VERSION=25.1.91+gg1+1
 --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
 --without-gconf --without-gsettings build_alias=x86_64-linux-gnu
 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions
 -Wl,-z,relro -Wl,-fuse-ld=gold,--export-dynamic-symbol=__google_auxv'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -DGOOGLE_EMACS_DEFINE_AUXV''

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 87104 6318)
 (symbols 48 19929 0)
 (miscs 40 51 110)
 (strings 32 15098 4711)
 (string-bytes 1 425436)
 (vectors 16 11832)
 (vector-slots 8 435700 4672)
 (floats 8 168 31)
 (intervals 56 262 0)
 (buffers 976 19)
 (heap 1024 12629 768))

Message #8 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Alex Hutcheson <alexhutcheson <at> google.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 23 Jan 2017 15:20:33 -0500

Alex Hutcheson wrote:

> The INSIDE_EMACS environmental variable is set for comint processes,
> including M-x shell and ansi-term. However, it's not set for eshell or
> for processes launched by eshell. This makes it difficult for scripts to
> detect whether or not they are being run inside eshell.

Could you give some examples of where this matters?
It never has been set for eshell, AFAIK.

When I think of INSIDE_EMACS usage, the only thing that comes to mind is
interactive bash, which obviously isn't relevant for eshell (as a bash
replacement).

> The INSIDE_EMACS env variable should be set within eshell, or should at
> least be set for processes launched by eshell.

Message #11 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Alex Hutcheson <alexhutcheson <at> google.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 23 Jan 2017 15:36:17 -0500

> Could you give some examples of where this matters?
> It never has been set for eshell, AFAIK.

Here's the case I'm running into:
Some command line programs that I work with (version control systems, as
well as other scripts) allow the user to specify a merge tool that gets called
for merge conflicts. I prefer to use ediff as my merge tool, so I have a simple
bash script that launches emacsclient and calls ediff with the appropriate
arguments.

My desired behavior is this:
if INSIDE_EMACS:
  Run an ediff session within the existing Emacs instance
else:
  Create a new frame and launch the ediff session in that

I frequently work by SSHing into my workstation and using emacsclient to
connect to the Emacs instance running on the workstation. I run all my shell
commands in M-x shell or eshell. If I run `emacsclient -c' in one of
these shells,
it creates a graphical frame on my workstation's desktop, which I can't see over
SSH. Instead, I check for INSIDE_EMACS, and if I detect that my shell is running
within Emacs I call emacsclient without -c.


On Mon, Jan 23, 2017 at 3:20 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> Alex Hutcheson wrote:
>
>> The INSIDE_EMACS environmental variable is set for comint processes,
>> including M-x shell and ansi-term. However, it's not set for eshell or
>> for processes launched by eshell. This makes it difficult for scripts to
>> detect whether or not they are being run inside eshell.
>
> Could you give some examples of where this matters?
> It never has been set for eshell, AFAIK.
>
> When I think of INSIDE_EMACS usage, the only thing that comes to mind is
> interactive bash, which obviously isn't relevant for eshell (as a bash
> replacement).
>
>> The INSIDE_EMACS env variable should be set within eshell, or should at
>> least be set for processes launched by eshell.



-- 
Alex Hutcheson
alexhutcheson <at> google.com

Message #16 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sun, 08 Mar 2020 17:50:51 +0100

[Message part 1 (text/plain, inline)]

Didn't realize that Bug#39596 was merged with this one, I'll attach my
patch here just in case.

- Fede

[0001-Copy-INSIDE_EMACS-env-variable-to-subprocesses-in-Es.patch (text/x-patch, attachment)]

Message #19 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sat, 28 Mar 2020 16:05:47 +0100

Federico Tedin <federicotedin <at> gmail.com> writes:

> Didn't realize that Bug#39596 was merged with this one, I'll attach my
> patch here just in case.
>
> - Fede

Pinging this thread again in case a maintainer can take a look at the
patch I submitted on my last message.

Thanks!

Message #22 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 30 Mar 2020 00:29:55 +0200

[Message part 1 (text/plain, inline)]

Thanks for the feedback!

I've removed the lambda, but I wasn't able to use a string directly, I
had to set the value elsewhere using a defconst. This is due to how
`eshell-get-variable' interprets string values associated to
variables. I'm attaching a new patch.

Thanks

[0001-Copy-INSIDE_EMACS-env-variable-to-subprocesses-in-Es.patch (text/x-diff, attachment)]

Message #25 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sun, 29 Mar 2020 21:44:30 -0400

Federico Tedin <federicotedin <at> gmail.com> writes:

> I've removed the lambda, but I wasn't able to use a string directly, I
> had to set the value elsewhere using a defconst. This is due to how
> `eshell-get-variable' interprets string values associated to
> variables.

Oh, a string is actually taken as an environment variable to alias.  I
guess that does justify the name.  I think we might actually be better
off with the lambda, what do you think?

>    "This list provides aliasing for variable references.
> -It is very similar in concept to what `eshell-user-aliases-list' does
> -for commands.  Each member of this defines the name of a command,
> -and the Lisp value to return for that variable if it is accessed
> -via the syntax `$NAME'.
> +Each member defines the name of a variable, and the Lisp value to
> +return for that variable if it is accessed via the syntax `$NAME'.

Again, not a problem introduced by your patch, but "Lisp value to
return" seem pretty inaccurate (if you don't feel like fixing this, it's
okay, I think describing it correctly is somewhat non-trivial).

Message #28 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sat, 28 Mar 2020 20:21:20 -0400

Federico Tedin <federicotedin <at> gmail.com> writes:

> Pinging this thread again in case a maintainer can take a look at the
> patch I submitted on my last message.

Thanks for the ping, I had forgotten about this one.

> * lisp/eshell/em-dirs.el (eshell-dirs-initialize): Add INSIDE_EMACS
> variable to buffer-local value of eshell-variable-aliases-alist.
> * lisp/eshell/esh-var.el (eshell-variable-aliases-list): Update doc
> string; remove mention of eshell-user-aliases-list and explain that

I think eshell-user-aliases-list was meant to refer to
eshell-command-aliases-list (though maybe the reference isn't really
needed anyway).

> +           ("INSIDE_EMACS" ,(lambda (_indices)
> +                              (format "%s,eshell" emacs-version))

Since emacs-version generally doesn't change during an Emacs session, is
there any need for a lambda at all here?

>    "This list provides aliasing for variable references.
> -It is very similar in concept to what `eshell-user-aliases-list' does
> -for commands.  Each member of this defines the name of a command,
> -and the Lisp value to return for that variable if it is accessed
> -via the syntax `$NAME'.
> +Each member of this defines the name of a command, and the Lisp value
               ^^^^^^^                       ^^^^^^^
> +to return for that variable if it is accessed via the syntax `$NAME'.

(These problems weren't introduced by your patch, but) I think the "of
this" is redundant, and it should say "variable" instead of "command".

Message #31 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 30 Mar 2020 21:52:49 +0200

[Message part 1 (text/plain, inline)]

>> I've removed the lambda, but I wasn't able to use a string directly, I
>> had to set the value elsewhere using a defconst. This is due to how
>> `eshell-get-variable' interprets string values associated to
>> variables.
>
> Oh, a string is actually taken as an environment variable to alias.  I
> guess that does justify the name.  I think we might actually be better
> off with the lambda, what do you think?

Hmm, actually now it's working fine - the value associated with
INSIDE_EMACS is the symbol `eshell-inside-emacs'.  Then
`eshell-get-variable' is returning that symbol's value, which is what we
want. The `$$', `$?' and `$0' variables are also set to symbols.

(But the lambda would also work, of course. No preferences here.)

>>    "This list provides aliasing for variable references.
>> -It is very similar in concept to what `eshell-user-aliases-list' does
>> -for commands.  Each member of this defines the name of a command,
>> -and the Lisp value to return for that variable if it is accessed
>> -via the syntax `$NAME'.
>> +Each member defines the name of a variable, and the Lisp value to
>> +return for that variable if it is accessed via the syntax `$NAME'.
>
> Again, not a problem introduced by your patch, but "Lisp value to
> return" seem pretty inaccurate (if you don't feel like fixing this, it's
> okay, I think describing it correctly is somewhat non-trivial).

Aaah sorry, I hadn't read your comment correctly. I've rewritten that
part and expanded a bit upon it. I think the most confusing part is that
when a user does `$foobar', if "foobar" is not in
eshell-variable-aliases-list, then "foobar" itself is used as a "value"
(which may or may not end up pointing to an env var, or a Lisp var). But
I don't think this is relevant when explaining what
eshell-variable-aliases-list should contain.

(I've attached a new patch!)

[0001-Copy-INSIDE_EMACS-env-variable-to-subprocesses-in-Es.patch (text/x-diff, attachment)]

Message #34 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 30 Mar 2020 19:11:04 -0400

Federico Tedin <federicotedin <at> gmail.com> writes:

>>> I've removed the lambda, but I wasn't able to use a string directly, I
>>> had to set the value elsewhere using a defconst. This is due to how
>>> `eshell-get-variable' interprets string values associated to
>>> variables.
>>
>> Oh, a string is actually taken as an environment variable to alias.  I
>> guess that does justify the name.  I think we might actually be better
>> off with the lambda, what do you think?
>
> Hmm, actually now it's working fine - the value associated with
> INSIDE_EMACS is the symbol `eshell-inside-emacs'.

Yeah, it works fine, I'm just not sure if having the extra
eshell-inside-emacs variable is better than a lambda.  But anyway, it
doesn't really matter that much.  I'll wait a couple of days (in case
there are any more suggested changes) and then push to master.

>> Again, not a problem introduced by your patch, but "Lisp value to
>> return" seem pretty inaccurate (if you don't feel like fixing this, it's
>> okay, I think describing it correctly is somewhat non-trivial).
>
> Aaah sorry, I hadn't read your comment correctly.

No, no, you read it right.  I just initially wrote the wrong thing: I
hadn't realized the docstring was wrong before (that's why I mistakenly
suggested using a string instead of a lambda).

> +If the value is a string, the value for the variable with that name in
> +the current environment will be returned.  If no variable with that
> +name exists in the environment, but if a symbol with that same name
> +exists and has a value bound to it, then that value will be used.  You
> +can prioritize symbol values over environment values by setting
> +`eshell-prefer-lisp-variables' to t.
> +
> +If the value is a symbol, the value bound to that symbol will be used.

Much better, thanks.

Message #37 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Thu, 02 Apr 2020 19:06:23 -0400

tags 25496 fixed
close 25496 28.1
quit

Noam Postavsky <npostavs <at> gmail.com> writes:
> I'll wait a couple of days (in case there are any more suggested
> changes) and then push to master.

Done.

[1: f28166dc9a]: 2020-04-02 18:59:57 -0400
  Copy INSIDE_EMACS env variable to subprocesses in Eshell (Bug#25496)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f28166dc9a56111606be8ac50ad38179a66ea636

Message #44 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org, federicotedin <at> gmail.com
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Fri, 03 Apr 2020 15:17:30 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Mon, 30 Mar 2020 19:11:04 -0400
> Cc: 25496 <at> debbugs.gnu.org
> 
> > +If the value is a string, the value for the variable with that name in
> > +the current environment will be returned.  If no variable with that
> > +name exists in the environment, but if a symbol with that same name
> > +exists and has a value bound to it, then that value will be used.  You
> > +can prioritize symbol values over environment values by setting
> > +`eshell-prefer-lisp-variables' to t.
> > +
> > +If the value is a symbol, the value bound to that symbol will be used.
> 
> Much better, thanks.

Would it be possible to reword this so that passive tense is used less
frequently?  E.g., instead of "the variable with that name in the
current environment will be returned", how about "return the variable
with that name in the current environment"?  And similarly with the
rest of the doc string.

Thanks.

Message #47 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25496 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sat, 04 Apr 2020 12:08:43 +0200

[Message part 1 (text/plain, inline)]

>> I'll wait a couple of days (in case there are any more suggested
>> changes) and then push to master.
>
> Done.

Thanks!

> Would it be possible to reword this so that passive tense is used less
> frequently?  E.g., instead of "the variable with that name in the
> current environment will be returned", how about "return the variable
> with that name in the current environment"?  And similarly with the
> rest of the doc string.
>
> Thanks.

No problem, I've attached a patch with the changes.

[0001-Reword-documentation-for-eshell-variable-aliases-lis.patch (text/x-diff, attachment)]

Message #50 received at 25496-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: npostavs <at> gmail.com, 25496-done <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Sat, 11 Apr 2020 12:20:54 +0300

> From: Federico Tedin <federicotedin <at> gmail.com>
> Cc: Noam Postavsky <npostavs <at> gmail.com>,  25496 <at> debbugs.gnu.org
> Date: Sat, 04 Apr 2020 12:08:43 +0200
> 
> > Would it be possible to reword this so that passive tense is used less
> > frequently?  E.g., instead of "the variable with that name in the
> > current environment will be returned", how about "return the variable
> > with that name in the current environment"?  And similarly with the
> > rest of the doc string.
> >
> > Thanks.
> 
> No problem, I've attached a patch with the changes.

Thanks, pushed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.