From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: rgm@gnu.org, 17036@debbugs.gnu.org, schwab@linux-m68k.org, rrt@sc3d.org
Subject: bug#17036: Continuation for Emacs: invoking a process on exit?
Date: Sun, 17 Apr 2022 17:37:53 +0300 [thread overview]
Message-ID: <83sfqbydvi.fsf@gnu.org> (raw)
In-Reply-To: <87wnfn98oc.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 17 Apr 2022 14:49:23 +0200)
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rgm@gnu.org, 17036@debbugs.gnu.org, schwab@linux-m68k.org, rrt@sc3d.org
> Date: Sun, 17 Apr 2022 14:49:23 +0200
>
> Eli Zaretskii <eliz@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?
next prev parent reply other threads:[~2022-04-17 14:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 22:47 bug#17036: Continuation for Emacs: invoking a process on exit? Reuben Thomas
2014-03-18 22:52 ` Andreas Schwab
2014-03-18 22:56 ` Reuben Thomas
2014-03-19 6:27 ` Glenn Morris
2014-03-19 13:10 ` Stefan
2014-03-19 13:19 ` Reuben Thomas
2014-03-19 16:51 ` Eli Zaretskii
2014-03-19 21:14 ` Reuben Thomas
2014-03-20 3:45 ` Eli Zaretskii
2014-03-20 12:02 ` Reuben Thomas
2014-03-20 17:43 ` Eli Zaretskii
2014-03-20 23:10 ` Reuben Thomas
2014-03-21 7:53 ` Eli Zaretskii
2014-03-21 10:09 ` Reuben Thomas
2014-03-21 10:18 ` Reuben Thomas
2014-03-21 10:18 ` Eli Zaretskii
2014-03-21 10:25 ` Reuben Thomas
2022-04-17 11:38 ` Lars Ingebrigtsen
2022-04-17 11:56 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-17 11:57 ` Eli Zaretskii
2022-04-17 12:08 ` Lars Ingebrigtsen
2022-04-17 12:34 ` Eli Zaretskii
2022-04-17 12:41 ` Eli Zaretskii
2022-04-17 12:52 ` Lars Ingebrigtsen
2022-04-17 12:49 ` Lars Ingebrigtsen
2022-04-17 14:37 ` Eli Zaretskii [this message]
2022-04-17 14:49 ` Lars Ingebrigtsen
2022-04-17 15:51 ` Eli Zaretskii
2022-04-18 8:48 ` Lars Ingebrigtsen
2022-04-18 9:28 ` Eli Zaretskii
2022-04-17 14:29 ` Eli Zaretskii
2022-04-17 15:58 ` Eli Zaretskii
2022-04-17 16:02 ` Lars Ingebrigtsen
2022-04-17 17:49 ` Eli Zaretskii
2022-04-18 8:53 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sfqbydvi.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=17036@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=rgm@gnu.org \
--cc=rrt@sc3d.org \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.