GNU bug report logs - #17036
Continuation for Emacs: invoking a process on exit?

Previous Next

Package: emacs;

Reported by: Reuben Thomas <rrt <at> sc3d.org>

Date: Tue, 18 Mar 2014 22:48:01 UTC

Severity: wishlist

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Tue, 18 Mar 2014 22:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Reuben Thomas <rrt <at> sc3d.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 18 Mar 2014 22:48:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: Continuation for Emacs: invoking a process on exit?
Date: Tue, 18 Mar 2014 22:47:29 +0000
[Message part 1 (text/plain, inline)]
Is there a way to give Emacs itself a continuation, i.e. a command to exec
when it exits? Copious searching and cursory examination of the source code
(grepping for atexit, exit, and looking at emacs.c in some more detail)
suggest not.

This would be useful for restarting having updated my configuration (some
of which is non-idempotent), as it would save having manually to issue a
new "emacs" command having waited for it to shut down; overall, up to
several brain-seconds if I don't just sit and watch the process.

It also seems appropriately Lispy to allow a Lisp system's final action to
be to call a continuation...

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Tue, 18 Mar 2014 22:54:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Tue, 18 Mar 2014 23:52:59 +0100
Reuben Thomas <rrt <at> sc3d.org> writes:

> Is there a way to give Emacs itself a continuation, i.e. a command to exec
> when it exits?

kill-emacs-hook?

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Tue, 18 Mar 2014 22:57:01 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 17036 <at> debbugs.gnu.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Tue, 18 Mar 2014 22:56:34 +0000
[Message part 1 (text/plain, inline)]
On 18 March 2014 22:52, Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> > Is there a way to give Emacs itself a continuation, i.e. a command to
> exec
> > when it exits?
>
> kill-emacs-hook?
>

That's not a tail-call: to reexec Emacs, it needs to be a proper exec. It
might work from kill-emacs-hook, but it's surely not safe? Emacs hasn't
finished shutting down when it runs...

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Wed, 19 Mar 2014 06:28:03 GMT) Full text and rfc822 format available.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Wed, 19 Mar 2014 02:27:41 -0400
I could imagine a `restart-emacs' command having some small utility.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Wed, 19 Mar 2014 13:11:02 GMT) Full text and rfc822 format available.

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

From: Stefan <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Wed, 19 Mar 2014 09:10:41 -0400
> I could imagine a `restart-emacs' command having some small utility.

Could the w32 build support something like POSIX's `exec'?


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Wed, 19 Mar 2014 13:20:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 17036 <at> debbugs.gnu.org,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Wed, 19 Mar 2014 13:19:28 +0000
[Message part 1 (text/plain, inline)]
On 19 March 2014 13:10, Stefan <monnier <at> iro.umontreal.ca> wrote:

> > I could imagine a `restart-emacs' command having some small utility.
>
> Could the w32 build support something like POSIX's `exec'?


Windows has execvp... http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Wed, 19 Mar 2014 16:52:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Wed, 19 Mar 2014 18:51:05 +0200
> Date: Wed, 19 Mar 2014 13:19:28 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 17036 <at> debbugs.gnu.org
> 
> On 19 March 2014 13:10, Stefan <monnier <at> iro.umontreal.ca> wrote:
> 
> > > I could imagine a `restart-emacs' command having some small utility.
> >
> > Could the w32 build support something like POSIX's `exec'?
> 
> 
> Windows has execvp... http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx

Don't believe the sales people.  MS's execvp is buggy, and even if we
forget about those bugs, it won't do what is expected here: it won't
keep the file descriptors open in the original process still open in
the overlaid process.  That's because there's no 'exec' system call on
Windows, so execvp is _emulated_: the original process simply invokes
the new one as its child process, and then immediately exits.

