Compile Mode and "host" Emacs

Compile Mode and "host" Emacs

[Sebastian Wiesner]

Hello,

how can a compilation process obtain the path to the Emacs executable
which started it?

I know that Emacs sets $EMACS and $INSIDE_EMACS in the environment of
compile processes, but the values of these variables aren't exactly
helpful and I didn't see any other environment variables in the
compile code.  So apparently environment variables can't help me.

Is there any way to find out the path to the "host" Emacs executable?
Preferably with not too much trickery?

Sincerely,
Sebastian Wiesner

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Your best bet is probably:

(concat (file-name-as-directory invocation-directory) invocation-name)

You can wrap that in (file-truename ...) if you want the true name.

Nathan

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Hello,
>
> how can a compilation process obtain the path to the Emacs executable
> which started it?
>
> I know that Emacs sets $EMACS and $INSIDE_EMACS in the environment of
> compile processes, but the values of these variables aren't exactly
> helpful and I didn't see any other environment variables in the
> compile code.  So apparently environment variables can't help me.
>
> Is there any way to find out the path to the "host" Emacs executable?
> Preferably with not too much trickery?
>
> Sincerely,
> Sebastian Wiesner

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Your best bet is probably:
>
> (concat (file-name-as-directory invocation-directory) invocation-name)
>
> You can wrap that in (file-truename ...) if you want the true name.

Uhm, you misunderstood me.  I didn't ask how to get the path to the
Emacs executable within the running Emacs instance itself.

Rather, I wanted to know how to get the path to the Emacs executable
**from within a running subprocess**, started by `M-x compile`.

For instance, assume that I do "M-x compile RET foo.sh", then how can
I get the path to the Emacs executable **within foo.sh**.

I have "$EMACS" and "$INSIDE_EMACS", but the values of these variables
are pretty much useless.

>
> Nathan
>
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> Hello,
>>
>> how can a compilation process obtain the path to the Emacs executable
>> which started it?
>>
>> I know that Emacs sets $EMACS and $INSIDE_EMACS in the environment of
>> compile processes, but the values of these variables aren't exactly
>> helpful and I didn't see any other environment variables in the
>> compile code.  So apparently environment variables can't help me.
>>
>> Is there any way to find out the path to the "host" Emacs executable?
>> Preferably with not too much trickery?
>>
>> Sincerely,
>> Sebastian Wiesner

Re: Compile Mode and "host" Emacs

[Andreas Schwab]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> For instance, assume that I do "M-x compile RET foo.sh", then how can
> I get the path to the Emacs executable **within foo.sh**.

Why do you need that?  What is the difference to running it outside
Emacs?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Uhm, you misunderstood me.  I didn't ask how to get the path to the
> Emacs executable within the running Emacs instance itself.
>
> Rather, I wanted to know how to get the path to the Emacs executable
> **from within a running subprocess**, started by `M-x compile`.
>
> For instance, assume that I do "M-x compile RET foo.sh", then how can
> I get the path to the Emacs executable **within foo.sh**.
>
> I have "$EMACS" and "$INSIDE_EMACS", but the values of these variables
> are pretty much useless.

I don't think there's any portable way.  If you're running on Linux and
you know the process's direct parent is emacs, you could do something
like:

executable=$(readlink -f /proc/$PPID/exe)

where $PPID is the parent's process id, which can be obtained in various
ways.  Of course, this only works if emacs is the direct parent.

A better way would probably be to set some environment variable to the
full path in your init file, and then using that from the compile
process:

;;;; .emacs

(setenv "EMACS_EXE_PATH"
        (file-truename (concat (file-name-as-directory
                                 invocation-directory)
                                 invocation-name)))

Nathan 

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Andreas Schwab <schwab@suse.de>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> For instance, assume that I do "M-x compile RET foo.sh", then how can
>> I get the path to the Emacs executable **within foo.sh**.
>
> Why do you need that?  What is the difference to running it outside
> Emacs?

Oh, come on, can we please just assume that I *have* a valid use case?
 Is it so hard not to challenge a question, and just *answer* it?

But since you will insist:  I want to interact with the running Emacs,
obviously.  More precisely, in my "build" script I want to evaluate
some expressions, and probably a complete Emacs Lisp script.

Now, it's not quite uncommon to have multiple Emacs versions
installed.  To give the user the freedom of choice in this case, I
provide an option to select the target Emacs.

Currently I just use the default `emacs` executable, if the user
didn't select a different version.  When running outside Emacs, I have
no other choice, but when running from inside Emacs, I could really
use a more clever default, namely the Emacs, that was used to start
the script.

It's not quite an essential feature, but really convenient, if you use
a "non-default" Emacs, that is, an Emacs, which is not available as
"emacs" in "$PATH".  Which is, by the way, a common case on OS X, if
Emacs is installed from a pre-build App bundle.  In such cases,
"emacs" still points to the OS X system Emacs (a horribly dated
version 22), but the user actually uses a more recent version from an
App bundle, started from the graphical user interface of OS X.

