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 11:28:54 -0700 Message-ID: References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@gmail.com> <87y18mdglp.fsf@zephyr.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16344"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70792@debbugs.gnu.org To: Sean Whitton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 06 20:29:54 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 1s4361-00044z-G7 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 May 2024 20:29:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s435t-0008RV-Rj; Mon, 06 May 2024 14:29: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 1s435m-0008Lg-IV for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 14:29: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 1s435m-0006jp-8o for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 14:29:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s436A-0005TW-Ar for bug-gnu-emacs@gnu.org; Mon, 06 May 2024 14:30:02 -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 18:30: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.171502017021014 (code B ref 70792); Mon, 06 May 2024 18:30:02 +0000 Original-Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:29:30 +0000 Original-Received: from localhost ([127.0.0.1]:39510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s435d-0005Ss-Kx for submit@debbugs.gnu.org; Mon, 06 May 2024 14:29:29 -0400 Original-Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]:49555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s435a-0005Sm-L9 for 70792@debbugs.gnu.org; Mon, 06 May 2024 14:29:27 -0400 Original-Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1ed835f3c3cso21563815ad.3 for <70792@debbugs.gnu.org>; Mon, 06 May 2024 11:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715020136; x=1715624936; 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=h0km4g0axG1kSbj3R0+B4KMiWsCt9wntYhRqEIUp7kM=; b=WXHdfdc/8GQp2CR+DUwrFT0BNXVvwgWzsdbOCOf43ZNhDJ0j0G1uKKGDOLIUxPbEZ0 2ob7dzaGPuCmP/OcBtvIiATCfvBTjKx0iFLD4wxA8zKnAdGagBNFQef31xPVmGDgWgbA UjqdG0zLB+cpV9Szzi+6IdYGU1XO4JJgzS5luHqFDECr7/qjVk/w5RbCra3V7t+IgoMO 8wsZVoztpul2rKv4uP6YEwJOcBVlrNBP8arhFaAfOAxRmo0WRq/nvzoxRzXd3Yi34a/P 9UztP+LkOC+g91nyErQuHNGhaHhZOY8z3bWmccMKwCjgYWFfP9kiLOPiTrtmCZLCrhzd ma9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715020136; x=1715624936; 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=h0km4g0axG1kSbj3R0+B4KMiWsCt9wntYhRqEIUp7kM=; b=J5xRHhYBwGLEFIdazxUUkT/OygfoBoHS5XlG/P04TjT2WqxMAS4gCDAFwxffhoAfsU Rdy7zqSL7T3KNIzwnySwWcLOC9qeDgbSvoglyxa4b+J4QbBsV/n5o534fLrfEfoAkN8P ZpLQ9nWGGpSly2+2yAvhBtEHnH1885jlV3eyIVty46oeSUtrEn5AT8CeucM6Sx1iFC5B dVpt+MYVd6CWoXPxdlc8FxQUk5StzcLj0GYAlsA2ruvthgD7au4FyAkifNg4RWVGB+1+ MmYghf+nYI0PUzairJ7jcKq4O1a0YZK9r0zn4+r8HevKrQpbBmQqY1xN1Ihadu1uhqA9 CEOA== X-Gm-Message-State: AOJu0Yyd//O6uXFozkn0Dz9xTJl+A+XymEoYp6mVOnkAwfF98V/STT6D SD6CRXv06uGIvwJisk7zaVtIdA4kDIhlqlqhfUDMotClaxv81kTBOCeqUQ== X-Google-Smtp-Source: AGHT+IH0BOdyEczNenkkmwz9pM+bjQDPL9ZzJDipqgx0sKGeixM0B2GH9bmVSgAOOsu89WJFK0YQxA== X-Received: by 2002:a17:902:7409:b0:1e0:a22a:623e with SMTP id g9-20020a170902740900b001e0a22a623emr10456559pll.21.1715020136059; Mon, 06 May 2024 11:28:56 -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 j11-20020a170902da8b00b001eb5c4054a4sm8517493plx.237.2024.05.06.11.28.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 11:28:55 -0700 (PDT) Content-Language: en-US In-Reply-To: <87y18mdglp.fsf@zephyr.silentflame.com> 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:284598 Archived-At: 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 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. > > 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 ‘/ssh:remote:~/file’ is remote, but current directory is 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 ‘/:/etc/A’ is local, but current directory is remote