So the answer to Stefan is: no, this cannot be done on Windows, not
without some custom code to let the re-executed Emacs inherit all of
the file descriptors which were open in the original Emacs process.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Wed, 19 Mar 2014 21:15:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Wed, 19 Mar 2014 21:14:22 +0000
[Message part 1 (text/plain, inline)]
On 19 March 2014 16:51, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Wed, 19 Mar 2014 13:19:28 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 17036 <at> debbugs.gnu.org
> >
> > On 19 March 2014 13:10, Stefan <monnier <at> iro.umontreal.ca> wrote:
> >
> > > > I could imagine a `restart-emacs' command having some small utility.
> > >
> > > Could the w32 build support something like POSIX's `exec'?
> >
> >
> > Windows has execvp...
> http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
>
> Don't believe the sales people.  MS's execvp is buggy, and even if we
> forget about those bugs, it won't do what is expected here: it won't
> keep the file descriptors open in the original process still open in
> the overlaid process.  That's because there's no 'exec' system call on
> Windows, so execvp is _emulated_: the original process simply invokes
> the new one as its child process, and then immediately exits.
>

That's good enough for restart-emacs.


> So the answer to Stefan is: no, this cannot be done on Windows, not
> without some custom code to let the re-executed Emacs inherit all of
> the file descriptors which were open in the original Emacs process.
>

It's fine for what i had in mind, namely Emacs simply launching another
command with arguments, much as a Lisp callcc. This could be documented as
a limitation on Windows.

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Thu, 20 Mar 2014 03:46:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Thu, 20 Mar 2014 05:45:18 +0200
> Date: Wed, 19 Mar 2014 21:14:22 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <schwab <at> linux-m68k.org>, 
> 	17036 <at> debbugs.gnu.org
> 
> > Don't believe the sales people.  MS's execvp is buggy, and even if we
> > forget about those bugs, it won't do what is expected here: it won't
> > keep the file descriptors open in the original process still open in
> > the overlaid process.  That's because there's no 'exec' system call on
> > Windows, so execvp is _emulated_: the original process simply invokes
> > the new one as its child process, and then immediately exits.
> >
> 
> That's good enough for restart-emacs.

Maybe so, it's hard to say, since you never described what that should
do.

> > So the answer to Stefan is: no, this cannot be done on Windows, not
> > without some custom code to let the re-executed Emacs inherit all of
> > the file descriptors which were open in the original Emacs process.
> >
> 
> It's fine for what i had in mind, namely Emacs simply launching another
> command with arguments, much as a Lisp callcc. This could be documented as
> a limitation on Windows.

I very much doubt that this limitation would not render the whole
issue moot on Windows.  E.g., how will restart-emacs then be different
from a simple call-process?  But again, since you didn't say what the
feature is supposed to do, ...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Thu, 20 Mar 2014 12:03:01 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Thu, 20 Mar 2014 12:02:49 +0000
[Message part 1 (text/plain, inline)]
On 20 March 2014 03:45, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Wed, 19 Mar 2014 21:14:22 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <
> schwab <at> linux-m68k.org>,
> >       17036 <at> debbugs.gnu.org
> >
> > > Don't believe the sales people.  MS's execvp is buggy, and even if we
> > > forget about those bugs, it won't do what is expected here: it won't
> > > keep the file descriptors open in the original process still open in
> > > the overlaid process.  That's because there's no 'exec' system call on
> > > Windows, so execvp is _emulated_: the original process simply invokes
> > > the new one as its child process, and then immediately exits.
> > >
> >
> > That's good enough for restart-emacs.
>
> Maybe so, it's hard to say, since you never described what that should
> do.
>

I didn't discuss the command (it was Glenn Morris who suggested the name),
but in my original bug report I said: "This would be useful for restarting
having updated my configuration...as it would save having manually to issue a
new 'emacs' command..." For this, a simple "exec emacs" is enough, but why
not throw in command-line arguments too.


>  I very much doubt that this limitation would not render the whole
> issue moot on Windows.  E.g., how will restart-emacs then be different
> from a simple call-process?


Because Emacs does not continue running after it exits. As I said in my
second email to this bug: "...to reexec Emacs, it needs to be a proper exec
[so that] Emacs has[...] finished shutting down when it runs."

If you simply use CallProcess (or fork/exec on POSIX systems), then the
newly-started emacs will be in contention with the old one, even if the old
one has nearly finished exiting.


>  But again, since you didn't say what the
> feature is supposed to do, ...
>

