[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
From: |
Alex Hutcheson |
Subject: |
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@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@google.com