GNU bug report logs - #76888
31.0.50; start-process: Spawning child process: Invalid argument

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: rcopley <at> gmail.com, 76888 <at> debbugs.gnu.org
Subject: Re: bug#76888: 31.0.50; start-process: Spawning child process:
 Invalid argument
Date: Mon, 17 Mar 2025 16:35:14 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Richard Copley <rcopley <at> gmail.com>,  76888 <at> debbugs.gnu.org
> Date: Mon, 17 Mar 2025 10:01:03 +0100
> 
> It seems to me that the problem is rather the re-use of the "*Async
> Shell Command*" buffer even in case the default-directory changes. It
> isn't a problem if this change is inside the same "remote" file system
> Tramp offers virtually. But if the change means, that another remote
> connection is established, or there is a change between remote and local
> directory, I propose to use another (new) "*Async Shell Command*" buffer.

We could reuse the buffer, but kill all its local variables, no?

But I feel that I still don't understand how this problem happens.
Can you take me through the steps of processing M-&, and explain how
come the buffer-local value of "*Async Shell Command*" gets to be used
for M-& in this scenario?  In particular, even if the buffer is
reused, why don't we re-calculate the local value of shell-file-name
every invocation of a shell command? why cache it?

Previous Next

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