From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#17036: Continuation for Emacs: invoking a process on exit? Date: Thu, 20 Mar 2014 12:02:49 +0000 Message-ID: References: <874n2v9l10.fsf@igel.home> <8361na9lom.fsf@gnu.org> <83r45x8re9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf301af33553288204f5088c3a X-Trace: ger.gmane.org 1395316992 9138 80.91.229.3 (20 Mar 2014 12:03:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 12:03:12 +0000 (UTC) Cc: Andreas Schwab , 17036@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 20 13:03:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQbgp-0004de-S3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Mar 2014 13:03:16 +0100 Original-Received: from localhost ([::1]:46600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQbgp-0006qG-20 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Mar 2014 08:03:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQbgh-0006q3-PP for bug-gnu-emacs@gnu.org; Thu, 20 Mar 2014 08:03:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQbgd-0006be-18 for bug-gnu-emacs@gnu.org; Thu, 20 Mar 2014 08:03:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQbgc-0006ao-TL for bug-gnu-emacs@gnu.org; Thu, 20 Mar 2014 08:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WQbgc-0002Rx-1Y for bug-gnu-emacs@gnu.org; Thu, 20 Mar 2014 08:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Mar 2014 12:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17036 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17036-submit@debbugs.gnu.org id=B17036.13953169759398 (code B ref 17036); Thu, 20 Mar 2014 12:03:01 +0000 Original-Received: (at 17036) by debbugs.gnu.org; 20 Mar 2014 12:02:55 +0000 Original-Received: from localhost ([127.0.0.1]:41924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WQbgU-0002RV-3I for submit@debbugs.gnu.org; Thu, 20 Mar 2014 08:02:54 -0400 Original-Received: from mail-yh0-f53.google.com ([209.85.213.53]:58073) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WQbgQ-0002RI-Je for 17036@debbugs.gnu.org; Thu, 20 Mar 2014 08:02:52 -0400 Original-Received: by mail-yh0-f53.google.com with SMTP id v1so637808yhn.26 for <17036@debbugs.gnu.org>; Thu, 20 Mar 2014 05:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1dnR/rUEkfw5DmTAHYvx6XPJNkGNxFULfHqF4FvGAfc=; b=LhRWRCQGbEuAXI9XZrLaX8MvT8GJPuNIFhpbNeAJMYFibwEBx4hIR2xlu1s/XWe+0T ZpuqmpCq2TJl7O036y8jXgjXfqvKRq6laGfCulbYymXquFgZ1c3kb+T3UoU8aqj5rZ+S X9PZsjhAqCiypphB8Ub3td4kQAZuxZ3e3AeIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1dnR/rUEkfw5DmTAHYvx6XPJNkGNxFULfHqF4FvGAfc=; b=azqLTP6fkaPnjGWY7857Yv7nWGGKKwG2ADAqk4rBwWAhTYextTGJlnTbyiManbq1Gi PHxTYXOMck+XFkhnI0hifvgdcyMsC/LwMP0tULXbpZnGejtk84nNBg45qVr9Leu9Yd92 UDAmCmVlqaM1XoZjeH7L8dS5VHaX7yKFfdApb4gVVjuYYNVnGd1MtIsGIRMJOoHmAR25 yk5Y6SLIND12DL3A0ZSGIm8IHA2hnyDIN6f6pNmAZB3WTvGTSCHNdEinsyePC6CoYlUV BhXasIdkGfDGJ85dmKlBAeAymm1A3k7txq61R7XqqLBr8IIktVtLECMAYA71Ot9b6/YA A7dg== X-Gm-Message-State: ALoCoQknuD0pwdNxz7hKH3JAI1xqauoo/9tsnEXghKCZXFZNZWGQdQKzuTAMdkCyDoZI1GlHDVZh X-Received: by 10.236.122.99 with SMTP id s63mr34468581yhh.19.1395316969633; Thu, 20 Mar 2014 05:02:49 -0700 (PDT) Original-Received: by 10.170.137.66 with HTTP; Thu, 20 Mar 2014 05:02:49 -0700 (PDT) In-Reply-To: <83r45x8re9.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:87009 Archived-At: --20cf301af33553288204f5088c3a Content-Type: text/plain; charset=ISO-8859-1 On 20 March 2014 03:45, Eli Zaretskii wrote: > > Date: Wed, 19 Mar 2014 21:14:22 +0000 > > From: Reuben Thomas > > Cc: Stefan Monnier , Andreas Schwab < > schwab@linux-m68k.org>, > > 17036@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 --20cf301af33553288204f5088c3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2= 0 March 2014 03:45, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Wed, 19 Mar 2014 21:14:22 +0000
> From: Reuben Thomas <rrt@sc3d.org>
> Cc: Stefan Monnier <
mon= nier@iro.umontreal.ca>, Andreas Schwab <schwab@linux-m68k.org>,
>       17036@de= bbugs.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: i= t won't
> > keep the file descriptors open in the original process still open= in
> > the overlaid process.  That's because there's no = 9;exec' system call on
> > Windows, so execvp is _emulated_: the original process simply inv= okes
> > 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 s= hould
do.

I didn't discuss the command (i= t was Glenn Morris who suggested the name), but in my original bug report I= said: "This would be useful for restarting having updated my configur= ation…as it would save having manually to=20 issue a new 'emacs' command…" F= or this, a simple "exec emacs" is enough, but why not throw in co= mmand-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 d= oes not continue running after it exits. As I said in my second email to th= is bug: "…to reexec Emacs, it needs to be a proper exec [so tha= t] Emacs=20 has[…] finished shutting down when it runs."

= If you simply use CallProcess (or fork/exec on POSIX systems), then the new= ly-started emacs will be in contention with the old one, even if the old on= e has nearly finished exiting.
 
&= nbsp;But again, since you didn't say what the
feature is supposed to do, ...

A tail-call, but fo= r processes. (BTW, sorry to have mentioned call/cc earlier, that was a bad = analogy.)
--20cf301af33553288204f5088c3a--