From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 14:55:05 +0300 Message-ID: <865xvpbzvq.fsf@gnu.org> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@gmail.com> <86y18nb3ap.fsf@gnu.org> <86cypybx3f.fsf@gnu.org> <320dbb86-07b5-03ce-3ef0-a25d7978c214@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23062"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70792@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 07 13:55:53 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s4JQG-0005jR-OB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 May 2024 13:55:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4JQ6-0002Ou-BN; Tue, 07 May 2024 07:55:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JQ2-0002NP-Bg for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 07:55:38 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s4JQ2-0006EE-0l for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 07:55:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s4JQQ-0003S7-9x for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 07:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 May 2024 11:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70792 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70792-submit@debbugs.gnu.org id=B70792.171508294613265 (code B ref 70792); Tue, 07 May 2024 11:56:02 +0000 Original-Received: (at 70792) by debbugs.gnu.org; 7 May 2024 11:55:46 +0000 Original-Received: from localhost ([127.0.0.1]:42572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4JQ9-0003Rt-Ns for submit@debbugs.gnu.org; Tue, 07 May 2024 07:55:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4JQ4-0003Rg-98 for 70792@debbugs.gnu.org; Tue, 07 May 2024 07:55:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JPa-0005y5-1e; Tue, 07 May 2024 07:55:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QIBGvPqIjGYbtW4izYGsik1B38bWtB5BU+meFr0mivA=; b=JgJ2Jy1ifI27 CE6NtsPfIvxKn3I0DrCjzvGxoqUcJK05yAJogaoeorTbi6OIdA0tGnP2h6+a5j+CBJ9fnyVh2Hpmy n13tL5eukTH+AvKwKn6jXdstW0RUbH+qk1avt+8vcuM0eOTAZnLjJ+MpYOY4KFXHFo9I9l2wIxS7P RlFBiMaggJnGLCC0sDJ6vIV+U3NIgyW2EdXQjrK0mBWYMqUDcW7TjU3DAdeJs0JnpZeC5PeNbvmHP kW75AA6QFDI64wu42eP3pqP5ykEo+jr6NtQNAAERB1QynKmE9cB4ctjeP0iHY2Fg45jhK3stz9EtC nOjg0+L1wClUifvW+OQ2TQ==; In-Reply-To: <320dbb86-07b5-03ce-3ef0-a25d7978c214@gmail.com> (message from Jim Porter on Mon, 6 May 2024 13:05:28 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284637 Archived-At: > Date: Mon, 6 May 2024 13:05:28 -0700 > Cc: 70792@debbugs.gnu.org > From: Jim Porter > > Currently, for Lisp-based commands, you have to type the the full remote > part of the file name again, like "/ssh:user@remote:/some/file". For > external commands, you have to type just the local part, like > "/some/file". For commands that could be *either* Lisp-based or external > (this includes most Eshell built-ins), there's no way to do this. > (Unless you know exactly how Eshell implements things.) I think asking the user to specify the full "/ssh:..." file name for remote files makes this easier, because Eshell could then transparently handle also the commands which can be external or internal. That's one confusing problem down. > > So you are saying that to chdir to the _local_ /etc I must quote it as > > in "/:/etc", or somesuch? If not, how do I chdir to a local directory > > by its absolute file name? > > If your current working directory is local, "cd /etc" is enough (since > the current host is the local one). If your current working directory is > remote, any of the following would change back to the local /etc: > > cd /:/etc > cd \/etc > cd "/etc" > cd '/etc' The first form I could maybe agree to. But the others are standard shell quoting, so I think repurposing them for "escape to local file names" is not a good idea, since quoting is used in shell commands for other reasons, notably for quoting special characters. We need to allow user to quote file names without implying the name is local. So I think the last 3 examples should not mean local file names. > >> ##### 5. Change to the *local* home directory, stop being root > >> /sudo:root@host:~ # cd /:~; pwd; *pwd > >> /home/jim > >> /home/jim > > > > That's awful! Completely un-natural, let alone a lot of typing! > > It's only two extra characters Two extra characters _per_file_name_! > > The simplest solution is to introduce a special command for that, so > > that the user could tell Eshell explicitly whether he/she wants to > > consider him/herself on the local or the remote host. Similar to what > > we did with rlogin or ssh. > > Eshell users already have a command for explicitly moving between local > and remote hosts: it's just "cd". Then why do we need to change anything at all? My suggestion is to introduce a notion of "state", either local or remote, and make it so that the "state" defines the semantics of file names without the Tramp "/METHOD:..." prefix: such names _always_ mean files on the host specified by the "state". In particular, quoted file names also specify files according to the "state"; they do not "escape" to the other host. This matches what you get from a normal shell: if you login to a remote host, _all_ the file names are from the remote host. It is okay to use the value of default-directory as the "state", but we should use it consistently. the only way of "escaping" from the current host is by using fully-qualified file names that specify the host explicitly. The advantage of this is twofold: (a) users will always know what do file names refer to, and (b) Eshell will always know that, and will be able to DTRT in all such cases by converting the file names the user typed to the appropriate form under the hood as needed. > I'm not familiar with what we do about rlogin and ssh though. Where > would I find that info? If someone else has come up with a better way to > handle a similar scenario, I'd be happy to take a look. See above. The advantage of those is that they never allow you to mix file names on different hosts except explicitly. > > If Eshel knew that I consider myself on the remote, it could have > > modified the logic accordingly, to DTRT. Without such an explicit > > knowledge, we are _guessing_, and our guesses are bound to be wrong > > sometimes. > > Unless I'm misunderstanding what you mean here, Eshell *does* know that > you consider yourself on the remote. Then why is external vs internal commands an issue? why cannot Eshell DTRT by invoking the command which can handle the file names the user typed? > Without using this option, I don't think there's a way to DTRT in > general. My point is that we should try to find such a way. Personally, I don't think it's a problem to find it. > Currently, the string "/foo/bar" is just that, a string. It > carries no information about the host Emacs should look on. The "state" should supply the missing information, and the "/METHOD:..." notation should allow the user to override what the "state" says implicitly. > Existing commands (whether Lisp-based or external) will just look on > the host where the process is running. Some kind of dispatch should look at the "state" before it runs the command, and decide which variety of the command to run.