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

Previous Next

To reply to this bug, email your comments to 70792 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names
 within the current remote connection
Date: Sun, 5 May 2024 13:58:55 -0700

[Message part 1 (text/plain, inline)]

One oddity of Eshell is that even when you're connected to a remote host 
(usually you just "cd" into a remote directory using Tramp syntax), 
absolute file names are still on your *local* host when running any Lisp 
commands. However, running *external* commands (programs on the remote 
host), absolute file names are on that remote host.

When you think about how it's implemented, this makes sense: Lisp 
commands always run in the local Emacs process, but external programs 
run on the remote. So naturally, "absolute" file names are relative to a 
different host in either case. This wouldn't be so bad except that it's 
not always obvious when you're running a Lisp command or not. Eshell 
provides Lisp implementations of some common commands, like "cat", but 
it also transparently falls back to the external program if it doesn't 
understand some option. This results in it being pretty hard to tell 
what's going to happen when you run a command.

There's an "elecslash" module for Eshell that helps with this, but it 
can't tell when you have a Lisp command that will actually fallback to 
the external program when you run it.

Instead, the attached patch provides a new way to handle this: if you 
enable 'eshell-connection-local-file-names', then "normal" absolute file 
names like "/foo/bar" or "~/user" are evaluated relative to the current 
remote connection (if any). Eshell does this by expanding the file name 
to a full remote name like "/ssh:remote:/foo/bar". If these strings get 
sent to an external program, Eshell will unexpand them back to a 
host-local name (it will make sure that the remote host is correct, too).

You can also keep Eshell from performing this expansion on a 
case-by-case basis by quoting the file name (like "this", 'this', or 
/:this) or escaping the leading / or ~.

[0001-Mark-all-backslash-escaped-characters-in-Eshell-as-e.patch (text/plain, attachment)]

[0002-Let-Eshell-expand-absolute-file-names-via-the-curren.patch (text/plain, attachment)]

Message #8 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50;
 [PATCH] Add Eshell support for expanding absolute file names within
 the current remote connection
Date: Mon, 06 May 2024 14:14:22 +0300

> Date: Sun, 5 May 2024 13:58:55 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> One oddity of Eshell is that even when you're connected to a remote host 
> (usually you just "cd" into a remote directory using Tramp syntax), 
> absolute file names are still on your *local* host when running any Lisp 
> commands. However, running *external* commands (programs on the remote 
> host), absolute file names are on that remote host.
> 
> When you think about how it's implemented, this makes sense: Lisp 
> commands always run in the local Emacs process, but external programs 
> run on the remote. So naturally, "absolute" file names are relative to a 
> different host in either case. This wouldn't be so bad except that it's 
> not always obvious when you're running a Lisp command or not. Eshell 
> provides Lisp implementations of some common commands, like "cat", but 
> it also transparently falls back to the external program if it doesn't 
> understand some option. This results in it being pretty hard to tell 
> what's going to happen when you run a command.
> 
> There's an "elecslash" module for Eshell that helps with this, but it 
> can't tell when you have a Lisp command that will actually fallback to 
> the external program when you run it.
> 
> Instead, the attached patch provides a new way to handle this: if you 
> enable 'eshell-connection-local-file-names', then "normal" absolute file 
> names like "/foo/bar" or "~/user" are evaluated relative to the current 
> remote connection (if any). Eshell does this by expanding the file name 
> to a full remote name like "/ssh:remote:/foo/bar". If these strings get 
> sent to an external program, Eshell will unexpand them back to a 
> host-local name (it will make sure that the remote host is correct, too).
> 
> You can also keep Eshell from performing this expansion on a 
> case-by-case basis by quoting the file name (like "this", 'this', or 
> /:this) or escaping the leading / or ~.

I don't understand how would this work conceptually.  Suppose I want
to run a command on a remote host, but pipe the results into a command
that runs locally -- how will Eshell know which file name to interpret
relative to which directory, and how can the user indicate which is
which unequivocally?

IOW, I fear that this problem cannot be solved in principle in a
shell-like application, and so trying to solve it will only cause us a
terrible complexity mess.  What am I missing?

Thanks.

Message #11 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 06 May 2024 17:56:18 +0100

Hello,

On Sun 05 May 2024 at 01:58pm -07, Jim Porter wrote:

> One oddity of Eshell is that even when you're connected to a remote host
> (usually you just "cd" into a remote directory using Tramp syntax), absolute
> file names are still on your *local* host when running any Lisp
> commands. However, running *external* commands (programs on the remote host),
> absolute file names are on that remote host.
>
> When you think about how it's implemented, this makes sense: Lisp commands
> always run in the local Emacs process, but external programs run on the
> remote. So naturally, "absolute" file names are relative to a different host
> in either case. This wouldn't be so bad except that it's not always obvious
> when you're running a Lisp command or not. Eshell provides Lisp
> implementations of some common commands, like "cat", but it also transparently
> falls back to the external program if it doesn't understand some option. This
> results in it being pretty hard to tell what's going to happen when you run a
> command.

Isn't this by design?  It lets you, e.g, transparently copy a file from
the local to the remote host just with 'cp'.

-- 
Sean Whitton

Message #14 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50;
 [PATCH] Add Eshell support for expanding absolute file names within
 the current remote connection
Date: Mon, 06 May 2024 20:59:22 +0300

> Cc: 70792 <at> debbugs.gnu.org
> Date: Mon, 06 May 2024 17:56:18 +0100
> From:  Sean Whitton via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Isn't this by design?  It lets you, e.g, transparently copy a file from
> the local to the remote host just with 'cp'.

Which 'cp'? the built-in one or the external one?  And how do you tell
which one will be invoked?

Message #17 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 6 May 2024 11:13:20 -0700

On 5/6/2024 4:14 AM, Eli Zaretskii wrote:
> I don't understand how would this work conceptually.  Suppose I want
> to run a command on a remote host, but pipe the results into a command
> that runs locally -- how will Eshell know which file name to interpret
> relative to which directory, and how can the user indicate which is
> which unequivocally?

Thanks for taking a look. I'll try to explain this in more detail, since 
it's a fairly subtle interaction, especially if you don't use Tramp + 
Eshell heavily. (With the benefit of hindsight, we might have chosen not 
to handle remote access in Eshell the way it does, but it's now one of 
the big features users mention when they describe what they like about 
it. This patch is my best attempt at smoothing some of the existing 
rough edges here so that remote access in Eshell doesn't feel so 
capricious.)