A tail-call, but for processes. (BTW, sorry to have mentioned call/cc
earlier, that was a bad analogy.)

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Thu, 20 Mar 2014 17:44:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Thu, 20 Mar 2014 19:43:31 +0200
> Date: Thu, 20 Mar 2014 12:02:49 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <schwab <at> linux-m68k.org>, 
> 	17036 <at> debbugs.gnu.org
> 
> I didn't discuss the command (it was Glenn Morris who suggested the name),
> but in my original bug report I said: "This would be useful for restarting
> having updated my configuration...as it would save having manually to issue a
> new 'emacs' command..." For this, a simple "exec emacs" is enough, but why
> not throw in command-line arguments too.

I'm probably missing something, because I don't see how "exec emacs"
will do what you want.  See below.

> >  I very much doubt that this limitation would not render the whole
> > issue moot on Windows.  E.g., how will restart-emacs then be different
> > from a simple call-process?
> 
> Because Emacs does not continue running after it exits. As I said in my
> second email to this bug: "...to reexec Emacs, it needs to be a proper exec
> [so that] Emacs has[...] finished shutting down when it runs."
> 
> If you simply use CallProcess (or fork/exec on POSIX systems), then the
> newly-started emacs will be in contention with the old one, even if the old
> one has nearly finished exiting.

What do you mean by "in contention"?  What contention do you envision?

> A tail-call, but for processes.

But AFAIU, 'exec' is not a tail-call.  It doesn't shut down the
invoking process; in particular, the atexit and on_exit handlers are
not run.  Depending on where you invoke it in Emacs, even the
kill-emacs-hook might not run.  Therefore, you cannot control whether
everything you get in an orderly shutdown, which you will then need
for the restart, will be in order.

There are also all kinds of small details, like the lock files left
behind by the original process -- the PID remains the same after
'exec', AFAIK.  Etc.

IOW, I'm not entirely sure 'exec' will do what you want.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Thu, 20 Mar 2014 23:11:01 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Thu, 20 Mar 2014 23:10:19 +0000
[Message part 1 (text/plain, inline)]
On 20 March 2014 17:43, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 20 Mar 2014 12:02:49 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <
> schwab <at> linux-m68k.org>,
> >       17036 <at> debbugs.gnu.org
> >
> > I didn't discuss the command (it was Glenn Morris who suggested the
> name),
> > but in my original bug report I said: "This would be useful for
> restarting
> > having updated my configuration...as it would save having manually to
> issue a
> > new 'emacs' command..." For this, a simple "exec emacs" is enough, but
> why
> > not throw in command-line arguments too.
>
> I'm probably missing something, because I don't see how "exec emacs"
> will do what you want.


I'm sorry, I seem to have made a total hash of explaining something really
simple. In effect, I want kill-emacs-and-exec, which takes a list of
arguments, runs kill-emacs, and then execs the argument list.

In fact, since kill-emacs can't currently take a list, it could be extended
to do so.

save-buffers-kill-emacs could be likewise extended.

Does that make sense now?
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Fri, 21 Mar 2014 07:54:03 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Fri, 21 Mar 2014 09:53:33 +0200
> Date: Thu, 20 Mar 2014 23:10:19 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <schwab <at> linux-m68k.org>, 
> 	17036 <at> debbugs.gnu.org
> 
> I'm sorry, I seem to have made a total hash of explaining something really
> simple. In effect, I want kill-emacs-and-exec, which takes a list of
> arguments, runs kill-emacs, and then execs the argument list.

As long as it does what you want, fine.  But please note that this is
not the same as exiting Emacs and starting a new session, because the
original Emacs didn't shut down all the way, and the PID is the same.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Fri, 21 Mar 2014 10:10:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Fri, 21 Mar 2014 10:09:10 +0000
[Message part 1 (text/plain, inline)]
On 21 March 2014 07:53, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 20 Mar 2014 23:10:19 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <
> schwab <at> linux-m68k.org>,
> >       17036 <at> debbugs.gnu.org
> >
> > I'm sorry, I seem to have made a total hash of explaining something
> really
> > simple. In effect, I want kill-emacs-and-exec, which takes a list of
> > arguments, runs kill-emacs, and then execs the argument list.
>
> As long as it does what you want, fine.  But please note that this is
> not the same as exiting Emacs and starting a new session, because the
> original Emacs didn't shut down all the way, and the PID is the same.
>