>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> Uhm, you misunderstood me.  I didn't ask how to get the path to the
>> Emacs executable within the running Emacs instance itself.
>>
>> Rather, I wanted to know how to get the path to the Emacs executable
>> **from within a running subprocess**, started by `M-x compile`.
>>
>> For instance, assume that I do "M-x compile RET foo.sh", then how can
>> I get the path to the Emacs executable **within foo.sh**.
>>
>> I have "$EMACS" and "$INSIDE_EMACS", but the values of these variables
>> are pretty much useless.
>
> I don't think there's any portable way.

That's unfortunate.

I cannot but wonder what (stupid?) rationale let to the design of
"$EMACS" and "$INSIDE_EMACS", if I have no chance to find out *what*
Emacs I am actually inside of…

>  If you're running on Linux

I am not, nor could I guarantee that my users do.

> you know the process's direct parent is emacs

I can guarantee that neither.

> A better way would probably be to set some environment variable to the
> full path in your init file, and then using that from the compile
> process:
>
> ;;;; .emacs
>
> (setenv "EMACS_EXE_PATH"
>         (file-truename (concat (file-name-as-directory
>                                  invocation-directory)
>                                  invocation-name)))

I am not in control of my users' configurations, nor can I reasonably
demand them to change their "init.el" just to support a single script.
 Besides, if I tell them to change their "init.el", I might just as
well tell them to select the target Emacs via the corresponding option
of my script right away.

>
> Nathan

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> I am not in control of my users' configurations, nor can I reasonably
> demand them to change their "init.el" just to support a single script.
>  Besides, if I tell them to change their "init.el", I might just as
> well tell them to select the target Emacs via the corresponding option
> of my script right away.

Then I think you're out of luck on this one.

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> I am not in control of my users' configurations, nor can I reasonably
>> demand them to change their "init.el" just to support a single script.
>>  Besides, if I tell them to change their "init.el", I might just as
>> well tell them to select the target Emacs via the corresponding option
>> of my script right away.
>
> Then I think you're out of luck on this one.

Do you think a bug report on changing the value of "$EMACS" or
"$INSIDE_EMACS" from "t" to the path of the running Emacs would stand
a chance?

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Do you think a bug report on changing the value of "$EMACS" or
> "$INSIDE_EMACS" from "t" to the path of the running Emacs would stand
> a chance?

I'm not the one to ask, but I suspect it could be easily done and
therefore would have a good chance of being accepted.  A more reasonable
proposal would be to have emacs set a third environment variable to the
path in the way I suggested above.  That way, the other two could retain
their meaning.

However, given what you have said, I don't see how that would solve your
problem.  You'd have to wait for the feature to be accepted and
implemented, then for it to be released, and then, finally, for your
users to upgrade.

Re: Compile Mode and "host" Emacs

[Andreas Schwab]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> But since you will insist:  I want to interact with the running Emacs,
> obviously.  More precisely, in my "build" script I want to evaluate
> some expressions, and probably a complete Emacs Lisp script.

That's what emacsclient is for.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> Do you think a bug report on changing the value of "$EMACS" or
>> "$INSIDE_EMACS" from "t" to the path of the running Emacs would stand
>> a chance?
>
> I'm not the one to ask, but I suspect it could be easily done and
> therefore would have a good chance of being accepted.  A more reasonable
> proposal would be to have emacs set a third environment variable to the
> path in the way I suggested above.  That way, the other two could retain
> their meaning.

I'll think of it, then.  A 3rd, independent variable is probably the
best idea here.

> However, given what you have said, I don't see how that would solve your
> problem.  You'd have to wait for the feature to be accepted and
> implemented, then for it to be released, and then, finally, for your
> users to upgrade.

Well, as I myself use Emacs trunk, it would solve *my* problem
immediately :)  Of course, it would not solve my users' problem right
now, but at least it would do so in the foreseeable future, when Emacs
24.4 is released.  That's still better than nothing, isn't it?

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Well, as I myself use Emacs trunk, it would solve *my* problem
> immediately :)  Of course, it would not solve my users' problem right
> now, but at least it would do so in the foreseeable future, when Emacs
> 24.4 is released.  That's still better than nothing, isn't it?

Yes it is.  But if solving _your_ problem is good enough in the short
run, why not just add that (setenv ...) sexp to your .emacs?

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Andreas Schwab <schwab@suse.de>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> But since you will insist:  I want to interact with the running Emacs,
>> obviously.  More precisely, in my "build" script I want to evaluate
>> some expressions, and probably a complete Emacs Lisp script.
>
> That's what emacsclient is for.