Anyway...

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. 
(If it helps, this is sort of like how "~" is expanded in regular 
shells. The shell expands it early on when parsing your input, so "sudo 
echo ~" outputs *your* homedir, not root's.)

Here are some examples with the new option enabled (note that "*" before 
a program name means "always execute the external program on the host"):

  ##### 1. Change to root
~ $ cd /sudo::
/sudo:root <at> host:~ # pwd; *pwd
/sudo:root <at> host:/root
/root

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

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

  ##### 4. Write the expanded "~/foo.txt" to the *local* "~/bar.txt".
  ##### Using "/:" quoting lets you explicitly name a local file
/sudo:root <at> host:~ # *echo ~/foo.txt > /:~/bar.txt
/sudo:root <at> 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 <at> host:~ # cd /:~; pwd; *pwd
/home/jim
/home/jim

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

In the last line above, note that the value we wrote to our file is just 
the local part. There's no Tramp remote host part here because Python 
(or other any other external program) wouldn't understand that syntax. 
Eshell strips off the remote part for you, unless you escape the 
argument, e.g. by surrounding it with quotes. (When doing this 
unexpanding, Eshell also makes sure that the remote host of the file 
name matches the host where the program will run.)

> IOW, I fear that this problem cannot be solved in principle in a
> shell-like application, and so trying to solve it will only cause us a
> terrible complexity mess.  What am I missing?

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:

  ##### 3b. Change to the home directory; stop being root(!)
/sudo:root <at> host:~ # cd ~; pwd; *pwd
/home/jim
/home/jim

Or suppose my cwd is /ssh:user <at> 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.

Message #20 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 6 May 2024 11:28:54 -0700

On 5/6/2024 9:56 AM, Sean Whitton via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>> When you think about how it's implemented, this makes sense: Lisp commands
>> always run in the local Emacs process, but external programs run on the
>> remote. So naturally, "absolute" file names are relative to a different host
>> in either case. This wouldn't be so bad except that it's not always obvious
>> when you're running a Lisp command or not. Eshell provides Lisp
>> implementations of some common commands, like "cat", but it also transparently
>> falls back to the external program if it doesn't understand some option. This
>> results in it being pretty hard to tell what's going to happen when you run a
>> command.
> 
> Isn't this by design?  It lets you, e.g, transparently copy a file from
> the local to the remote host just with 'cp'.

Yes, but this breaks in non-obvious ways if Eshell's "cp" implementation 
falls back to the external program. For example, today:

  ~ $ cp file /ssh:remote:~/file    # copies "file" to a remote host
  ~ $ cp -b file /ssh:remote:~/file
  /usr/bin/cp: cannot create regular file '/ssh:remote:~/file': No such
  file or directory

Or the second line might work if you get unlucky, or pass --parents, or...

With the new option, Eshell is smart enough to recognize that this is a 
problem even before it calls "/usr/bin/cp":

  ~ $ cp -b file /ssh:remote:~/file
  ‘/ssh:remote:~/file’ is remote, but current directory is local

Similarly, if you're in a remote directory and try to specify an 
absolute file name on that remote to copy, this is what happens today:

  /ssh:remote:~ $ cp /etc/A /etc/B     # copies local A to local B
  /ssh:remote:~ $ cp -b /etc/A /etc/B  # copies remote A to remote B

With the new option, both cases copy remote A to remote B. If you wanted 
to copy local A to local B with the option enabled, you could do this:

  /ssh:remote:~ $ cp /:/etc/A /:/etc/B     # copies local A to local B
  /ssh:remote:~ $ cp -b /:/etc/A /:/etc/B
  ‘/:/etc/A’ is local, but current directory is remote

Message #23 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 6 May 2024 11:37:06 -0700

On 5/6/2024 11:28 AM, Jim Porter wrote:
> Yes, but this breaks in non-obvious ways if Eshell's "cp" implementation 
> falls back to the external program. For example, today:
> 
>    ~ $ cp file /ssh:remote:~/file    # copies "file" to a remote host
>    ~ $ cp -b file /ssh:remote:~/file
>    /usr/bin/cp: cannot create regular file '/ssh:remote:~/file': No such
>    file or directory
> 
> Or the second line might work if you get unlucky, or pass --parents, or...

By "work" here, I mean, "cp will copy the file, but to a place you 
likely didn't intend."

Message #26 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 06 May 2024 21:43:00 +0300

> Date: Mon, 6 May 2024 11:13:20 -0700
> Cc: 70792 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> 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 <at> host:~ # pwd; *pwd
> /sudo:root <at> host:/root
> /root
> 
>    ##### 2. Change to an absolute directory, stay as root
> /sudo:root <at> host:~ # cd /etc; pwd; *pwd
> /sudo:root <at> 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 <at> host:~ # cd ~; pwd; *pwd
> /sudo:root <at> 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 <at> host:~ # *echo ~/foo.txt > /:~/bar.txt
> /sudo:root <at> 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 <at> 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 <at> 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.

Message #29 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 6 May 2024 13:05:28 -0700

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.

On 5/6/2024 11:43 AM, Eli Zaretskii wrote:
> 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.

Correct. Eshell's transparent remote access forces us to consider a 
question that other shells don't have: how do I refer to a file that's 
absolute *on the current connection*?

Currently, for Lisp-based commands, you have to type the the full remote 
part of the file name again, like "/ssh:user <at> remote:/some/file". For 
external commands, you have to type just the local part, like 
"/some/file". For commands that could be *either* Lisp-based or external 
(this includes most Eshell built-ins), there's no way to do this. 
(Unless you know exactly how Eshell implements things.)

>>     ##### 2. Change to an absolute directory, stay as root
>> /sudo:root <at> host:~ # cd /etc; pwd; *pwd
>> /sudo:root <at> 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?

If your current working directory is local, "cd /etc" is enough (since 
the current host is the local one). If your current working directory is 
remote, any of the following would change back to the local /etc:

  cd /:/etc
  cd \/etc
  cd "/etc"
  cd '/etc'

>>     ##### 3. Change to the home directory, stay as root
>> /sudo:root <at> host:~ # cd ~; pwd; *pwd
>> /sudo:root <at> host:/root
>> /root
> 
> Likewise here: how to chdir to the _local_ home directory? quote it?

If your cwd is local, just "cd ~" is enough. If cwd is remote then you'd 
use "cd /:~".

>>     ##### 4. Write the expanded "~/foo.txt" to the *local* "~/bar.txt".
>>     ##### Using "/:" quoting lets you explicitly name a local file
>> /sudo:root <at> host:~ # *echo ~/foo.txt > /:~/bar.txt
>> /sudo:root <at> 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 <at> host:~ # cd /:~; pwd; *pwd
>> /home/jim
>> /home/jim
> 
> That's awful!  Completely un-natural, let alone a lot of typing!

It's only two extra characters compared to the equivalent command that 
all happens on a single host (which I think would be the more-common 
scenario):

  ##### 4b. Write the expanded "~/foo.txt" to the remote "~/bar.txt".
  ##### Using "/:" quoting lets you explicitly name a local file
/sudo:root <at> host:~ # *echo ~/foo.txt > ~/bar.txt
/sudo:root <at> host:~ # cat bar.txt
['-c', '/root/foo.txt']

The example I chose is somewhat contrived, of course. I just wanted to 
show off how you can mix local and remote expanded file names in a 
single command for this case.

> 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?

Yes. Just type the full remote name, like "/ssh:user <at> remote:/file".

>>     ##### 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.)

At this point, it's just text, so *technically* it's neither. However, 
that text was created from the local portion of a remote file name, so 
the string is local to the remote host where Python was executed. (In 
the example, I used "sudo", so I suppose local/remote are misnomers, but 
the same reasoning applies if you used "ssh".)

>> 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??

As mentioned above, this is a contrived example to show the lifecycle of 
these names, but yes. The Python command I used just shows off the 
internals. For a more practical example, suppose I want to write the 
word counts of a remote file into a local file. This might actually come 
up in practice: if the remote file is large, I don't want to copy the 
whole thing locally first. With this new option, I could do the following:

  /ssh:user <at> remote:/somedir $ *wc ~/file.txt > /:~/counts.txt

Today, you could do this like so:

  /ssh:user <at> remote:/somedir $ *wc ~/file.txt > ~/counts.txt

That looks a bit simpler at a glance (no "/:"), but now there's a 
problem lurking: "~" points to the remote homedir in the first case, and 
the local homedir in the second.

Now suppose a slightly different case. What if I'm in a remote directory 
and want to write this summary file to my remote homedir? With this new 
option, I could type the following:

  /ssh:user <at> remote:/somedir $ *wc ~/file.txt > ~/counts.txt

Today, you'd need to do this:

  /ssh:user <at> remote:/somedir $ *wc ~/file.txt > 
/ssh:user <at> remote:~/counts.txt

Or this:

  /ssh:user <at> remote:/somedir $ cd /ssh:user <at> remote:~
  /ssh:user <at> remote:~ $ *wc file.txt > counts.txt

In both of the "today" cases, you need to type "/ssh:user <at> remote:~" 
somewhere, which is the thing I'd consider to be unnatural and a lot of 
typing.

>> 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.

Eshell users already have a command for explicitly moving between local 
and remote hosts: it's just "cd".

I'm not familiar with what we do about rlogin and ssh though. Where 
would I find that info? If someone else has come up with a better way to 
handle a similar scenario, I'd be happy to take a look.

>> Or suppose my cwd is /ssh:user <at> 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.

Unless I'm misunderstanding what you mean here, Eshell *does* know that 
you consider yourself on the remote. You previously cd'ed into a remote 
directory, expressing your intention to Eshell explicitly. With my 
patch, there's no guesswork here. At least the way I interpret your 
message, this patch does exactly what you suggest: because Eshell knows 
that you consider yourself on the remote (you cd'ed into it) and that 
you chose this new option, it knows that "/foo/bar" should refer to a 
file on the remote system, ensuring that your commands work the same no 
matter whether they're Lisp-based or external programs.

Without using this option, I don't think there's a way to DTRT in 
general. Currently, the string "/foo/bar" is just that, a string. It 
carries no information about the host Emacs should look on. Existing 
commands (whether Lisp-based or external) will just look on the host 
where the process is running. Conceptually, my patch adds annotations to 
these strings so that we can determine authoritatively which host they 
belong to.

[1] Eshell has some code to handle this syntax, but it's built on the 
one of the intended uses for quoted file names. From "Quoted File Names" 
in the Emacs manual: "For example, you can quote a local file name which 
appears remote, to prevent it from being treated as a remote file name."

Message #32 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
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 <at> 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.)

Message #35 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Tue, 07 May 2024 10:12:52 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

> 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.

Perhaps we start with a first step to make it visible, what a file name
is intended to be. We could use different faces for local and remote
file names in a command line of Eshell which hasn't been sent yet, as
Eshell would treat them.

Best regards, Michael.

Message #38 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Tue, 07 May 2024 09:50:51 +0100

Hello,

On Mon 06 May 2024 at 11:28am -07, Jim Porter wrote:

> On 5/6/2024 9:56 AM, Sean Whitton via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>>> When you think about how it's implemented, this makes sense: Lisp commands
>>> always run in the local Emacs process, but external programs run on the
>>> remote. So naturally, "absolute" file names are relative to a different host
>>> in either case. This wouldn't be so bad except that it's not always obvious
>>> when you're running a Lisp command or not. Eshell provides Lisp
>>> implementations of some common commands, like "cat", but it also transparently
>>> falls back to the external program if it doesn't understand some option. This
>>> results in it being pretty hard to tell what's going to happen when you run a
>>> command.
>> Isn't this by design?  It lets you, e.g, transparently copy a file from
>> the local to the remote host just with 'cp'.
>
> Yes, but this breaks in non-obvious ways if Eshell's "cp" implementation falls
> back to the external program. For example, today:
>
>   ~ $ cp file /ssh:remote:~/file    # copies "file" to a remote host
>   ~ $ cp -b file /ssh:remote:~/file
>   /usr/bin/cp: cannot create regular file '/ssh:remote:~/file': No such
>   file or directory
>
> Or the second line might work if you get unlucky, or pass --parents, or...
>
> With the new option, Eshell is smart enough to recognize that this is a
> problem even before it calls "/usr/bin/cp":
>
>   ~ $ cp -b file /ssh:remote:~/file
>   ‘/ssh:remote:~/file’ is remote, but current directory is local
>
> Similarly, if you're in a remote directory and try to specify an absolute file
> name on that remote to copy, this is what happens today:
>
>   /ssh:remote:~ $ cp /etc/A /etc/B     # copies local A to local B
>   /ssh:remote:~ $ cp -b /etc/A /etc/B  # copies remote A to remote B
>
> With the new option, both cases copy remote A to remote B. If you wanted to
> copy local A to local B with the option enabled, you could do this:
>
>   /ssh:remote:~ $ cp /:/etc/A /:/etc/B     # copies local A to local B
>   /ssh:remote:~ $ cp -b /:/etc/A /:/etc/B
>   ‘/:/etc/A’ is local, but current directory is remote

Right okay.  I guess you are basically saying that this aspect of
Eshell's design turned out to be a bit too clever, and doing things in a
more predictable way, always based on the cwd unless explicitly
otherwise, will probably turn out to be more useful for most users.

-- 
Sean Whitton

Message #41 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Tue, 07 May 2024 14:55:05 +0300

> Date: Mon, 6 May 2024 13:05:28 -0700
> Cc: 70792 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> Currently, for Lisp-based commands, you have to type the the full remote 
> part of the file name again, like "/ssh:user <at> remote:/some/file". For 
> external commands, you have to type just the local part, like 
> "/some/file". For commands that could be *either* Lisp-based or external 
> (this includes most Eshell built-ins), there's no way to do this. 
> (Unless you know exactly how Eshell implements things.)

I think asking the user to specify the full "/ssh:..." file name for
remote files makes this easier, because Eshell could then
transparently handle also the commands which can be external or
internal.  That's one confusing problem down.

> > 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?
> 
> If your current working directory is local, "cd /etc" is enough (since 
> the current host is the local one). If your current working directory is 
> remote, any of the following would change back to the local /etc:
> 
>    cd /:/etc
>    cd \/etc
>    cd "/etc"
>    cd '/etc'

The first form I could maybe agree to.  But the others are standard
shell quoting, so I think repurposing them for "escape to local file
names" is not a good idea, since quoting is used in shell commands for
other reasons, notably for quoting special characters.  We need to
allow user to quote file names without implying the name is local.

So I think the last 3 examples should not mean local file names.

> >>     ##### 5. Change to the *local* home directory, stop being root
> >> /sudo:root <at> host:~ # cd /:~; pwd; *pwd
> >> /home/jim
> >> /home/jim
> > 
> > That's awful!  Completely un-natural, let alone a lot of typing!
> 
> It's only two extra characters

Two extra characters _per_file_name_!

> > 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.
> 
> Eshell users already have a command for explicitly moving between local 
> and remote hosts: it's just "cd".

Then why do we need to change anything at all?

My suggestion is to introduce a notion of "state", either local or
remote, and make it so that the "state" defines the semantics of file
names without the Tramp "/METHOD:..." prefix: such names _always_ mean
files on the host specified by the "state".  In particular, quoted
file names also specify files according to the "state"; they do not
"escape" to the other host.

This matches what you get from a normal shell: if you login to a
remote host, _all_ the file names are from the remote host.

It is okay to use the value of default-directory as the "state", but
we should use it consistently.  the only way of "escaping" from the
current host is by using fully-qualified file names that specify the
host explicitly.

The advantage of this is twofold: (a) users will always know what do
file names refer to, and (b) Eshell will always know that, and will be
able to DTRT in all such cases by converting the file names the user
typed to the appropriate form under the hood as needed.

> I'm not familiar with what we do about rlogin and ssh though. Where 
> would I find that info? If someone else has come up with a better way to 
> handle a similar scenario, I'd be happy to take a look.

See above.  The advantage of those is that they never allow you to mix
file names on different hosts except explicitly.

> > 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.
> 
> Unless I'm misunderstanding what you mean here, Eshell *does* know that 
> you consider yourself on the remote.

Then why is external vs internal commands an issue? why cannot Eshell
DTRT by invoking the command which can handle the file names the user
typed?

> Without using this option, I don't think there's a way to DTRT in 
> general.

My point is that we should try to find such a way.  Personally, I
don't think it's a problem to find it.

> Currently, the string "/foo/bar" is just that, a string. It 
> carries no information about the host Emacs should look on.

The "state" should supply the missing information, and the
"/METHOD:..." notation should allow the user to override what the
"state" says implicitly.

> Existing commands (whether Lisp-based or external) will just look on
> the host where the process is running.

Some kind of dispatch should look at the "state" before it runs the
command, and decide which variety of the command to run.

Message #44 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Tue, 7 May 2024 11:54:26 -0700

(Replying a bit out of order to make the structure of my responses clearer.)

On 5/7/2024 4:55 AM, Eli Zaretskii wrote:
>> Eshell users already have a command for explicitly moving between local
>> and remote hosts: it's just "cd".
> 
> Then why do we need to change anything at all?
> 
> My suggestion is to introduce a notion of "state", either local or
> remote, and make it so that the "state" defines the semantics of file
> names without the Tramp "/METHOD:..." prefix: such names _always_ mean
> files on the host specified by the "state".  In particular, quoted
> file names also specify files according to the "state"; they do not
> "escape" to the other host.
> 
> This matches what you get from a normal shell: if you login to a
> remote host, _all_ the file names are from the remote host.
> 
> It is okay to use the value of default-directory as the "state", but
> we should use it consistently.  the only way of "escaping" from the
> current host is by using fully-qualified file names that specify the
> host explicitly.

I think we must be close to seeing things the same way, since your 
explanation is almost exactly how I proposed to fix this initially. In 
retrospect, I should probably have spent a bit more space introducing 
the issue and explaining why I did what I did; most of my initial 
explanation was simply on *how* the patch works.

So I'll try to provide a summary of this problem from a user POV to make 
sure we're on the same page:

----- SUMMARY -----

Currently, Eshell has a problem: when connected to a remote host (i.e. 
cd'ed into a remote dir), sometimes an absolute file name like 
"/foo/bar" means "a file on the current host", and sometimes it means "a 
file on the *local* host". This new option lets you change that so an 
absolute file name *always* means "a file on the current host"; this 
matches the behavior of normal shells. If you want to refer to a file on 
a different host, you instead type the fully-qualified remote file name 
("/ssh:remote:/foo/bar"); this always means "/foo/bar on remote".

----- END SUMMARY -----

There's just one open question with this: if I'm on a remote system, how 
do I type the fully-qualified *local* file name? I propose using "/:" as 
the prefix to mean "always look on the local host", so "/:/etc/foo.log" 
is a local file name no matter what. For this case, I'm open to other 
spellings, so long as we have *some* way to fully-qualify a local file name.

>> Currently, for Lisp-based commands, you have to type the the full remote 
>> part of the file name again, like "/ssh:user <at> remote:/some/file". For 
>> external commands, you have to type just the local part, like 
>> "/some/file". For commands that could be *either* Lisp-based or external 
>> (this includes most Eshell built-ins), there's no way to do this. 
>> (Unless you know exactly how Eshell implements things.)
> 
> I think asking the user to specify the full "/ssh:..." file name for
> remote files makes this easier, because Eshell could then
> transparently handle also the commands which can be external or
> internal.  That's one confusing problem down.

Based on your longer explanation above, I think we agree entirely here.

>>> 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?
>>
>> If your current working directory is local, "cd /etc" is enough (since 
>> the current host is the local one). If your current working directory is 
>> remote, any of the following would change back to the local /etc:
>>
>>    cd /:/etc
>>    cd \/etc
>>    cd "/etc"
>>    cd '/etc'
> 
> The first form I could maybe agree to.  But the others are standard
> shell quoting, so I think repurposing them for "escape to local file
> names" is not a good idea, since quoting is used in shell commands for
> other reasons, notably for quoting special characters.  We need to
> allow user to quote file names without implying the name is local.

That's fine by me; I could remove options 2-4 from this list (so that 
they mean "/etc on the current host"). I had chosen this set of options 
to match the escaping logic for "~" in Eshell. However, I think I agree 
that that's too invasive: a user might want to write a file name with 
spaces "/something/like this.txt", and would be surprised if that 
escaped to a local filename.

>>>>     ##### 5. Change to the *local* home directory, stop being root
>>>> /sudo:root <at> host:~ # cd /:~; pwd; *pwd
>>>> /home/jim
>>>> /home/jim
>>>
>>> That's awful!  Completely un-natural, let alone a lot of typing!
>>
>> It's only two extra characters
> 
> Two extra characters _per_file_name_!

Note that these extra characters *only* come up if you're connected to a 
remote host and need to explicitly refer to a file on your local system. 
With this new option enabled, the "normal" spelling of "~/blah" would be 
on the current host, just like normal shells. The "/:" is there to 
explicitly override that behavior by fully-qualifying the name. (This 
makes the common case - everything on the same host - easier to type. 
You just type the normal, unqualified name.)

>> Currently, the string "/foo/bar" is just that, a string. It
>> carries no information about the host Emacs should look on.
> 
> The "state" should supply the missing information, and the
> "/METHOD:..." notation should allow the user to override what the
> "state" says implicitly.

Agreed. With this option, an unqualified file name will refer to the 
"state" (current remote host) to resolve the name.

>> Existing commands (whether Lisp-based or external) will just look on
>> the host where the process is running.
> 
> Some kind of dispatch should look at the "state" before it runs the
> command, and decide which variety of the command to run.

Eshell already has a lot of logic for determining whether to run a Lisp 
implementation of a command or an external program, so I don't think we 
can change that without breaking many things. However, once Eshell has 
determined the variety of the command, it can provide file names in the 
correct syntax for that variety. (In other words, Lisp code will see the 
fully-qualified file name[1], and external commands will see the 
unqualified file name.)

[1] It might be wise to let Lisp-based commands request unqualified file 
names too; Eshell already does similar things for determining when to 
turn a string like "123" into a Lisp number.

Message #47 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 08 May 2024 16:20:38 +0300

> Date: Tue, 7 May 2024 11:54:26 -0700
> Cc: 70792 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> There's just one open question with this: if I'm on a remote system, how 
> do I type the fully-qualified *local* file name? I propose using "/:" as 
> the prefix to mean "always look on the local host", so "/:/etc/foo.log" 
> is a local file name no matter what. For this case, I'm open to other 
> spellings, so long as we have *some* way to fully-qualify a local file name.

I think "/:" quoting should not change the host of the file name.
That's because the user might need this quoting for file names on the
remote host.

If the user wants to specify a local file name while default-directory
is remote, the user can use the normal Tramp "/METHOD:..." notation.

Message #50 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 8 May 2024 09:13:59 -0700

On 5/8/2024 6:20 AM, Eli Zaretskii wrote:
> I think "/:" quoting should not change the host of the file name.
> That's because the user might need this quoting for file names on the
> remote host.

Not to say we *should* do this, but if we kept the "/:" syntax of my 
patch, a user could still /:-quote a remote file name in Eshell by using 
the fully-qualified name like: "/ssh:user <at> remote:/:/blah".

I can construct an argument for why using /: this way in Eshell would 
make sense, but maybe it's just needlessly "clever"...

(As a note, Eshell already uses /:-quoting to mean "on the local host" 
in one spot: for the command to run. However, I added that for Emacs 30, 
so we can still change it without worrying about compatibility issues. 
See the manual here for more info: 
<https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.)

> If the user wants to specify a local file name while default-directory
> is remote, the user can use the normal Tramp "/METHOD:..." notation.

How about a new "local" method? Then users would type 
"/local::~/some-file.txt". That's more typing, but it's also more clear, 
and doesn't repurpose an existing syntax used elsewhere in Emacs.

I don't think the extra typing is *too* bad, since cross-host file names 
are probably a lot rarer than regular intra-host ones. Most likely, 
users will use cross-host file names primarily when cd'ing to a 
different host.

If I go this route, I'm not sure whether it would be better to make 
"local" a real file name handler available everywhere in Emacs despite 
only being useful for Eshell, or if Eshell should just strip out the 
"/local::" prefix before sending it to other parts of Emacs. I'm leaning 
towards the former though, since the latter seems like a hack that could 
have unforeseen consequences.

Message #53 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 08 May 2024 20:17:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

>> There's just one open question with this: if I'm on a remote system, how
>> do I type the fully-qualified *local* file name? I propose using "/:" as
>> the prefix to mean "always look on the local host", so "/:/etc/foo.log"
>> is a local file name no matter what. For this case, I'm open to other
>> spellings, so long as we have *some* way to fully-qualify a local file name.
>
> I think "/:" quoting should not change the host of the file name.
> That's because the user might need this quoting for file names on the
> remote host.
>
> If the user wants to specify a local file name while default-directory
> is remote, the user can use the normal Tramp "/METHOD:..." notation.

FTR, we *have* already two different kinds of quoting. "/:<something>"
makes <something> local, whatever syntax it has (for example, Tramp file
name syntax).

"/method:user <at> host:/:<something>" makes <something> "local" on
"/method:user <at> host:" whatever syntax it has.

--8<---------------cut here---------------start------------->8---
(expand-file-name "/:/ssh::.emacs") => "/:/ssh::.emacs"
(file-truename "/:/ssh::.emacs") => "/:/ssh::.emacs"
(file-remote-p "/:/ssh::.emacs") => nil
(file-local-name "/:/ssh::.emacs") => "/:/ssh::.emacs"

(expand-file-name "/ssh::/:.emacs") => "/ssh:gandalf:/:.emacs"
(file-truename "/ssh::/:.emacs") => "/ssh:gandalf:/:/home/albinus/.emacs"
(file-remote-p "/ssh::/:.emacs") => "/ssh:gandalf:"
(file-local-name "/ssh::/:.emacs") => "/:.emacs"
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Message #56 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>,
 Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 08 May 2024 21:32:42 +0300

> Date: Wed, 8 May 2024 09:13:59 -0700
> Cc: 70792 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 5/8/2024 6:20 AM, Eli Zaretskii wrote:
> > I think "/:" quoting should not change the host of the file name.
> > That's because the user might need this quoting for file names on the
> > remote host.
> 
> Not to say we *should* do this, but if we kept the "/:" syntax of my 
> patch, a user could still /:-quote a remote file name in Eshell by using 
> the fully-qualified name like: "/ssh:user <at> remote:/:/blah".
> 
> I can construct an argument for why using /: this way in Eshell would 
> make sense, but maybe it's just needlessly "clever"...

We do need the ability to quote like "/ssh:user <at> remote:/:/blah".
That's why I think quoting should not "escape to local".  Another
reason that I think "/:" quoting should not escape to local is that
"/:" is for protecting file names from being interpreted as
referencing another host; a simple name like "/foo/bar/baz", when
quoted as "/:/foo/bar/baz", should resolve to itself.

> (As a note, Eshell already uses /:-quoting to mean "on the local host" 
> in one spot: for the command to run. However, I added that for Emacs 30, 
> so we can still change it without worrying about compatibility issues. 
> See the manual here for more info: 
> <https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.)

I think we should remove that before we release Emacs 30.  It's wrong
to interpret quoting this way.

> > If the user wants to specify a local file name while default-directory
> > is remote, the user can use the normal Tramp "/METHOD:..." notation.
> 
> How about a new "local" method? Then users would type 
> "/local::~/some-file.txt". That's more typing, but it's also more clear, 
> and doesn't repurpose an existing syntax used elsewhere in Emacs.

Don't we already have that with "/localhost:" or somesuch?

> If I go this route, I'm not sure whether it would be better to make 
> "local" a real file name handler available everywhere in Emacs despite 
> only being useful for Eshell, or if Eshell should just strip out the 
> "/local::" prefix before sending it to other parts of Emacs. I'm leaning 
> towards the former though, since the latter seems like a hack that could 
> have unforeseen consequences.

I'd like Michael's opinion on this, since we will be "invading" the
Tramp methods space.

Message #59 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 08 May 2024 21:49:56 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Jim Porter <jporterbugs <at> gmail.com>,  70792 <at> debbugs.gnu.org
> Date: Wed, 08 May 2024 20:17:27 +0200
> 
> FTR, we *have* already two different kinds of quoting. "/:<something>"
> makes <something> local, whatever syntax it has (for example, Tramp file
> name syntax).
> 
> "/method:user <at> host:/:<something>" makes <something> "local" on
> "/method:user <at> host:" whatever syntax it has.

There's a fine nuance here: "/:" does NOT make a file name locale, it
prevents interpreting it as remote due to the "/something:" construct
in it.  "/:" does NOT change the semantics of "/foo/bar/baz", it only
changes the semantics of "/method:user <at> host:/foo/bar".

Message #62 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 8 May 2024 11:57:19 -0700

On 5/8/2024 11:32 AM, Eli Zaretskii wrote:
>> (As a note, Eshell already uses /:-quoting to mean "on the local host"
>> in one spot: for the command to run. However, I added that for Emacs 30,
>> so we can still change it without worrying about compatibility issues.
>> See the manual here for more info:
>> <https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.)
> 
> I think we should remove that before we release Emacs 30.  It's wrong
> to interpret quoting this way.

Ok, whatever we decide for this bug, I'll apply the same syntax over 
there too.

>>> If the user wants to specify a local file name while default-directory
>>> is remote, the user can use the normal Tramp "/METHOD:..." notation.
>>
>> How about a new "local" method? Then users would type
>> "/local::~/some-file.txt". That's more typing, but it's also more clear,
>> and doesn't repurpose an existing syntax used elsewhere in Emacs.
> 
> Don't we already have that with "/localhost:" or somesuch?

I don't see one like that. It shouldn't be too difficult to add though 
(so long as Michael is ok with it).

Message #65 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 09 May 2024 20:14:07 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

>> How about a new "local" method? Then users would type
>> "/local::~/some-file.txt". That's more typing, but it's also more clear,
>> and doesn't repurpose an existing syntax used elsewhere in Emacs.
>
> Don't we already have that with "/localhost:" or somesuch?
>
>> If I go this route, I'm not sure whether it would be better to make
>> "local" a real file name handler available everywhere in Emacs despite
>> only being useful for Eshell, or if Eshell should just strip out the
>> "/local::" prefix before sending it to other parts of Emacs. I'm leaning
>> towards the former though, since the latter seems like a hack that could
>> have unforeseen consequences.

There is no public Tramp syntax for "/local:" or "/localhost:" or alike
in Tramp. Tramp uses internally, in `tramp-null-hop', the "local" method
in order to cache properties of the local machine. But this isn't
intended to be a public API.

> I'd like Michael's opinion on this, since we will be "invading" the
> Tramp methods space.

I'm kind of undecided. We might use this method internally for Eshell,
as "/local::/path/to/file", but it should be clear that it won't be an
official Tramp method. There might be problems, because all methods the
basic Tramp functions work for must be registered in `tramp-methods'.

And there might be other problems if a user changes the Tramp
syntax. The so-called simplified syntax doesn't use explicit method
strings, see (info "(tramp) Change file name syntax") .

Best regards, Michael.

Message #68 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 09 May 2024 20:22:57 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> FTR, we *have* already two different kinds of quoting. "/:<something>"
>> makes <something> local, whatever syntax it has (for example, Tramp file
>> name syntax).
>>
>> "/method:user <at> host:/:<something>" makes <something> "local" on
>> "/method:user <at> host:" whatever syntax it has.
>
> There's a fine nuance here: "/:" does NOT make a file name locale, it
> prevents interpreting it as remote due to the "/something:" construct
> in it.  "/:" does NOT change the semantics of "/foo/bar/baz", it only
> changes the semantics of "/method:user <at> host:/foo/bar".

The intenmtion of file name quoting isn't to make a file name local or
remote. This is just a side-effect in case of Tramp.

The intention of file name quoting is to suppress file name handlers of
any kind.

"/:/method:user <at> host:/foo/bar.gz" makes "/method:user <at> host:/foo/bar.gz"
a literal file name, not to be transferred to any file name handler.

"/method:user <at> host:/:/foo/bar.gz" keeps the Tramp file name handler
active, but makes "/:/foo/bar.gz" a literal file name "/foo/bar.gz" on
the remote machine. This suppresses the jka-compr-handler, for example.

Likely, you mean the same, but I wanted to say it explicitly.

Best regards, Michael.

Message #71 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 09 May 2024 21:10:44 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: Jim Porter <jporterbugs <at> gmail.com>,  70792 <at> debbugs.gnu.org
>> Date: Thu, 09 May 2024 20:14:07 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> There is no public Tramp syntax for "/local:" or "/localhost:" or alike
>> in Tramp. Tramp uses internally, in `tramp-null-hop', the "local" method
>> in order to cache properties of the local machine. But this isn't
>> intended to be a public API.
>>
>> > I'd like Michael's opinion on this, since we will be "invading" the
>> > Tramp methods space.
>>
>> I'm kind of undecided. We might use this method internally for Eshell,
>> as "/local::/path/to/file", but it should be clear that it won't be an
>> official Tramp method. There might be problems, because all methods the
>> basic Tramp functions work for must be registered in `tramp-methods'.
>>
>> And there might be other problems if a user changes the Tramp
>> syntax. The so-called simplified syntax doesn't use explicit method
>> strings, see (info "(tramp) Change file name syntax") .
>
> What would you suggest as an alternative?
>
> Since there's no official Tramp method for the local host, we could
> invent one now.

We could start with "/local::". I'm simply not so optimistic like Jim,
that it will be easy. Likely, se need a full Tramp backend for this, say
tramp-local.el. The respective file name handler should remove the
"/local::" prefix from the arguments, call the original file operation,
and add the "/local::" prefix on the results where appropriate.

And somehow, I'd like to check that this is called from Eshell only. Am
I paranoid? Will people use it on their own?

Best regards, Michael.

Message #74 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 09 May 2024 21:53:18 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Jim Porter <jporterbugs <at> gmail.com>,  70792 <at> debbugs.gnu.org
> Date: Thu, 09 May 2024 20:14:07 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> There is no public Tramp syntax for "/local:" or "/localhost:" or alike
> in Tramp. Tramp uses internally, in `tramp-null-hop', the "local" method
> in order to cache properties of the local machine. But this isn't
> intended to be a public API.
> 
> > I'd like Michael's opinion on this, since we will be "invading" the
> > Tramp methods space.
> 
> I'm kind of undecided. We might use this method internally for Eshell,
> as "/local::/path/to/file", but it should be clear that it won't be an
> official Tramp method. There might be problems, because all methods the
> basic Tramp functions work for must be registered in `tramp-methods'.
> 
> And there might be other problems if a user changes the Tramp
> syntax. The so-called simplified syntax doesn't use explicit method
> strings, see (info "(tramp) Change file name syntax") .

What would you suggest as an alternative?

Since there's no official Tramp method for the local host, we could
invent one now.

Message #77 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: jporterbugs <at> gmail.com, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 09 May 2024 22:02:54 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: jporterbugs <at> gmail.com,  70792 <at> debbugs.gnu.org
> Date: Thu, 09 May 2024 20:22:57 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Hi Eli,
> 
> >> FTR, we *have* already two different kinds of quoting. "/:<something>"
> >> makes <something> local, whatever syntax it has (for example, Tramp file
> >> name syntax).
> >>
> >> "/method:user <at> host:/:<something>" makes <something> "local" on
> >> "/method:user <at> host:" whatever syntax it has.
> >
> > There's a fine nuance here: "/:" does NOT make a file name locale, it
> > prevents interpreting it as remote due to the "/something:" construct
> > in it.  "/:" does NOT change the semantics of "/foo/bar/baz", it only
> > changes the semantics of "/method:user <at> host:/foo/bar".
> 
> The intenmtion of file name quoting isn't to make a file name local or
> remote. This is just a side-effect in case of Tramp.

I agree (and tried to say the same in different words).

> The intention of file name quoting is to suppress file name handlers of
> any kind.

I agree.

> "/:/method:user <at> host:/foo/bar.gz" makes "/method:user <at> host:/foo/bar.gz"
> a literal file name, not to be transferred to any file name handler.
> 
> "/method:user <at> host:/:/foo/bar.gz" keeps the Tramp file name handler
> active, but makes "/:/foo/bar.gz" a literal file name "/foo/bar.gz" on
> the remote machine. This suppresses the jka-compr-handler, for example.
> 
> Likely, you mean the same, but I wanted to say it explicitly.

Yes, we agree.

Which is why I think using /: for "escaping to local" in Eshell is
confusing and should not be done.

Message #80 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 9 May 2024 13:30:57 -0700

On 5/9/2024 12:10 PM, Michael Albinus via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>> Since there's no official Tramp method for the local host, we could
>> invent one now.
> 
> We could start with "/local::". I'm simply not so optimistic like Jim,
> that it will be easy. Likely, se need a full Tramp backend for this, say
> tramp-local.el. The respective file name handler should remove the
> "/local::" prefix from the arguments, call the original file operation,
> and add the "/local::" prefix on the results where appropriate.
> 
> And somehow, I'd like to check that this is called from Eshell only. Am
> I paranoid? Will people use it on their own?

Maybe the better solution would simply be for "/local:"[1] to be an 
Eshell-only syntax that DTRT within Eshell. There shouldn't be any 
conflict so long as Tramp promises not to add a "local" method. :)

