bug#57556: 28.1; Eshell not finding executables in PATH when tramp-integration loaded

[Jim Porter]

On 10/1/2022 3:02 PM, Jim Porter wrote:
> On 10/1/2022 1:25 PM, Michael Albinus wrote:
> > Again, no possibility to use connection-local variables? You use them
> > already by calling (path-separator) ...
>
> I'll take a look at doing that. As I understand it, connection-local 
> variables are cleared if the associated connection gets cleaned up, 
> right? I wonder if that would be the right thing to do. For example, if 
> I cd into a remote host in Eshell, then update Eshell's $PATH for that 
> host, then clean up the connection, should the $PATH be reset to the 
> default for that host? I'm really not sure...

After a bit of trying, I wasn't able to get this to work. I was doing 
something along these lines:

  (defvar-local eshell-path-env-list nil)

  (connection-local-set-profile-variables
   'eshell-connection-local-profile
   '((eshell-path-env-list . nil)))

  (connection-local-set-profiles
   nil 'eshell-connection-local-profile)

  ;; When getting the $PATH...
  (with-connection-local-variables
   (or eshell-path-env-list
       (setq eshell-path-env-list (butlast (exec-path)))))

However, the next time I try to get the $PATH in the 
'with-connection-local-variables' block, the value is nil again, so it 
gets recomputed. I guess 'setq' inside 'with-connection-local-variables' 
doesn't work?

This is also made more complex by the fact that in an Eshell subcommand, 
we want to be able to modify the $PATH locally so that it's reset to the 
previous value after the subcommand. Since there are so many different 
things that can alter the $PATH value, making it connection-local seemed 
to be more complex in my experiments. The alist implementation is a bit 
more primitive, but I found it easier to reason through the logic. That 
could just be because I don't quite understand all the details of 
connection-local variables though.