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: Eli Zaretskii <eliz <at> gnu.org>
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 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.

Previous Next

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