Now, it's possible that this could conflict with Tramp's alternate file 
name syntax, but a) this feature will be disabled by default to avoid 
automatically changing the meaning of existing Eshell forms, and b) 
Eshell could look at Tramp's syntax and change the spelling for 
"/local:" to avoid collisions if we wanted to avoid this.

(If in the future, we came up with an Emacs-wide use case for this, it 
should be possible to upgrade "/local:" to a full magic file name. I'm 
not sure why we'd want this though.)

[1] Note the single colon, though I'm not dead-set on this. If it's just 
an Eshell notation and not part of Tramp, we don't necessarily need to 
follow Tramp syntax. Of course, if we wanted to keep open the 
possibility that this becomes a new Tramp method, maybe the "::" is the 
more forward-thinking route.

Message #83 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Fri, 10 May 2024 00:15:14 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

>> We could start with "/local::". I'm simply not so optimistic like
>> Jim,
>> that it will be easy. Likely, se need a full Tramp backend for this, say
>> tramp-local.el. The respective file name handler should remove the
>> "/local::" prefix from the arguments, call the original file operation,
>> and add the "/local::" prefix on the results where appropriate.
>> And somehow, I'd like to check that this is called from Eshell
>> only. Am
>> I paranoid? Will people use it on their own?
>
> Maybe the better solution would simply be for "/local:"[1] to be an
> Eshell-only syntax that DTRT within Eshell. There shouldn't be any
> conflict so long as Tramp promises not to add a "local" method. :)

