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

Previous Next

Full log

View this message in rfc822 format

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 76888 <at> debbugs.gnu.org
Subject: bug#76888: 31.0.50; start-process: Spawning child process: Invalid argument
Date: Sun, 16 Mar 2025 08:47:35 +0000

On Sun, 16 Mar 2025 at 08:21, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Cc: 76888 <at> debbugs.gnu.org
> > Date: Sat, 15 Mar 2025 13:48:10 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
>
> Trying this recipe, I have some questions and observations.
>
> > > From: Richard Copley <rcopley <at> gmail.com>
> > > Date: Sun, 9 Mar 2025 12:37:56 +0000
> > >
> > > When the "*Async Shell Command*" buffer is re-used, its
> > > connection-local variable 'shell-file-name' is set permanently instead
> > > of temporarily, and if the value is inappropriate, an error ensues.
>
> I'm not sure this is relevant, see below.  Or if it _is_ relevant, I
> don't think I understand why the value of shell-file-name in the
> "*Async Shell Command*" buffer matters.

There are two factors, the combination of which leads to the problem.

The first factor is that the value of shell-file-name sometimes gets
set buffer-locally in the "*Async Shell Command*" buffer. (This is
true for the Tramp code, when the buffer is reused. I don't know if it
is meaningful to ask whether it is true for the non-Tramp code.)

The second factor is that 'async-shell-command' sometimes uses the
value of shell-file-name from the "*Async Shell Command*" buffer.
(This is true for the non-Tramp code. I don't know if it is true for
the Tramp code.)

If we were to arrange for at least one of those factors to be no
longer true, the problem would go away.

Which one should we target? I make no recommendation. But, for
example, if we target the second factor, we could kill all buffer
local variables in the "*Async Shell Command*" buffer somewhere near
the beginning of the code path that is followed when
'async-shell-command' is invoked. This would need to be done in the
non-Tramp code. I don't know if it would need to be done in the Tramp
code.

All of this may also apply to 'shell-command'. I did not investigate.

> > > Recipe from 'emacs -Q', on Windows:
> > >
> > > Visit a remote file on a Linux system using tramp. (You will need to
> > > substitute an appropriate remote file name here.)
> > >
> > > [C-x C-f] /plink:xxx:/ [RET]
>
> This shows the remote file on display.
>
> > > Execute an asynchronous shell command.
> > >
> > > [M-&] echo [RET]
>
> This command should run on the remote host, because the
> default-directory is remote, due to the current-buffer visiting a
> remote file, per the above "C-x C-f" command.
>
> Is that what you see?  Does the "echo" command run on the remote host?

Yes.

> > > NOTE: (with-current-buffer "*Async Shell Command*" shell-file-name)
> > > returns the path to "cmdproxy.exe" as expected.
> > >
> > > Execute an asynchronous shell command again.
> > >
> > > [M-&] echo [RET]
> > >
> > > NOTE: (with-current-buffer "*Async Shell Command*" shell-file-name)
> > > now returns "/bin/sh".
> > >
> > > Visit a local file.
> > >
> > > [C-x C-f C-a C-k] C:/ [RET]
>
> Now the local file is shown in the selected window, and the current
> buffer visits that file, so its default-directory is local.
>
> > > Execute an async shell command.
> > >
> > > [M-&] echo [RET]
>
> This command should run locally, because default-directory is local.
> Is that what you see?

Yes.

> > > An error is signalled, with the message "start-process: Spawning child
> > > process: Invalid argument". (Note, the invalid argument is the
> > > executable name, "/bin/sh").
>
> In my case, the error message dosn't pop up each time, but I do see it
> from time to time.
>
> Michael, does Tramp reuse the value of shell-file-name between shell
> commands, and if so, how does it know whether to reuse or not?

Previous Next

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