bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute fi


From: Eli Zaretskii
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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]