Promised. Tramp uses just a tramp-file-name structure in tramp-null-hop,
that's it.

> Now, it's possible that this could conflict with Tramp's alternate
> file name syntax, but a) this feature will be disabled by default to
> avoid automatically changing the meaning of existing Eshell forms, and
> b) Eshell could look at Tramp's syntax and change the spelling for
> "/local:" to avoid collisions if we wanted to avoid this.

OK.

> (If in the future, we came up with an Emacs-wide use case for this, it
> should be possible to upgrade "/local:" to a full magic file name. I'm
> not sure why we'd want this though.)
>
> [1] Note the single colon, though I'm not dead-set on this. If it's
> just an Eshell notation and not part of Tramp, we don't necessarily
> need to follow Tramp syntax. Of course, if we wanted to keep open the
> possibility that this becomes a new Tramp method, maybe the "::" is
> the more forward-thinking route.

Anyway, even if you implement this completely in Eshell, I recommend to
write a file-name-handler for this. Potential 70+ primitive file
operations cannot be handled w/o such a basis, I fear.

Best regards, Michael.

Message #86 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Thu, 9 May 2024 15:28:58 -0700

On 5/9/2024 3:15 PM, Michael Albinus via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Promised. Tramp uses just a tramp-file-name structure in tramp-null-hop,
> that's it.

Thanks for the promise. :)

