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

Previous Next

Full log

View this message in rfc822 format

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 70792 <at> debbugs.gnu.org
Subject: 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

Previous Next

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