I think I'm still being unclear, sorry.

I am assuming that all the regular atexit handlers have already been
called, and that Emacs is really about to exit. (That is what I mean by
saying that kill-emacs has been run.) So, this could be implemented by
ensuring that the first atexit handler to be registered on startup checks a
"kill-emacs-and-exec" flag, and if it is set, does the exec.
Correspondingly, kill-emacs-and-exec would set the flag, store the
arguments in a suitable place, and then tail-call to kill-emacs.

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Fri, 21 Mar 2014 10:19:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Fri, 21 Mar 2014 12:18:34 +0200
> Date: Fri, 21 Mar 2014 10:09:10 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <schwab <at> linux-m68k.org>, 
> 	17036 <at> debbugs.gnu.org
> 
> > As long as it does what you want, fine.  But please note that this is
> > not the same as exiting Emacs and starting a new session, because the
> > original Emacs didn't shut down all the way, and the PID is the same.
> >
> 
> I think I'm still being unclear, sorry.
> 
> I am assuming that all the regular atexit handlers have already been
> called, and that Emacs is really about to exit. (That is what I mean by
> saying that kill-emacs has been run.) So, this could be implemented by
> ensuring that the first atexit handler to be registered on startup checks a
> "kill-emacs-and-exec" flag, and if it is set, does the exec.

Assuming a call to 'exec' is allowed in an atexit handler.  (I don't
know if it is.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Fri, 21 Mar 2014 10:19:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Fri, 21 Mar 2014 10:18:30 +0000
[Message part 1 (text/plain, inline)]
On 21 March 2014 10:09, Reuben Thomas <rrt <at> sc3d.org> wrote:

>
> On 21 March 2014 07:53, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > Date: Thu, 20 Mar 2014 23:10:19 +0000
>> > From: Reuben Thomas <rrt <at> sc3d.org>
>> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <
>> schwab <at> linux-m68k.org>,
>> >       17036 <at> debbugs.gnu.org
>> >
>> > I'm sorry, I seem to have made a total hash of explaining something
>> really
>> > simple. In effect, I want kill-emacs-and-exec, which takes a list of
>> > arguments, runs kill-emacs, and then execs the argument list.
>>
>> As long as it does what you want, fine.  But please note that this is
>> not the same as exiting Emacs and starting a new session, because the
>> original Emacs didn't shut down all the way, and the PID is the same.
>>
>
> I think I'm still being unclear, sorry.
>
> I am assuming that all the regular atexit handlers have already been
> called, and that Emacs is really about to exit. (That is what I mean by
> saying that kill-emacs has been run.) So, this could be implemented by
> ensuring that the first atexit handler to be registered on startup checks a
> "kill-emacs-and-exec" flag, and if it is set, does the exec.
> Correspondingly, kill-emacs-and-exec would set the flag, store the
> arguments in a suitable place, and then tail-call to kill-emacs.
>

And if there is a problem with keeping the same PID, or with file
descriptors still being open, or any other kind of resource that is
released on process exit, then by all means have the atexit handler
mentioned above fork().

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Fri, 21 Mar 2014 10:27:01 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Fri, 21 Mar 2014 10:25:54 +0000
[Message part 1 (text/plain, inline)]
On 21 March 2014 10:18, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Fri, 21 Mar 2014 10:09:10 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Andreas Schwab <
> schwab <at> linux-m68k.org>,
> >       17036 <at> debbugs.gnu.org
> >
> > > As long as it does what you want, fine.  But please note that this is
> > > not the same as exiting Emacs and starting a new session, because the
> > > original Emacs didn't shut down all the way, and the PID is the same.
> > >
> >
> > I think I'm still being unclear, sorry.
> >
> > I am assuming that all the regular atexit handlers have already been
> > called, and that Emacs is really about to exit. (That is what I mean by
> > saying that kill-emacs has been run.) So, this could be implemented by
> > ensuring that the first atexit handler to be registered on startup
> checks a
> > "kill-emacs-and-exec" flag, and if it is set, does the exec.
>
> Assuming a call to 'exec' is allowed in an atexit handler.  (I don't
> know if it is.)
>

The only restrictions I can find are that a) if an atexit handler calls
_exit, the remaining handlers are not called; b) if the process is
terminated by a signal, the handlers are not called. The only thing you
can't do is call exit() or longjmp(). You can even call "atexit" from an
atexit handler (the new handler is pushed on the front of the remaining
queue).

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 11:39:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 17036 <at> debbugs.gnu.org,
 Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 13:38:10 +0200
