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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 6 May 2024 11:13:20 -0700
> Cc: 70792@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> File names are expanded according to the current working directory when 
> you enter your command, so unless you explicitly type out the host in a 
> file name, it's treated as belonging to the host associated with cwd. 

I know this, but we are explicitly talking about _absolute_ file
names, which normally trivially expand to themselves.  _That_ is the
problem which I was talking about: you seem to propose a feature where
an absolute file name is sometimes expanded not to itself, but to a
remote file name.

>    ##### 1. Change to root
> ~ $ cd /sudo::
> /sudo:root@host:~ # pwd; *pwd
> /sudo:root@host:/root
> /root
> 
>    ##### 2. Change to an absolute directory, stay as root
> /sudo:root@host:~ # cd /etc; pwd; *pwd
> /sudo:root@host:/etc
> /etc

So you are saying that to chdir to the _local_ /etc I must quote it as
in "/:/etc", or somesuch?  If not, how do I chdir to a local directory
by its absolute file name?

>    ##### 3. Change to the home directory, stay as root
> /sudo:root@host:~ # cd ~; pwd; *pwd
> /sudo:root@host:/root
> /root

Likewise here: how to chdir to the _local_ home directory? quote it?

>    ##### 4. Write the expanded "~/foo.txt" to the *local* "~/bar.txt".
>    ##### Using "/:" quoting lets you explicitly name a local file
> /sudo:root@host:~ # *echo ~/foo.txt > /:~/bar.txt
> /sudo:root@host:~ # cat bar.txt
> /bin/cat: bar.txt: No such file or directory
> 
>    ##### 5. Change to the *local* home directory, stop being root
> /sudo:root@host:~ # cd /:~; pwd; *pwd
> /home/jim
> /home/jim

That's awful!  Completely un-natural, let alone a lot of typing!

Also, am I still able to specify remote file names when my default
directory is local?  Or do I have to chdir to a remote directory
first?

>    ##### 6. "bar.txt" ended up here
> ~ $ cat bar.txt
> ['-c', '/root/foo.txt']

Is "/root/foo.txt" a local or remote file name?  (I know you used
*echo, but the file bar.text has no memory of that.)

> In the last line above, note that the value we wrote to our file is just 
> the local part.

And that's considered a feature??

> With this option *disabled* (the default), there are some problems that 
> (in my opinion) make working with remote file names in Eshell even more 
> complex. For example, suppose I'm on a remote host, and want to change 
> to my home directory on that remote. There's not an easy way to do that:

The simplest solution is to introduce a special command for that, so
that the user could tell Eshell explicitly whether he/she wants to
consider him/herself on the local or the remote host.  Similar to what
we did with rlogin or ssh.

> Or suppose my cwd is /ssh:user@remote:/somedir. If I run "cat 
> /etc/hosts", Eshell will print my local hosts file. But what if I run 
> "cat -n /etc/hosts"? Eshell's "cat" implementation doesn't understand 
> "-n", so it calls the "cat" on "remote". Now it prints the remote hosts 
> file. You can only predict which hosts files you'll get if you know 
> exactly which flags Eshell's "cat" implementation supports.

If Eshel knew that I consider myself on the remote, it could have
modified the logic accordingly, to DTRT.  Without such an explicit
knowledge, we are _guessing_, and our guesses are bound to be wrong
sometimes.

Bottom line: instead of trying to improve our guesswork, I suggest to
explore the possibility of adding new command(s) that will tell Eshell
exactly what the user means wrt local/remote operation.