That makes no difference, it just shifts the problem from finding the
right Emacs to finding the right "emacsclient".  You can't (easily)
use a v22 "emacsclient" to talk to a v24 Emacs, so I would still need
to find the path to the running Emacs, in order to use its
corresponding "emacsclient".

Besides, I deliberately don't want to use "emacsclient", because I do
not want my build script to depend on the users customizations or
block (in case of long-running expressions) block the running Emacs
instance.

I see that my statement was ambiguous, which I apologize for.  To
clarify, I do not actually intend to talk to the running Emacs
process.  I merely want to use the same Emacs *executable* as the
running process.

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> Well, as I myself use Emacs trunk, it would solve *my* problem
>> immediately :)  Of course, it would not solve my users' problem right
>> now, but at least it would do so in the foreseeable future, when Emacs
>> 24.4 is released.  That's still better than nothing, isn't it?
>
> Yes it is.  But if solving _your_ problem is good enough in the short
> run, why not just add that (setenv ...) sexp to your .emacs?

Well, because obviously this would *never* solve this problem for my
users, unless they replicate my configuration.

If Compile Mode was now changed to set a variable, lets call it
"EMACS_PATH" for now, I myself would not need to do anything, and my
users would just need to add this variable to their "init.el"
temporarily, until 24.4 is released.

And besides, setting variables in "init.el" just to support a single
script is sort of a dirty hack, isn't it?  I'd rather like to see this
solved in a clean way in Emacs itself.

After all, this use case can't be so special that none else has it.

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> If Compile Mode was now changed to set a variable, lets call it
> "EMACS_PATH" for now, I myself would not need to do anything, and my
> users would just need to add this variable to their "init.el"
> temporarily, until 24.4 is released.

Sorry, I don't follow.  If asking your users to temporarily add
something to their initialization files is an option, why not:

(setenv "EMACS_EXE_PATH"
        (file-truename (concat (file-name-as-directory
                                 invocation-directory)
                                 invocation-name)))

?

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Nathan Trapuzzano <nbtrap@nbtrap.com>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> If Compile Mode was now changed to set a variable, lets call it
>> "EMACS_PATH" for now, I myself would not need to do anything, and my
>> users would just need to add this variable to their "init.el"
>> temporarily, until 24.4 is released.
>
> Sorry, I don't follow.  If asking your users to temporarily add
> something to their initialization files is an option, why not:
>
> (setenv "EMACS_EXE_PATH"
>         (file-truename (concat (file-name-as-directory
>                                  invocation-directory)
>                                  invocation-name)))

See, I can ask them, or better, "advise" them, but I can't actually
rely upon them, can I?  There is still a chance that the user lacks
this setting, or (even worse) has it wrong, isn't there?

If Emacs set "EMACS_EXE_PATH" for me, I would not need to advise my
users to change their "init.el" (at least in foreseeable future), and
there is little chance that things can go wrong.

Surely, it is not essential, but it is *a lot* more convenient, if
Emacs just got things right here :)

Re: Compile Mode and "host" Emacs

[Nathan Trapuzzano]

Right, I was only talking about the short-term.

Re: Compile Mode and "host" Emacs

[Andreas Schwab]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> I see that my statement was ambiguous, which I apologize for.  To
> clarify, I do not actually intend to talk to the running Emacs
> process.  I merely want to use the same Emacs *executable* as the
> running process.

You need an Emacs that can process your lisp expressions.  That is
independent of the Emacs that happens to execute the compile process.
As such it is not useful to know anything about that instance.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Andreas Schwab <schwab@suse.de>:
> Sebastian Wiesner <lunaryorn@gmail.com> writes:
>
>> I see that my statement was ambiguous, which I apologize for.  To
>> clarify, I do not actually intend to talk to the running Emacs
>> process.  I merely want to use the same Emacs *executable* as the
>> running process.
>
> You need an Emacs that can process your lisp expressions.  That is
> independent of the Emacs that happens to execute the compile process.
> As such it is not useful to know anything about that instance.

Begging your pardon, but *I* find it extremely useful to know this
instance, and as such, I would have preferred to have my question
answered and my problem solved rather than seeing my question
arrogantly dismissed as "not useful", and being lectured upon what my
problem actually is.

>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: Compile Mode and "host" Emacs

[David Engster]

Sebastian Wiesner writes:
> 2013/10/29 Andreas Schwab <schwab@suse.de>:
>> That's what emacsclient is for.
>
> That makes no difference, it just shifts the problem from finding the
> right Emacs to finding the right "emacsclient".  You can't (easily)
> use a v22 "emacsclient" to talk to a v24 Emacs,

> [...]

While emacsclient from 22.1 cannot open a new frame, you can still use
it to evaluate lisp (yes, I actually tried). You can retrieve the the
invoked emacs binary from the running server by calling

 emacsclient -e '(expand-file-name invocation-name invocation-directory)'

