Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

>> Second, I've played a little bit on MS Windows. I haven't installed
>> Emacs 29 there, just an Emacs git master checkout. And plink is not in
>> the PATH of my MINGW64 bash shell, so I'm using sshx. But everything
>> works under this constellation:
>
> I'm using sshx locally to test this, and can reproduce the
> issue. Maybe your MINGW64 configuration is smoothing over the bug for
> you. When I tested this, I started from the MS-Windows "cmd.exe" and
> ran "emacs -Q", with "ssh.exe" in my PATH.

Yes, with this scenario I see the problem as well.

> In Emacs 28, this worked fine, but it regressed in 29. I believe this
> is due to commit cee1cbfd54375cdece23d4741ced6b0c7091f6d9, which
> changes how Eshell manages its PATH env var.
>
> I think what Eshell would want here is to set its environment
> variables *only* for the subprocess it creates via 'make-process'. For
> local subprocesses, I don't think we need to do anything fancy, but
> for the remote case, we'd need a way to say "use the original
> process-environment for all the Tramp code, but use this new
> process-environment for the actual subprocess". Maybe there's already
> a way to do this, or maybe we need to add some new powers to
> 'make-process' or something...

AFAICS, the problem is in eshell-environment-variables, which sets PATH
to the remote path. There are good reasons that Tramp doesn't handle the
PATH environment variable, but uses its own tramp-remote-path variable.

I've applied the following sledge-hammer patch, which cures the problem
for me. But I'm pretty sure there are better ways in Eshell to fix this.

Best regards, Michael.