From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 09:50:51 +0100 Message-ID: <87pltyatuc.fsf@zephyr.silentflame.com> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@gmail.com> <87y18mdglp.fsf@zephyr.silentflame.com> Reply-To: Sean Whitton Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18582"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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 10:52:06 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 1s4GYQ-0004c9-G0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 May 2024 10:52:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4GY5-0002w8-EY; Tue, 07 May 2024 04:51:45 -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 1s4GXy-0002vq-E6 for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 04:51:39 -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 1s4GXx-0008J5-So for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 04:51:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s4GYM-0006me-98 for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 04:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sean Whitton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 May 2024 08:52: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.171507189126060 (code B ref 70792); Tue, 07 May 2024 08:52:02 +0000 Original-Received: (at 70792) by debbugs.gnu.org; 7 May 2024 08:51:31 +0000 Original-Received: from localhost ([127.0.0.1]:42443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4GXq-0006mF-OD for submit@debbugs.gnu.org; Tue, 07 May 2024 04:51:31 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:45556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4GXn-0006lt-1L for 70792@debbugs.gnu.org; Tue, 07 May 2024 04:51:28 -0400 DKIM-Signature: a=rsa-sha256; b=SRNmw1hP4ZBv9sheIarBTJQXn+j6szw6dtr26cJDlcjMS3HIq2vmZR5gO+TOfCG6fyCpyWcoC5gYIE7RbaPv0OYuB5aTYiGZerIsLRDHQSf3edljPuQ3NjD0FrVlKRO0qYnG4oyouzeAKpriI4ZGfNUQlCUfCn8b4Jnk/O3oRHNJrfZKJ+dUbTxN7t8+mH3NuH3CsuluXfKQBv2Vh8g/i0oOTeO8T9s/PcXGcMtBTkdv4j8LmWFdyarqUjK4o99WYx6hs8FT8CHgqHtBrvoAg6l1WdOmNzd081YCrxbUEVOLqvpHffpMChA75WAzocSge8Jn0mZyDa2F3Bi3jhThow==; s=purelymail2; d=spwhitton.name; v=1; bh=B5punJ+wZpd0nIPmDPKGdAXvEvZLoYP3hn0LbU6tImQ=; h=Received:Received:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=UNnMCoKYEKe7iz5h2+sBZRSvPtF52O6xTsPCFDylfhscBnoAHOjEZ+rcdUlGP+S3oYBSqFp3Us01/GirElXs0Eng2lkCFf+++Lgbw4chYV0RSGXPF+ouC8PfwyiQtGnMAO4JfezlEgSXDZeOP+S8Lsy+ggUPS82n25uHjdBavl8OLkVFejQaKCmW4cwRGpeGiCzDZ7SHwH+T7VadkWDjiz08IUPNPv/E4owZn6DNP5yKAwQtDe5WTzQYCt2z25VJWC/Z6oTxRJaQ4yadmUOi+lIEgxRop/5CBHm1JCSte5jcU4UxMcldyr8qBa/NVCfFI1C0h/VoJ0jrVg41xvGzwg==; s=purelymail2; d=purelymail.com; v=1; bh=B5punJ+wZpd0nIPmDPKGdAXvEvZLoYP3hn0LbU6tImQ=; h=Feedback-ID:Received:Received:From:To:Subject; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 70792@debbugs.gnu.org Original-Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -325503005; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 07 May 2024 08:50:53 +0000 (UTC) Original-Received: by zephyr.silentflame.com (Postfix, from userid 1000) id E4B09940403; Tue, 7 May 2024 09:50:51 +0100 (BST) In-Reply-To: (Jim Porter's message of "Mon, 6 May 2024 11:28:54 -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:284632 Archived-At: Hello, On Mon 06 May 2024 at 11:28am -07, Jim Porter wrote: > On 5/6/2024 9:56 AM, Sean Whitton via Bug reports for GNU Emacs, the Swiss > army knife of text editors wrote: >>> When you think about how it's implemented, this makes sense: Lisp comma= nds >>> 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 obv= ious >>> when you're running a Lisp command or not. Eshell provides Lisp >>> implementations of some common commands, like "cat", but it also transp= arently >>> 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'. > > Yes, but this breaks in non-obvious ways if Eshell's "cp" implementation = falls > back to the external program. For example, today: > > ~ $ cp file /ssh:remote:~/file # copies "file" to a remote host > ~ $ cp -b file /ssh:remote:~/file > /usr/bin/cp: cannot create regular file '/ssh:remote:~/file': No such > file or directory > > Or the second line might work if you get unlucky, or pass --parents, or... > > With the new option, Eshell is smart enough to recognize that this is a > problem even before it calls "/usr/bin/cp": > > ~ $ cp -b file /ssh:remote:~/file > =E2=80=98/ssh:remote:~/file=E2=80=99 is remote, but current directory i= s local > > Similarly, if you're in a remote directory and try to specify an absolute= file > name on that remote to copy, this is what happens today: > > /ssh:remote:~ $ cp /etc/A /etc/B # copies local A to local B > /ssh:remote:~ $ cp -b /etc/A /etc/B # copies remote A to remote B > > With the new option, both cases copy remote A to remote B. If you wanted = to > copy local A to local B with the option enabled, you could do this: > > /ssh:remote:~ $ cp /:/etc/A /:/etc/B # copies local A to local B > /ssh:remote:~ $ cp -b /:/etc/A /:/etc/B > =E2=80=98/:/etc/A=E2=80=99 is local, but current directory is remote Right okay. I guess you are basically saying that this aspect of Eshell's design turned out to be a bit too clever, and doing things in a more predictable way, always based on the cwd unless explicitly otherwise, will probably turn out to be more useful for most users. --=20 Sean Whitton