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: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
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: 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

Previous Next

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