From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter 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: Mon, 6 May 2024 13:05:28 -0700 Message-ID: <320dbb86-07b5-03ce-3ef0-a25d7978c214@gmail.com> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@gmail.com> <86y18nb3ap.fsf@gnu.org> <86cypybx3f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25073"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70792@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 06 22:07:16 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 1s44cE-00068H-Au for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 May 2024 22:07:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s44bt-0004X0-AZ; Mon, 06 May 2024 16:06:53 -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 1s44bg-0004Iv-2X for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 16:06:43 -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 1s44bd-00018D-JQ for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 16:06:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s44c1-0006lJ-Ty for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 16:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 May 2024 20:07:01 +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.171502597725977 (code B ref 70792); Mon, 06 May 2024 20:07:01 +0000 Original-Received: (at 70792) by debbugs.gnu.org; 6 May 2024 20:06:17 +0000 Original-Received: from localhost ([127.0.0.1]:39994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s44bI-0006kv-5C for submit@debbugs.gnu.org; Mon, 06 May 2024 16:06:17 -0400 Original-Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:58822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s44b2-0006kS-Mx for 70792@debbugs.gnu.org; Mon, 06 May 2024 16:06:15 -0400 Original-Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1eb24e3a2d9so22813535ad.1 for <70792@debbugs.gnu.org>; Mon, 06 May 2024 13:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715025930; x=1715630730; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=KSpN4MzqKcb1D/MEtjbcTB1hfCIQVixO+eCRiEFiLrI=; b=g4sAr1s3g0JTbQ3uy4yLBnHQCI9PpJ6sqvnJCmToi4//m8uLGsUr3u/QaSHdYx5DYi MZj6IZfd2Gb5mvip8Dn0/xaik1IGxsuRl4yXCIHC6RYlcew/lVWPsyK+WPeJ09D6zsam uYNmWvK2mgPf76aPK+CdhCOWDs+EgNDIQn83n9pMrEsHINMEz1aLr2NQ+J3/zh0mEV0H ptbaU9X96238BkUMnsWnkVEewwKsrNFS6efrUqVqi7bIIVg7751HRGPE3xy/crUCxqdB S9s20kUQlkT/EYiI4DGpPx03g8L3JgBVbDc+rKQNwev4rMOP38GqXqXuByEH9OBPA14+ FYCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715025930; x=1715630730; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KSpN4MzqKcb1D/MEtjbcTB1hfCIQVixO+eCRiEFiLrI=; b=s0Q5zEui/x78qFALILejckp3JiPdllRJBv0+bQcQNz+biMSsHz2TVsa8ba1mfm1jdT kGNZViUfyun/ulprBZ/jzpqxw/BqqO13SEkxZx/v4z03yekrxYEYDA6Y9MIvrMSNJrPU XmrOErBDTlsq4XDprP2zZqXjfVR7Q9jNudYEZr0C7CqkT3QnO0a5nZQwvxrO+bgdvtbX ZZHj3TkuSAxYMFaVURtlHrJe8HxQpFCxw6nfBL4SPrb+bPAZ9PhTpuaHXdagLBlCiO7B Bssl3oGw+BqvdXd2gZKUQIKMX2/ko4HWfBFps1xzky9Xsxf9DfG/Nz+himcVkiCsviOy pTLQ== X-Gm-Message-State: AOJu0YzO+4RHqNvagcboK867ZxfMrRY+7Ct4FTQ6Vpd1RJH8dqvgpKP+ Yop735W2dq4jZHgsmF5MNKHwVs1e/Nd+9tM4I2VB03OsC17DbYP4 X-Google-Smtp-Source: AGHT+IGphhOW50/T8egq6n9RGHMJqqOMzO21KQLSOl1T9vphZpkXrHHxKKt8JlhbSL8l+Osa1r1M4Q== X-Received: by 2002:a17:902:f648:b0:1e4:19e3:56cb with SMTP id m8-20020a170902f64800b001e419e356cbmr17388656plg.12.1715025929645; Mon, 06 May 2024 13:05:29 -0700 (PDT) Original-Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id y8-20020a17090264c800b001e868e29fabsm8877056pli.251.2024.05.06.13.05.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 13:05:29 -0700 (PDT) Content-Language: en-US In-Reply-To: <86cypybx3f.fsf@gnu.org> 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:284608 Archived-At: Before I respond to the initial points, I wanted to emphasize one part first: my patch is intended to make Eshell behave more like other shells and to simplify how users can perform "common" tasks. By "common", I mean specifically that, when you've started a remote "session" (by cd'ing into a remote host), normal filenames all refer to something on that host, just like if you used SSH on a terminal. To refer to something on another host, you use remote file name syntax (or /:quoted file name syntax to explicitly refer to a local file[1]). Also, even with this option, absolutely nothing changes about how Eshell works when the current directory is local. On 5/6/2024 11:43 AM, Eli Zaretskii wrote: > I know this, but we are explicitly talking about _absolute_ file > names, which normally trivially expand to themselves. _That_ is the > problem which I was talking about: you seem to propose a feature where > an absolute file name is sometimes expanded not to itself, but to a > remote file name. Correct. Eshell's transparent remote access forces us to consider a question that other shells don't have: how do I refer to a file that's absolute *on the current connection*? 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.) >> ##### 2. Change to an absolute directory, stay as root >> /sudo:root@host:~ # cd /etc; pwd; *pwd >> /sudo:root@host:/etc >> /etc > > 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' >> ##### 3. Change to the home directory, stay as root >> /sudo:root@host:~ # cd ~; pwd; *pwd >> /sudo:root@host:/root >> /root > > Likewise here: how to chdir to the _local_ home directory? quote it? If your cwd is local, just "cd ~" is enough. If cwd is remote then you'd use "cd /:~". >> ##### 4. Write the expanded "~/foo.txt" to the *local* "~/bar.txt". >> ##### Using "/:" quoting lets you explicitly name a local file >> /sudo:root@host:~ # *echo ~/foo.txt > /:~/bar.txt >> /sudo:root@host:~ # cat bar.txt >> /bin/cat: bar.txt: No such file or directory >> >> ##### 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 compared to the equivalent command that all happens on a single host (which I think would be the more-common scenario): ##### 4b. Write the expanded "~/foo.txt" to the remote "~/bar.txt". ##### Using "/:" quoting lets you explicitly name a local file /sudo:root@host:~ # *echo ~/foo.txt > ~/bar.txt /sudo:root@host:~ # cat bar.txt ['-c', '/root/foo.txt'] The example I chose is somewhat contrived, of course. I just wanted to show off how you can mix local and remote expanded file names in a single command for this case. > Also, am I still able to specify remote file names when my default > directory is local? Or do I have to chdir to a remote directory > first? Yes. Just type the full remote name, like "/ssh:user@remote:/file". >> ##### 6. "bar.txt" ended up here >> ~ $ cat bar.txt >> ['-c', '/root/foo.txt'] > > Is "/root/foo.txt" a local or remote file name? (I know you used > *echo, but the file bar.text has no memory of that.) At this point, it's just text, so *technically* it's neither. However, that text was created from the local portion of a remote file name, so the string is local to the remote host where Python was executed. (In the example, I used "sudo", so I suppose local/remote are misnomers, but the same reasoning applies if you used "ssh".) >> In the last line above, note that the value we wrote to our file is just >> the local part. > > And that's considered a feature?? As mentioned above, this is a contrived example to show the lifecycle of these names, but yes. The Python command I used just shows off the internals. For a more practical example, suppose I want to write the word counts of a remote file into a local file. This might actually come up in practice: if the remote file is large, I don't want to copy the whole thing locally first. With this new option, I could do the following: /ssh:user@remote:/somedir $ *wc ~/file.txt > /:~/counts.txt Today, you could do this like so: /ssh:user@remote:/somedir $ *wc ~/file.txt > ~/counts.txt That looks a bit simpler at a glance (no "/:"), but now there's a problem lurking: "~" points to the remote homedir in the first case, and the local homedir in the second. Now suppose a slightly different case. What if I'm in a remote directory and want to write this summary file to my remote homedir? With this new option, I could type the following: /ssh:user@remote:/somedir $ *wc ~/file.txt > ~/counts.txt Today, you'd need to do this: /ssh:user@remote:/somedir $ *wc ~/file.txt > /ssh:user@remote:~/counts.txt Or this: /ssh:user@remote:/somedir $ cd /ssh:user@remote:~ /ssh:user@remote:~ $ *wc file.txt > counts.txt In both of the "today" cases, you need to type "/ssh:user@remote:~" somewhere, which is the thing I'd consider to be unnatural and a lot of typing. >> With this option *disabled* (the default), there are some problems that >> (in my opinion) make working with remote file names in Eshell even more >> complex. For example, suppose I'm on a remote host, and want to change >> to my home directory on that remote. There's not an easy way to do that: > > 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". 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. >> Or suppose my cwd is /ssh:user@remote:/somedir. If I run "cat >> /etc/hosts", Eshell will print my local hosts file. But what if I run >> "cat -n /etc/hosts"? Eshell's "cat" implementation doesn't understand >> "-n", so it calls the "cat" on "remote". Now it prints the remote hosts >> file. You can only predict which hosts files you'll get if you know >> exactly which flags Eshell's "cat" implementation supports. > > 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. You previously cd'ed into a remote directory, expressing your intention to Eshell explicitly. With my patch, there's no guesswork here. At least the way I interpret your message, this patch does exactly what you suggest: because Eshell knows that you consider yourself on the remote (you cd'ed into it) and that you chose this new option, it knows that "/foo/bar" should refer to a file on the remote system, ensuring that your commands work the same no matter whether they're Lisp-based or external programs. Without using this option, I don't think there's a way to DTRT in general. Currently, the string "/foo/bar" is just that, a string. It carries no information about the host Emacs should look on. Existing commands (whether Lisp-based or external) will just look on the host where the process is running. Conceptually, my patch adds annotations to these strings so that we can determine authoritatively which host they belong to. [1] Eshell has some code to handle this syntax, but it's built on the one of the intended uses for quoted file names. From "Quoted File Names" in the Emacs manual: "For example, you can quote a local file name which appears remote, to prevent it from being treated as a remote file name."