You just have to be aware that an older emacsclient will prefix the
output with '-print'.

-David

Re: Compile Mode and "host" Emacs

[Michael Albinus]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Begging your pardon, but *I* find it extremely useful to know this
> instance, and as such, I would have preferred to have my question
> answered and my problem solved rather than seeing my question
> arrogantly dismissed as "not useful", and being lectured upon what my
> problem actually is.

Before implementing your request in Emacs core, it might be useful to
understand that it is of general interest. If it solves only *your*
problem, which could be solved also otherwise, nobody will add it.

Btw, you could write an own command, which wraps `compile' with the
necessary information (like setting the environment $EMACS_PATH). Then
you could instruct your users to perform this command instead of M-x
compile.

Best regards, Michael.

Re: Compile Mode and "host" Emacs

[Andreas Schwab]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Begging your pardon, but *I* find it extremely useful to know this
> instance,

It won't help your case.  You still won't know whether this instance
(which is just acting as a shell) is of the version you need, and you
have to be prepared to search for an alternative anyway.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Compile Mode and "host" Emacs

[Stefan Monnier]

So, IIUC your setup is:
- you have some kind of script that is run from Emacs.
- you have no control over how Emacs runs it (presumably via M-x
  compile, but could be M-! or anything else, and without any related
  Elisp package).
- this script needs to run Elisp code.
- you care about machines where a useful `emacs' can't be found in $PATH.

So, yes, you're probably out of luck.  If your script comes with some
Elisp package, you could have that package add whatever you need to
the environment, but without it, you're screwed.