>> (If in the future, we came up with an Emacs-wide use case for this, it
>> should be possible to upgrade "/local:" to a full magic file name. I'm
>> not sure why we'd want this though.)
>>
>> [1] Note the single colon, though I'm not dead-set on this. If it's
>> just an Eshell notation and not part of Tramp, we don't necessarily
>> need to follow Tramp syntax. Of course, if we wanted to keep open the
>> possibility that this becomes a new Tramp method, maybe the "::" is
>> the more forward-thinking route.
> 
> Anyway, even if you implement this completely in Eshell, I recommend to
> write a file-name-handler for this. Potential 70+ primitive file
> operations cannot be handled w/o such a basis, I fear.

My initial plan here was to have Eshell treat "/local:" similarly to any 
other Eshell-specific syntax (e.g. $VARIABLE expansions): Eshell would 
parse it, convert it to a regular filename, and then no other code would 
ever see the "/local:".

That might not actually work in practice though (I haven't written the 
code yet to prove it), so another option would be to do like you say and 
add a real file-name-handler within Eshell buffers for this.

Message #89 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Fri, 10 May 2024 08:45:18 +0300

> Date: Thu, 9 May 2024 13:30:57 -0700
> Cc: 70792 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > We could start with "/local::". I'm simply not so optimistic like Jim,
> > that it will be easy. Likely, se need a full Tramp backend for this, say
> > tramp-local.el. The respective file name handler should remove the
> > "/local::" prefix from the arguments, call the original file operation,
> > and add the "/local::" prefix on the results where appropriate.
> > 
> > And somehow, I'd like to check that this is called from Eshell only. Am
> > I paranoid? Will people use it on their own?
> 
> Maybe the better solution would simply be for "/local:"[1] to be an 
> Eshell-only syntax that DTRT within Eshell. There shouldn't be any 
> conflict so long as Tramp promises not to add a "local" method. :)