Glenn Morris <rgm <at> gnu.org> writes:

> I could imagine a `restart-emacs' command having some small utility.

I've now added this command to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 17036 <at> debbugs.gnu.org and Reuben Thomas <rrt <at> sc3d.org> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 17 Apr 2022 11:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 11:57:02 GMT) Full text and rfc822 format available.

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

From: Reuben Thomas <rrt <at> sc3d.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, Andreas Schwab <schwab <at> linux-m68k.org>,
 17036 <at> debbugs.gnu.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 12:56:20 +0100
[Message part 1 (text/plain, inline)]
Thanks for this! I look forward to it.

--
https://rrt.sc3d.org

On Sun, 17 Apr 2022, 12:38 Lars Ingebrigtsen, <larsi <at> gnus.org> wrote:

> Glenn Morris <rgm <at> gnu.org> writes:
>
> > I could imagine a `restart-emacs' command having some small utility.
>
> I've now added this command to Emacs 29.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 11:59:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 14:57:58 +0300
> Resent-From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 17 Apr 2022 13:38:10 +0200
> Cc: 17036 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>,
>  Reuben Thomas <rrt <at> sc3d.org>
> 
> Glenn Morris <rgm <at> gnu.org> writes:
> 
> > I could imagine a `restart-emacs' command having some small utility.
> 
> I've now added this command to Emacs 29.

As implemented, it won't work reliably on MS-Windows, because execvp
there doesn't do what you think it should.  I think we should use
sys_spawnve instead.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 12:10:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 14:08:49 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> As implemented, it won't work reliably on MS-Windows, because execvp
> there doesn't do what you think it should.  I think we should use
> sys_spawnve instead.

Ah, I grepped for execvp to see whether we already used it, but didn't
notice that the hits were from Gnulib.

I'm not familiar with sys_spawnve -- can you do the adjustments?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 12:36:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 15:34:55 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> Date: Sun, 17 Apr 2022 14:08:49 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > As implemented, it won't work reliably on MS-Windows, because execvp
> > there doesn't do what you think it should.  I think we should use
> > sys_spawnve instead.
> 
> Ah, I grepped for execvp to see whether we already used it, but didn't
> notice that the hits were from Gnulib.
> 
> I'm not familiar with sys_spawnve -- can you do the adjustments?

I don't think I will have the time.  It isn't a simple job, because
just calling sys_spawnve will not do -- that function currently
supports only Emacs sub-processes.

FTR, I will document below the potential issues with the current
implementation of kill-emacs/restart-emacs:

  . when kill-emacs is called with RESTART non-nil, the value of ARG
    is ignored; this should at least be documented;
  . the exit status of the restarted Emacs is discarded, so it will
    not be available to the parent program, at least on MS-Windows,
    and also if execvp fails for some reason;
  . the semantics of the file descriptors open in the original Emacs
    process is not clear to me: will they remain open in the restarted
    Emacs, if the original Emacs opened them without CLOEXEC?
  . does the restarted Emacs belong to the same process group? should
    it?
  . on MS-Windows, if any of the argv[] command-line arguments have
    embedded whitespace, the restarted Emacs will not get the same
    elements in its argv[] array, because the Windows API for starting
    processes accepts the command-line arguments as a single string




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 12:42:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 15:41:06 +0300
> Resent-From: Eli Zaretskii <eliz <at> gnu.org>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Date: Sun, 17 Apr 2022 15:34:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rgm <at> gnu.org, 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, rrt <at> sc3d.org
> 
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> > Date: Sun, 17 Apr 2022 14:08:49 +0200
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > As implemented, it won't work reliably on MS-Windows, because execvp
> > > there doesn't do what you think it should.  I think we should use
> > > sys_spawnve instead.
> > 
> > Ah, I grepped for execvp to see whether we already used it, but didn't
> > notice that the hits were from Gnulib.
> > 
> > I'm not familiar with sys_spawnve -- can you do the adjustments?
> 
> I don't think I will have the time.  It isn't a simple job, because
> just calling sys_spawnve will not do -- that function currently
> supports only Emacs sub-processes.
> 
> FTR, I will document below the potential issues with the current
> implementation of kill-emacs/restart-emacs:
> 
>   . when kill-emacs is called with RESTART non-nil, the value of ARG
>     is ignored; this should at least be documented;
>   . the exit status of the restarted Emacs is discarded, so it will
>     not be available to the parent program, at least on MS-Windows,
>     and also if execvp fails for some reason;
>   . the semantics of the file descriptors open in the original Emacs
>     process is not clear to me: will they remain open in the restarted
>     Emacs, if the original Emacs opened them without CLOEXEC?
>   . does the restarted Emacs belong to the same process group? should
>     it?
>   . on MS-Windows, if any of the argv[] command-line arguments have
>     embedded whitespace, the restarted Emacs will not get the same
>     elements in its argv[] array, because the Windows API for starting
>     processes accepts the command-line arguments as a single string

And one more:

  . my reading of the code in 'main' is that the argv[] array is
    sorted as it is processed, so the restarted Emacs will get the
    arguments in a different order (not that it should matter too
    much, I think, but still: it isn't exactly the same invocation)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 12:50:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 14:49:23 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>   . when kill-emacs is called with RESTART non-nil, the value of ARG
>     is ignored; this should at least be documented;

Emacs doesn't exit, so I thought it would be self-evident that ARG
(which is all about the exit code) is ignored.

>   . the exit status of the restarted Emacs is discarded, so it will
>     not be available to the parent program, at least on MS-Windows,
>     and also if execvp fails for some reason;

Again, Emacs doesn't exit, so...

>   . the semantics of the file descriptors open in the original Emacs
>     process is not clear to me: will they remain open in the restarted
>     Emacs, if the original Emacs opened them without CLOEXEC?

I thought we opened all file descriptors with CLOEXEC?  If not, that's a
bug, since we'd be leaking file descriptors to programs we start with
`call-process', for instance.