Emacs does not itself look for its own executable, usually; and of
course, in the general case we can't find this file because it may not
even have a name any more (you can `rm' the file after Emacs is
started ;-).

This said, I've never encountered such a situation.  Maybe there's
a different way to attack the problem, tho.  E.g. distribute your
package via ELPA, so it can bundle a little Elisp that's automatically
run at startup.


        Stefan

Re: Compile Mode and "host" Emacs

[Eli Zaretskii]

> Date: Tue, 29 Oct 2013 15:04:08 +0100
> From: Sebastian Wiesner <lunaryorn@gmail.com>
> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
> 
> I see that my statement was ambiguous, which I apologize for.  To
> clarify, I do not actually intend to talk to the running Emacs
> process.  I merely want to use the same Emacs *executable* as the
> running process.

What do you mean by "use the Emacs executable"?  Use how?  Invoke it
as a separate process? read some of its parts into memory? something
else?

Re: Compile Mode and "host" Emacs

[Eli Zaretskii]

> Date: Tue, 29 Oct 2013 16:52:42 +0100
> From: Sebastian Wiesner <lunaryorn@gmail.com>
> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
> 
> I would have preferred to have my question answered and my problem
> solved rather than seeing my question arrogantly dismissed as "not
> useful", and being lectured upon what my problem actually is.

Perhaps if you explained in more details what is your problem, the
issue would become more clear, and you could get more focused replies.
As things stand, you only described in very general terms what you
want to do, and on that level, Andreas is right: the OOB tool to
communicate with Emacs is emacsclient.  Providing more details might
clarify whether emacsclient fits the bill or not, and why, and if it
doesn't, what might fit the bill.

Re: Compile Mode and "host" Emacs

[chad]

On 29 Oct 2013, at 06:18, Sebastian Wiesner <lunaryorn@gmail.com> wrote:
>> 
>> I don't think there's any portable way.
> 
> That's unfortunate.

It was (is?) an early design principle of unix systems that there isn't necessarily any such thing as `the path' or even `a path' to anything. This has a number of positive benefits surrounding hard links, soft links, movable files, and [un/re]mountable filesystems. Instead, we got conventions (not rules) about where things should be, and how to find them. It also has a cost, but it's relatively low - most of the time, when someone said "I want my program to know its place in the filesystem.", they really didn't need to know that, and there were better ways to accomplish their goals. For example, often these requests are an effort to work around the user's configuration choices, and that desire gets things wrong at least as often as it gets things right - even if it seems better in the short-term, narrow-focus view.

That said, there are times when the program really does want to know that data, so emacs provides a way to find it (invocation-*, mentioned above). Under macosx, for example, if you build a relocatable bundle, it really wants to be able to find its lisp libraries.

> I cannot but wonder what (stupid?) rationale let to the design of
> "$EMACS" and "$INSIDE_EMACS", if I have no chance to find out *what*
> Emacs I am actually inside of…

In most cases, programs don't care at all. When they do care, in most cases they care if they're running inside any sort of emacs at all or not. Your case appears to care inside which specific filesystem invocation of emacs it was run, which is unusual. Most cases, when examined, really are better off using rather than bypassing the user's configuration (PATH in this case). If I were using some code that wanted to know where emacs was installed, and I changed PATH for that code, I wouldn't want it poking around and guessing that it should ignore PATH. Conversely, if the user hasn't set PATH, but wants to interact with emacs, they generally will get similar sorts of wrong behavior if they're shell uses the wrong programs from bin and libexec (ctags, etags, emacsclient, etc).

In most cases, then, the right thing to do is to get/help the user configure emacs on their system correctly, rather than second-guess their intentions - it's harder to do, but gives the right result in more cases.

>> A better way would probably be to set some environment variable to the
>> full path in your init file, and then using that from the compile
>> process:
>> 
>> ;;;; .emacs
>> 
>> (setenv "EMACS_EXE_PATH"
>>        (file-truename (concat (file-name-as-directory
>>                                 invocation-directory)
>>                                 invocation-name)))
> 
> I am not in control of my users' configurations, nor can I reasonably
> demand them to change their "init.el" just to support a single script.
> Besides, if I tell them to change their "init.el", I might just as
> well tell them to select the target Emacs via the corresponding option
> of my script right away.

That's a good idea; you can also have your script run emacs (probably -batch) and have that emacs stash the info you need somewhere. I'll point out that if you expect your users to interact with emacs both from a gui launcher and from the command-line, it's almost never a bad idea to suggest and/or help them to configure their environment so that emacs works well in both situations.

Hopefully that helps explain why what seemed like a simple question wasn't quite as simple as you'd thought. If you can explain a bit more what it is you're actually trying to do, we can probably provide some helpful suggestions about how to accomplish your goals.

Thanks,
~Chad

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Stefan Monnier <monnier@iro.umontreal.ca>:
> So, IIUC your setup is:
> - you have some kind of script that is run from Emacs.
> - you have no control over how Emacs runs it (presumably via M-x
>   compile, but could be M-! or anything else, and without any related
>   Elisp package).
> - this script needs to run Elisp code.
> - you care about machines where a useful `emacs' can't be found in $PATH.

Yes, that is about right.  More generally, I care for situations in
which the "emacs" in $PATH is different from the Emacs I currently
use, for whatever reason (e.g. testing Emacs Lisp code in an other
Emacs version, trying a trunk build, etc.)

> So, yes, you're probably out of luck.  If your script comes with some
> Elisp package, you could have that package add whatever you need to
> the environment, but without it, you're screwed.

I am screwed then.  I presume there is no chance of having a new
variable introduced for this purpose, or changing the value of the
existing variables?

See, even if we leave my use case aside, the values of $EMACS and
$INSIDE_EMACS are generally not helpful.

Emacs tells subprocesses that they are running within Emacs by the
mere presence of $INSIDE_EMACS, but it just doesn't tell them, *which*
Emacs they are running inside.  Even if this information serves no
useful purpose other than making some scripts more convenient, the
current value of $INSIDE_EMACS serves even less purpose.  It is simply
"t", which conveys absolutely no useful information.

Is any harm done by changing these values to a more useful value?

> Emacs does not itself look for its own executable, usually;

Nonetheless we have "invocation-directory" and "invocation-name" in
Emacs Lisp, so the information is there.

And it is a useful piece of information.  I use it in Flycheck to
asynchronously check Emacs Lisp code, and I have seen Flymake recipes
doing the same.  It has also been used to implement asynchronous
functions for Emacs Lisp [1].

It is just not exposed to subprocesses from compile-mode…

> and of course, in the general case we can't find this file because it may not
> even have a name any more (you can `rm' the file after Emacs is
> started ;-).

Well, if Emacs goes away after being started, not being able to use
its executable is the least of all problems.  On my system, Emacs
won't even exit, if uninstalled after started, because libraries
backing some autoloadable `kill-emacs-hook` functions are gone.

Yes, strictly speaking, that's not exactly the same as just "rm
emacs", but who does this really?

[1]: https://github.com/jwiegley/emacs-async

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Eli Zaretskii <eliz@gnu.org>:
>> Date: Tue, 29 Oct 2013 15:04:08 +0100
>> From: Sebastian Wiesner <lunaryorn@gmail.com>
>> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
>>
>> I see that my statement was ambiguous, which I apologize for.  To
>> clarify, I do not actually intend to talk to the running Emacs
>> process.  I merely want to use the same Emacs *executable* as the
>> running process.
>
> What do you mean by "use the Emacs executable"?  Use how?  Invoke it
> as a separate process?

