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

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Sun, 5 May 2024 21:00:02 UTC

Severity: normal

Tags: patch

Found in version 30.0.50

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




This bug report was last modified 1 year and 33 days ago.

Previous Next


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