>   . does the restarted Emacs belong to the same process group? should
>     it?

I think so, and I guess so?

>   . on MS-Windows, if any of the argv[] command-line arguments have
>     embedded whitespace, the restarted Emacs will not get the same
>     elements in its argv[] array, because the Windows API for starting
>     processes accepts the command-line arguments as a single string

Sounds like we should just document that this doesn't work on Windows,
then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 12:53:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 14:52:41 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> And one more:
>
>   . my reading of the code in 'main' is that the argv[] array is
>     sorted as it is processed, so the restarted Emacs will get the
>     arguments in a different order (not that it should matter too
>     much, I think, but still: it isn't exactly the same invocation)

Hm, so we do (in sort_args), so I guess we should store the real argv
somewhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 14:30:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 17:29:20 +0300
> Date: Sun, 17 Apr 2022 15:34:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rgm <at> gnu.org, 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, rrt <at> sc3d.org
> 
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> > Date: Sun, 17 Apr 2022 14:08:49 +0200
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > As implemented, it won't work reliably on MS-Windows, because execvp
> > > there doesn't do what you think it should.  I think we should use
> > > sys_spawnve instead.
> > 
> > Ah, I grepped for execvp to see whether we already used it, but didn't
> > notice that the hits were from Gnulib.
> > 
> > I'm not familiar with sys_spawnve -- can you do the adjustments?
> 
> I don't think I will have the time.  It isn't a simple job, because
> just calling sys_spawnve will not do -- that function currently
> supports only Emacs sub-processes.

I eventually had an implementation idea that is much simpler than the
above, so I went ahead and implemented it.  It currently doesn't work
in a -nw session, I hope to debug that later.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 14:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 17:37:53 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> Date: Sun, 17 Apr 2022 14:49:23 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >   . when kill-emacs is called with RESTART non-nil, the value of ARG
> >     is ignored; this should at least be documented;
> 
> Emacs doesn't exit, so I thought it would be self-evident that ARG
> (which is all about the exit code) is ignored.

Let's see how evident is it ;-)

> >   . the exit status of the restarted Emacs is discarded, so it will
> >     not be available to the parent program, at least on MS-Windows,
> >     and also if execvp fails for some reason;
> 
> Again, Emacs doesn't exit, so...

I meant when the restarted Emacs exits.  It _can_ exit, can't it?

> >   . the semantics of the file descriptors open in the original Emacs
> >     process is not clear to me: will they remain open in the restarted
> >     Emacs, if the original Emacs opened them without CLOEXEC?
> 
> I thought we opened all file descriptors with CLOEXEC?  If not, that's a
> bug, since we'd be leaking file descriptors to programs we start with
> `call-process', for instance.

What about stadin/stdout/stderr etc.?

> >   . does the restarted Emacs belong to the same process group? should
> >     it?
> 
> I think so, and I guess so?

Is that guaranteed? should we make sure it's so?  Or is it
unimportant?

> >   . on MS-Windows, if any of the argv[] command-line arguments have
> >     embedded whitespace, the restarted Emacs will not get the same
> >     elements in its argv[] array, because the Windows API for starting
> >     processes accepts the command-line arguments as a single string
> 
> Sounds like we should just document that this doesn't work on Windows,
> then.

It works now, at least in the GUI sessions.

Some other questions related to this:

  . AFAIU, the execvp'ed process inherits the environment of the
    calling process, so any changes to the environment will be
    propagated to the child, right?  Do we want that?

  . What about the working directory?  If the original Emacs was
    invoked with --chdir, the restart happens in another directory;
    moreover, relative program name in argv[0] and relative directory
    name in --chdir may not work.  Is that a problem?

  . What should happen to client frames when Emacs is restarted?  What
    does happen with the current implementation, .e.g if some of the
    client frames are on other displays?

A lot of this stuff has to do with the semantics of "restarting"
Emacs: what exactly does that mean, and what should users expect/not
expect when they restart Emacs?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 14:50:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 16:49:42 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> >   . the exit status of the restarted Emacs is discarded, so it will
>> >     not be available to the parent program, at least on MS-Windows,
>> >     and also if execvp fails for some reason;
>> 
>> Again, Emacs doesn't exit, so...
>
> I meant when the restarted Emacs exits.  It _can_ exit, can't it?

If you exit from the new process, then you'll get the exit code from
that next call to `kill-emacs'?

>> I thought we opened all file descriptors with CLOEXEC?  If not, that's a
>> bug, since we'd be leaking file descriptors to programs we start with
>> `call-process', for instance.
>
> What about stadin/stdout/stderr etc.?

Those are inherited, I think.  (Which is good.)

>> >   . does the restarted Emacs belong to the same process group? should
>> >     it?
>> 
>> I think so, and I guess so?
>
> Is that guaranteed? should we make sure it's so?  Or is it
> unimportant?

I think that whatever the OS does here by default is what's correct, so
it's not something we need to worry about.

>> Sounds like we should just document that this doesn't work on Windows,
>> then.
>
> It works now, at least in the GUI sessions.

Great!

> Some other questions related to this:
>
>   . AFAIU, the execvp'ed process inherits the environment of the
>     calling process, so any changes to the environment will be
>     propagated to the child, right?  Do we want that?

I'm not quite sure.  We could save envp and call execve instead with
that saved envp (I think?), but I think using the environment is what we
want here.  Probably?  But perhaps that should be an option...

>   . What about the working directory?  If the original Emacs was
>     invoked with --chdir, the restart happens in another directory;
>     moreover, relative program name in argv[0] and relative directory
>     name in --chdir may not work.  Is that a problem?

Ah, yes it is.  --chdir and relative names stops this from working, so
that needs fixing, I think. 

>   . What should happen to client frames when Emacs is restarted?  What
>     does happen with the current implementation, .e.g if some of the
>     client frames are on other displays?

I expect those to disappear.  We're restarting Emacs, after all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 15:53:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 18:51:39 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> Date: Sun, 17 Apr 2022 16:49:42 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >   . the exit status of the restarted Emacs is discarded, so it will
> >> >     not be available to the parent program, at least on MS-Windows,
> >> >     and also if execvp fails for some reason;
> >> 
> >> Again, Emacs doesn't exit, so...
> >
> > I meant when the restarted Emacs exits.  It _can_ exit, can't it?
> 
> If you exit from the new process, then you'll get the exit code from
> that next call to `kill-emacs'?

Do you see that returned to the shell?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 15:59:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 18:58:05 +0300
> Date: Sun, 17 Apr 2022 17:29:20 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: rgm <at> gnu.org, 17036 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, rrt <at> sc3d.org
> 
> I eventually had an implementation idea that is much simpler than the
> above, so I went ahead and implemented it.  It currently doesn't work
> in a -nw session, I hope to debug that later.

The problems in the -nw session have something top do with the parent
releasing the console device and the restarted child attaching to it;
I'm unable to get that to work (not really surprising, as I know very
little about the subtleties of the Windows console sharing).  So for
now I just made restart-emacs fail in the -nw case on MS-Windows.

