Richard Copley <rcopley@gmail.com> writes:

Hi Richard,

> Thanks Michael.
>
>> Thank you for the analysis. However, I don't believe that your change is
>> correct. `buffer' is the working (output) buffer of
>> start-process-shell-command, so we shall call it here.
>
> Yes, but 'start-process-shell-command' takes care of switching to 'buffer'.

Yes. But we're already here, due to the '(with-current-buffer buffer ...'.

>> Instead, I've tried the appended patch. Could you, please, check? It
>> fixes the problem for me.
>
> It doesn't work for me. With your patch, on my system, the original
> recipe still exhibits the problem on the third invocation of
> 'async-shell-command'.
>
> At the time when '(connection-local-value shell-file-name)' is invoked
> in your patch, the current buffer is the output buffer (not the buffer
> from which the user invoked 'async-shell-command'), and the default
> directory is "/plink:xxx/" (not "c:/"), and the value returned is
> "/bin/sh" (not the file name of "cmdproxy.exe").

I hoped that the connection-local-value trick works. The
default-directory of buffer is already changed; there is '(setq
default-directory directory)' in time.

However, connection-local-value does not work as I've hoped. It simply
uses the recent (buffer-local) value, if default-directory isn't remote.

So we must kill the local value(s) explicitly. The revised patch
(appended) seems to work. Tested on my Windows 11 VM with your recipe.

Best regards, Michael.