Well, yes. What else should I do with an executable? :)

Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Eli Zaretskii <eliz@gnu.org>:
>> Date: Tue, 29 Oct 2013 16:52:42 +0100
>> From: Sebastian Wiesner <lunaryorn@gmail.com>
>> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
>>
>> I would have preferred to have my question answered and my problem
>> solved rather than seeing my question arrogantly dismissed as "not
>> useful", and being lectured upon what my problem actually is.
>
> Perhaps if you explained in more details what is your problem, the
> issue would become more clear, and you could get more focused replies.
> As things stand, you only described in very general terms what you
> want to do, and on that level, Andreas is right: the OOB tool to
> communicate with Emacs is emacsclient.  Providing more details might
> clarify whether emacsclient fits the bill or not, and why, and if it
> doesn't, what might fit the bill.

"emacsclient" runs code in a running Emacs.  I don't want a use the
running session, but rather a fresh session, but using the same Emacs.

I think, there are a number of use cases for this:

An Emacs Lisp developer runs her ERT tests in a fresh Emacs session.
She has a Makefile with a "test" target, and a bunch of different
Emacs versions installed (e.g. Emacs 23.4, Emacs 24.2, Emacs 24.3,
three different Emacs trunk builds), to test her package against all
supported Emacs versions.   When developing her package, she has
different Emacs versions running in parallel to try how different
Emacs versions behave.   She wants "M-x compile RET make test" to use
the Emacs version she is currently in, and she does not want to
remember to explicitly specify the target version in each Emacs
session with "make EMACS=emacs23.4 test".

She also byte-compiles her libraries in a fresh Emacs session to make
sure that they cause no warnings (e.g. assignment to free variables,
unused lexical variables, undefined functions, whatever).  For this
purpose, she has a "compile" target in her Makefile, and she also
wants to compile against the very she is currently in.

A Emacs Lisp has written a little script to update all her installed
packages from the command line.  As she uses a lot of packages and
updates only once in a while, updates take long, and she wants to
continue working meanwhile.  Thus, she calls her update script via
"M-x compile", watches the compile buffer for progress, and calls
"package-initialize" once the update is done, to make her Emacs use
the new packages.  Obviously, she wants to install packages for the
Emacs she is currently using, and not the one, which is in "$PATH".
She has a few systems, where these are actually different:  A Fedora
system at work, where she has no root privileges.  She installed Emacs
trunk from source, and added it to the Gnome 3 menu.  Also an OS X
system at home, where she installed Emacs 24.3 as App Bundle, by just
dragging it into the "/Applications" folder.  In both cases, the
"emacs" in $PATH is different from the Emacs she uses and starts from
the GUI.  She does not want this Emacs to be used in her script,
because it would break in both cases, because the system "emacs" is
outdated.

I hope these use cases make my intend a little more clear.

My personal motivation for this feature is the Cask [1] project, which
pretty much covers the 3rd use case "install and update packages from
command line".  We had a number of reports from OS X people who
installed Emacs as App bundle from http://emacsformacosx.com/, and
never added a "emacs" script to their path.  When these people used
"M-x compile" to invoke Cask, they got mysterious errors, because Cask
used "emacs" from $PATH, which is a out-dated Emacs 22 included with
OS X.  We could argue that their setup is broken, but as a matter of
fact, these people just used the standard installation procedure for
OS X applications, and are sometimes even surprised that there is
already an Emacs included in their OS X.

Just to make things clear: I agree that in neither of these cases it
is *essential* to expose the Emacs executable path to the subprocess,
but it would be definitely convenient…

[1]: https://github.com/cask/cask

Re: Compile Mode and "host" Emacs

[Eli Zaretskii]

> Date: Tue, 29 Oct 2013 20:09:04 +0100
> From: Sebastian Wiesner <lunaryorn@gmail.com>
> Cc: schwab@suse.de, nbtrap@nbtrap.com, emacs-devel@gnu.org
> 
> 2013/10/29 Eli Zaretskii <eliz@gnu.org>:
> >> Date: Tue, 29 Oct 2013 16:52:42 +0100
> >> From: Sebastian Wiesner <lunaryorn@gmail.com>
> >> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
> >>
> >> I would have preferred to have my question answered and my problem
> >> solved rather than seeing my question arrogantly dismissed as "not
> >> useful", and being lectured upon what my problem actually is.
> >
> > Perhaps if you explained in more details what is your problem, the
> > issue would become more clear, and you could get more focused replies.
> > As things stand, you only described in very general terms what you
> > want to do, and on that level, Andreas is right: the OOB tool to
> > communicate with Emacs is emacsclient.  Providing more details might
> > clarify whether emacsclient fits the bill or not, and why, and if it
> > doesn't, what might fit the bill.
> 
> "emacsclient" runs code in a running Emacs.  I don't want a use the
> running session, but rather a fresh session, but using the same Emacs.

Ah, but you could use emacsclient to provide the absolute file name of
the running Emacs, like this:

  emacsclient --eval "(concat invocation-directory invocation-name)"

and then use the result to invoke a fresh instance of the same binary.

