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

From: Jim Porter <[email-masked]>
Date: Sat, 1 Oct 2022 22:34:50 -0700

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.