Btw, calling 'error' in this place, which we also do on Posix
platforms, is not very useful: this is past the call to
shut_down_emacs, so all 'error' does at this point is exit with an
error status, and the error message is lost.  Something to keep in
mind, I guess.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 16:03:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 18:02:15 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> Btw, calling 'error' in this place, which we also do on Posix
> platforms, is not very useful: this is past the call to
> shut_down_emacs, so all 'error' does at this point is exit with an
> error status, and the error message is lost.  Something to keep in
> mind, I guess.

It prints the error message OK on Debian, at least, but I guess
emacs_perror is the function to use here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Sun, 17 Apr 2022 17:50:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 20:49:09 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> Date: Sun, 17 Apr 2022 18:02:15 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Btw, calling 'error' in this place, which we also do on Posix
> > platforms, is not very useful: this is past the call to
> > shut_down_emacs, so all 'error' does at this point is exit with an
> > error status, and the error message is lost.  Something to keep in
> > mind, I guess.
> 
> It prints the error message OK on Debian, at least, but I guess
> emacs_perror is the function to use here?

I guess so.  Although that will be lost as well if Emacs is invoked as
a GUI program from some desktop shortcut or in some other fancy way
which redirects the standard handles to the great void...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Mon, 18 Apr 2022 08:49:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Mon, 18 Apr 2022 10:48:17 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> If you exit from the new process, then you'll get the exit code from
>> that next call to `kill-emacs'?
>
> Do you see that returned to the shell?

When you finally exit (without restarting), the function returns the
same value as always, so I think I must be misunderstanding what you
mean here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Mon, 18 Apr 2022 08:54:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Mon, 18 Apr 2022 10:53:20 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> I guess so.  Although that will be lost as well if Emacs is invoked as
> a GUI program from some desktop shortcut or in some other fancy way
> which redirects the standard handles to the great void...

Yup, but we've already shut down Emacs at this point, so I don't think
we can do much more.

But there is one check we could do at a more meaningful point: We could
check whether argv[0] points to a binary that exists at the start of
`kill-emacs' and then signal an error.  That will probably be the (by
far) most common problem in practice, so it's worth doing that, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17036; Package emacs. (Mon, 18 Apr 2022 09:30:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, schwab <at> linux-m68k.org, 17036 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Mon, 18 Apr 2022 12:28:28 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rgm <at> gnu.org,  17036 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org,  rrt <at> sc3d.org
> Date: Mon, 18 Apr 2022 10:48:17 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> If you exit from the new process, then you'll get the exit code from
> >> that next call to `kill-emacs'?
> >
> > Do you see that returned to the shell?
> 
> When you finally exit (without restarting), the function returns the
> same value as always, so I think I must be misunderstanding what you
> mean here.

I was just asking whether this was checked and worked correctly.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 16 May 2022 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 340 days ago.

Previous Next


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