bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not recognized as an internal or external command...

[Jim Porter]

On 8/28/2023 10:33 AM, Michael Albinus wrote:
> tramp-remote-path is just a template, It is taken the very first time
> you connect to a remote host in order to determine proper PATH
> settings. The result is cached in the connection property "remote-path".

Yeah, I believe this result is where we get the starting value for PATH 
for remote hosts. If we don't already have a cached PATH for the remote 
host in Eshell, we get it by calling '(exec-path)', which I'm guessing 
uses tramp-remote-path (at least indirectly).

> If a user changes PATH for a remote connection in eshell (I don't recall
> how, but I'm sure it is possible in Eshell), you just have to change the
> respective connection property "remote-path" in Tramp.
> See (info "(tramp) Predefined connection information")

Changing the PATH is pretty simple: just run "export PATH=blah" or "set 
PATH blah".

> There is an exception: If a user has the symbol tramp-own-remote-path
> in tramp-remote-path, the cached value is not used for a new process,
> and PATH is recomputed based on tramp-remote-path.

I think we want to handle this case too: for example, I use 
'tramp-own-remote-path' so that I can pick up my remote hosts' PATH 
values, but then I might want to change that value in Eshell later. If 
Eshell let-binds and sets 'tramp-remote-path' when starting the remote 
process, it can override the 'tramp-own-remote-path' setting 
temporarily, which I think is what we want. We'd lose the ability for 
Tramp to recompute the remote PATH on its own, but in the context of 
Eshell I think that should be ok.

> Writing this, it sounds to me too complex. OTOH, no other package has
> tried yet to play with the remote PATH. There are bug reports by users
> who request a simplification (bug#61926, bug#62326). Perhaps it is time
> to redesign the machinery in Tramp.

Yeah, this is pretty tricky code to work with on both sides (both 
Tramp/remote connections and Eshell). One option that might make sense 
is if we could pass the environment vars for the subprocess as a key in 
'make-process', like ':env'. That would let us make sure that the env 
vars are only used exactly where we want them.

For the Eshell side, I think this bug has shown that it's time to review 
how it handles environment variables in general for remote hosts. 
Another interesting bug is how we set PWD and OLDPWD to Tramp filenames 
on remote hosts. When running an external process on that host, we 
should probably use the local file name instead, since non-Emacs 
programs won't understand our remote file syntax.

I'm sure there are other bugs besides that too. Maybe the default 
behavior for env vars is that they should be connection-local (so remote 
hosts don't see your env vars), and then we can opt into passing certain 
special vars (like TERM) to all remote hosts. I'll think about this some 
more and file a bug when I have something more concrete.