I agree that it's a better solution: since the problem is Eshell-only,
having the solution in Eshell has several advantages.

Message #92 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Fri, 10 May 2024 12:35:48 -0700

[Message part 1 (text/plain, inline)]

On 5/9/2024 10:45 PM, Eli Zaretskii wrote:
>> Date: Thu, 9 May 2024 13:30:57 -0700
>> Cc: 70792 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> Maybe the better solution would simply be for "/local:"[1] to be an
>> Eshell-only syntax that DTRT within Eshell. There shouldn't be any
>> conflict so long as Tramp promises not to add a "local" method. :)
> 
> I agree that it's a better solution: since the problem is Eshell-only,
> having the solution in Eshell has several advantages.

Here's a patch for the first part of this: it just changes the Eshell 
syntax for "run this command on localhost even if cwd is remote" to use 
"/local:program" instead of "/:program". Now, users can instead use "/:" 
in an Eshell command name to *disable* any remote file handlers.

For example "/:/ssh:user <at> remote:/foo" now means, "Run the program 'foo' 
on the current host, located in the directory '/ssh:user <at> remote:/'."

Next, I'll work on updating my original patch for this bug to use the 
new syntax (possibly with a new way of handling "/local:" if I need it). 
I wanted to get this ready first though so that Eshell is in a 
release-ready state for the upcoming Emacs 30, even if I don't finish 
the rest of this in time.

[0001-Use-local-prefix-in-Eshell-to-run-local-commands-whe.patch (text/plain, attachment)]

Message #95 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Mon, 13 May 2024 09:39:33 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> Here's a patch for the first part of this: it just changes the Eshell
> syntax for "run this command on localhost even if cwd is remote" to
> use "/local:program" instead of "/:program". Now, users can instead
> use "/:" in an Eshell command name to *disable* any remote file
> handlers.

I've scanned the changes, and they look OK to me as far as I unsderstand
them.

Best regards, Michael.

Message #98 received at 70792 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70792 <at> debbugs.gnu.org
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
 absolute file names within the current remote connection
Date: Wed, 15 May 2024 19:12:11 -0700

On 5/13/2024 12:39 AM, Michael Albinus via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:
> I've scanned the changes, and they look OK to me as far as I unsderstand
> them.

Thanks for taking a look. I've now merged this part as e260bf1be7b. 
(Leaving this bug open while I work on the rest of it.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.