> An Emacs Lisp developer runs her ERT tests in a fresh Emacs session.
> She has a Makefile with a "test" target, and a bunch of different
> Emacs versions installed (e.g. Emacs 23.4, Emacs 24.2, Emacs 24.3,
> three different Emacs trunk builds), to test her package against all
> supported Emacs versions.   When developing her package, she has
> different Emacs versions running in parallel to try how different
> Emacs versions behave.   She wants "M-x compile RET make test" to use
> the Emacs version she is currently in, and she does not want to
> remember to explicitly specify the target version in each Emacs
> session with "make EMACS=emacs23.4 test".

No need to remember, there could be a specialized command to
automatically add the EMACS=whatever part.

> She also byte-compiles her libraries in a fresh Emacs session to make
> sure that they cause no warnings (e.g. assignment to free variables,
> unused lexical variables, undefined functions, whatever).  For this
> purpose, she has a "compile" target in her Makefile, and she also
> wants to compile against the very she is currently in.

Same-same.

> A Emacs Lisp has written a little script to update all her installed
> packages from the command line.  As she uses a lot of packages and
> updates only once in a while, updates take long, and she wants to
> continue working meanwhile.  Thus, she calls her update script via
> "M-x compile", watches the compile buffer for progress, and calls
> "package-initialize" once the update is done, to make her Emacs use
> the new packages.  Obviously, she wants to install packages for the
> Emacs she is currently using, and not the one, which is in "$PATH".
> She has a few systems, where these are actually different:  A Fedora
> system at work, where she has no root privileges.  She installed Emacs
> trunk from source, and added it to the Gnome 3 menu.  Also an OS X
> system at home, where she installed Emacs 24.3 as App Bundle, by just
> dragging it into the "/Applications" folder.  In both cases, the
> "emacs" in $PATH is different from the Emacs she uses and starts from
> the GUI.  She does not want this Emacs to be used in her script,
> because it would break in both cases, because the system "emacs" is
> outdated.
> 
> I hope these use cases make my intend a little more clear.

They are all the same use case, and I can see at least 2 solutions,
outlined above.  One that uses custom commands which wrap "M-x compile",
the other that uses emacsclient to glean the file name of the running
binary.

Re: Compile Mode and "host" Emacs

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Ah, but you could use emacsclient to provide the absolute file name of
> the running Emacs, like this:
>
>   emacsclient --eval "(concat invocation-directory invocation-name)"
>
> and then use the result to invoke a fresh instance of the same binary.

This communicates with an Emacs instance that is acting as a server, if
any, right?

Re: Compile Mode and "host" Emacs

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 29 Oct 2013 21:22:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Ah, but you could use emacsclient to provide the absolute file name of
> > the running Emacs, like this:
> >
> >   emacsclient --eval "(concat invocation-directory invocation-name)"
> >
> > and then use the result to invoke a fresh instance of the same binary.
> 
> This communicates with an Emacs instance that is acting as a server, if
> any, right?

Yes, of course.  Presumably, the person who needs this has an Emacs
running, just not one that's on PATH.

Re: Compile Mode and "host" Emacs

[Stefan Monnier]

>> So, yes, you're probably out of luck.  If your script comes with some
>> Elisp package, you could have that package add whatever you need to
>> the environment, but without it, you're screwed.

> I am screwed then.  I presume there is no chance of having a new
> variable introduced for this purpose, or changing the value of the
> existing variables?

> See, even if we leave my use case aside, the values of $EMACS and
> $INSIDE_EMACS are generally not helpful.

$EMACS is useless, indeed: for some reason we used to set it to "t"
a long time ago, and a less-long time ago, someone complained that it
broke Makefile-style use where $EMACS is supposed to hold the command to
run Emacs.  So now, we only add "EMACS=t" if EMACS is not already defined.

From this point of view, it would be "natural" to set $EMACS not to "t"
but to (expand-file-name invocation-name invocation-directory).

But I'm afraid it would still break some of the use cases that are
broken by "t", so we'd still have to do it conditionally (i.e. only when
$EMACS is undefined).  Furthermore, it would also break some people's
.<foo>shrc where the test if $EMACS is "t" to detect if running in
M-x shell (look for «if ("$EMACS" == t) then» in
http://www.opensource.apple.com/source/emacs/emacs-51/emacs/info/efaq-2
for an example).

> Emacs tells subprocesses that they are running within Emacs by the
> mere presence of $INSIDE_EMACS, but it just doesn't tell them, *which*
> Emacs they are running inside.  Even if this information serves no
> useful purpose other than making some scripts more convenient, the
> current value of $INSIDE_EMACS serves even less purpose.  It is simply
> "t", which conveys absolutely no useful information.

I think this is a bug in compile.el: $INSIDE_EMACS should be of the form
"<version>,<context>", as is the case when the process is run by comint,
term, and tramp.  Patch welcome.  So, $INSIDE_EMACS should at least give
you the version number, tho not the actual file name.

