Subject: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection

From: Jim Porter <[email-masked]>
Date: Mon, 6 May 2024 19:01:11 -0700

On 5/6/2024 1:05 PM, Jim Porter wrote:
> Before I respond to the initial points, I wanted to emphasize one part 
> first: my patch is intended to make Eshell behave more like other shells 
> and to simplify how users can perform "common" tasks. By "common", I 
> mean specifically that, when you've started a remote "session" (by 
> cd'ing into a remote host), normal filenames all refer to something on 
> that host, just like if you used SSH on a terminal. To refer to 
> something on another host, you use remote file name syntax (or /:quoted 
> file name syntax to explicitly refer to a local file[1]).
> 
> Also, even with this option, absolutely nothing changes about how Eshell 
> works when the current directory is local.

One final point I'd like to make here is that this new (opt-in) behavior 
to treat "absolute" file names relative to the current remote connection 
already has precedent in Eshell. It's how Eshell looks for *commands* 
(as far as I know, it's always been this way). That means that 
"/bin/whoami" is the local whoami if the cwd is local, but it's the 
remote whoami is the cwd is remote:

   ~ $ /bin/whoami
   jim
   ~ $ cd /sudo::
   /sudo:root@host:~ # /bin/whoami
   root

By enabling this new option, Eshell will treat arguments much the same 
as it treats command names.

(Of course, I'm happy to explain any part of this in more detail, and to 
add more documentation to the manual for whatever outcome we can agree 
to. The behavior around Tramp + Eshell in general is non-obvious, hence 
my hesitance to submit this patch without thinking it over for a *long* 
time. As the diff says, I finished the initial version of this last 
September and have spent much of the intervening time considering 
whether this behavior makes sense and how/if it could go wrong.)