GNU bug report logs - #77389
31.0.50; Restarting Emacs with (kill-emacs ... t) looses noninteractivity

Previous Next

Package: emacs;

Reported by: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>

Date: Sun, 30 Mar 2025 17:22:01 UTC

Severity: normal

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77389 <at> debbugs.gnu.org
Subject: Re: bug#77389: 31.0.50; Restarting Emacs with (kill-emacs ... t)
 looses noninteractivity
Date: Tue, 1 Apr 2025 22:52:48 +0200
[Message part 1 (text/plain, inline)]
On 2025-03-30  20:29, Eli Zaretskii wrote:
>> Date: Sun, 30 Mar 2025 19:20:58 +0200
>> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> [ Disclaimer:
>>
>>   - This is one of my more exotic bug reports, so I won't argue
>>     (at least not much) if you close this as "won't fix".
>>
>>   - In particular since an Emacs restart, added by Lars in
>>     5be9a9ca, probably has only been meant to be used
>>     interactively.
>>
>>   - But I do have a valid use case for a non-interactive restart,
>>     so I created this bug report ... ]
> 
> Please describe your use case.

TL;DR:

1. Start foo.el in batch mode with "emacs --script foo.el".
2. foo.el reads the user init file and writes a modified copy of
   it to init-new.el.
3. Then foo.el calls (kill-emacs ... t), thus restarting itself,
   (hopefully) still in batch mode.
4. The newly started foo.el senses the presence of init-new.el
   and, hence, processes that in a final step.

In the above it is important that steps 2 and 4 are executed
from different, newly started Emacs processes which share STDOUT
and STDERR.

The bigger picture is my package bc-dot-emacs.el

  bc-dot-emacs.el --- Check Emacs init file syntax

  https://git.sr.ht/~jschmidt/bc-dot-emacs

which I sooner or later wanted to present on emacs-devel for
inclusion to ELPA.

>> Probably Fkill_emacs should call execvp not on the command line
>> arguments in initial_argv, which already got modified by main,
>> but on a copy of the *real* initial command line arguments as
>> they have been passed into main?
> 
> Yes.  And on MS-Windows, it already does.

Indeed, I missed that bit.  The only other non-Posix case seems
to be Android, which a) IIRC does not support non-interactive
operation and b) restarts Emacs with some mechanism in Java-land
that does not require Emacs itself to keep a copy of the initial
arguments.

So this leaves the Posix/execvp case, I think, which I hope to
have covered in the attached patch.

The only thing that bothers me a bit is that there is the following
memory-related initialization being executed in main *after*
copy_raw_args (or also the present sort_args) have already been
allocating memory:

#if !defined SYSTEM_MALLOC
  /* Arrange to get warning messages as memory fills up.  */
  memory_warnings (0, malloc_warning);

  /* Call malloc at least once, to run malloc_initialize_hook.
     Also call realloc and free for consistency.  */
  free (realloc (malloc (4), 4));

#endif	/* not SYSTEM_MALLOC */

Thanks.
[0001-Use-raw-argv-as-passed-into-main-to-restart-Emacs.patch (text/x-patch, attachment)]

This bug report was last modified 41 days ago.

Previous Next


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