> Is any harm done by changing these values to a more useful value?

I think it would break some people's setups, yes.  Maybe changing $EMACS
as suggested above could be considered if we have a good replacement
test for "$EMACS == t" that has the advantage of being more reliable
(e.g. something like "$TERM = emacs").  Still, I'm not sure it's worth
the trouble to break people's .fooshrc.

> My personal motivation for this feature is the Cask [1] project, which
> pretty much covers the 3rd use case "install and update packages from
> command line".  We had a number of reports from OS X people who

Why not make Cask an ELPA package?
[ Even better: a GNU ELP package ;-)  ]

Then you could easily add a CASK_EMACS envvar from the autoloaded code
of the package.  Also, it seems just natural for Cask to itself be an
ELPA package, doesn't it?


        Stefan

Re: Compile Mode and "host" Emacs

[Xue Fuqiao]

On Wed, Oct 30, 2013 at 5:40 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Why not make Cask an ELPA package?

It is already in MELPA[fn:1].

> [ Even better: a GNU ELPA package ;-)  ]

+1

Footnotes:

[fn:1] http://melpa.milkbox.net/#/cask

-- 
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: Compile Mode and "host" Emacs

[Stephen J. Turnbull]

Sebastian Wiesner writes:

 > > Sorry, I don't follow.  If asking your users to temporarily add
 > > something to their initialization files is an option, why not:
 > >
 > > (setenv "EMACS_EXE_PATH"
 > >         (file-truename (concat (file-name-as-directory
 > >                                  invocation-directory)
 > >                                  invocation-name)))
 > 
 > See, I can ask them, or better, "advise" them, but I can't actually
 > rely upon them, can I?  There is still a chance that the user lacks
 > this setting, or (even worse) has it wrong, isn't there?

Yes.  However, if your users all use an organizationally-supplied
Emacs as you imply, you can put it in site-start.el in your
distribution.  Inhibiting site-start.el is rather uncommon, so this
should do the trick for you.

Re: Compile Mode and "host" Emacs

[Jorgen Schaefer]

On Wed, 30 Oct 2013 13:43:31 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> Sebastian Wiesner writes:
> 
>  > > Sorry, I don't follow.  If asking your users to temporarily add
>  > > something to their initialization files is an option, why not:
>  > >
>  > > (setenv "EMACS_EXE_PATH"
>  > >         (file-truename (concat (file-name-as-directory
>  > >                                  invocation-directory)
>  > >                                  invocation-name)))
>  > 
>  > See, I can ask them, or better, "advise" them, but I can't actually
>  > rely upon them, can I?  There is still a chance that the user lacks
>  > this setting, or (even worse) has it wrong, isn't there?
> 
> Yes.  However, if your users all use an organizationally-supplied
> Emacs as you imply, you can put it in site-start.el in your
> distribution.  Inhibiting site-start.el is rather uncommon, so this
> should do the trick for you.

One use case Sebastian has in mind is mine. One of my Emacs packages is
being tested on 24.1, 24.2, 24.3 and trunk. I have all four Emacsen
installed. I run all my unit tests in all of those. Thanks to cask, none
of those share installed packages so I test an actual use environment,
not my own environment. Not even cask is installed in those. When I find
a bug, I start the respective Emacs and see what is causing it. "emacs"
runs trunk, "emacs-24.1" runs that one, etc.

From within that Emacs, I then run programs such as ert-testrunner
which use Emacs to run automated tests. It's impossible for these
programs to tell which Emacs I am currently using, even though the
information is trivially accessible to Emacs itself. This is not
impossible to work around (I simply manually set EMACS, I also could
manually set EMACS_EXE_PATH or whatever), but it would be nice if the
information was more easily available.

Regards,
Jorgen

Re: Compile Mode and "host" Emacs

[Stephen J. Turnbull]

Jorgen Schaefer writes:

 > From within that Emacs, I then run programs such as ert-testrunner
 > which use Emacs to run automated tests.

Nope, not the same use-case.

(defmacro with-emacs-exe-set-in-environment (pollute-permanently &rest body)
  "Documentation is an exercise for the reader.

Making the unset work safely (handling previous settings and signals
in BODY) and beautifully also left as an exercise."

  (setenv EMACS_EXE_VARIABLE_YOU_LIKE_BEST
          (expand-file-name invocation-name invocation-directory))
  ,@body
  (unless pollute-permanently
    (setenv EMACS_EXE_VARIABLE_YOU_LIKE_BEST nil t)))

is all you (and ert-testrunner) need, FVO "you" which are singular
(eg, "I", see quoted text above).  You could also generalize the macro
to take a string which is the full name of the executable to use.

The OP's problem is organizational, but the site-start.el method I
proposed should handle that.