Received: (at 70792) by debbugs.gnu.org; 8 May 2024 18:33:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 08 14:33:26 2024 Received: from localhost ([127.0.0.1]:50191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4m6Y-0007CI-0N for submit <at> debbugs.gnu.org; Wed, 08 May 2024 14:33:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s4m6U-0007CB-Id for 70792 <at> debbugs.gnu.org; Wed, 08 May 2024 14:33:24 -0400 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 <eliz@HIDDEN>) id 1s4m5x-0005EA-Sh; Wed, 08 May 2024 14:32:50 -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=XpV3rEkLLaJDWdt5IWObaOUrAeM6lIwAzSTsPjXVrBE=; b=DVZKzZeVYMAt BJf1C61Y3ESBHNG/99Xoh6uSd57yVsbxcs276c5Grcs8BqNTnd6VRJEIf8aEMGLivG+z7h8lQH6kM aE5HFmpPFzxq7lvbTBf/gblD8WCYg2eAd7054OPgu3pmBXe9r2CrWrzYgQeIciRqIxnOGdXOaM2d3 lZ8mkltQCqp40jSpTJLfEpRPW0IbudRHEqgXfR7q1CSkXDYdFIMO0uZrwTQXAZZGgtXvAryLG3f0u 11z8YRyHjGjgjwYR2nNACFlLg+8NXam8zF0yvqiGL/MK4qWZom2Ryrvt+fxOR6FbkUJTVBJYrvTlP xqn2E1M6ywwDbucLH26a7w==; Date: Wed, 08 May 2024 21:32:42 +0300 Message-Id: <86wmo4888l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN>, Michael Albinus <michael.albinus@HIDDEN> In-Reply-To: <b7c6a012-cdb0-5f1e-59fc-42dc7470a8dc@HIDDEN> (message from Jim Porter on Wed, 8 May 2024 09:13:59 -0700) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> <865xvpbzvq.fsf@HIDDEN> <920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN> <86a5l0a195.fsf@HIDDEN> <b7c6a012-cdb0-5f1e-59fc-42dc7470a8dc@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Wed, 8 May 2024 09:13:59 -0700 > Cc: 70792 <at> debbugs.gnu.org > From: Jim Porter <jporterbugs@HIDDEN> > > On 5/8/2024 6:20 AM, Eli Zaretskii wrote: > > I think "/:" quoting should not change the host of the file name. > > That's because the user might need this quoting for file names on the > > remote host. > > Not to say we *should* do this, but if we kept the "/:" syntax of my > patch, a user could still /:-quote a remote file name in Eshell by using > the fully-qualified name like: "/ssh:user@remote:/:/blah". > > I can construct an argument for why using /: this way in Eshell would > make sense, but maybe it's just needlessly "clever"... We do need the ability to quote like "/ssh:user@remote:/:/blah". That's why I think quoting should not "escape to local". Another reason that I think "/:" quoting should not escape to local is that "/:" is for protecting file names from being interpreted as referencing another host; a simple name like "/foo/bar/baz", when quoted as "/:/foo/bar/baz", should resolve to itself. > (As a note, Eshell already uses /:-quoting to mean "on the local host" > in one spot: for the command to run. However, I added that for Emacs 30, > so we can still change it without worrying about compatibility issues. > See the manual here for more info: > <https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.) I think we should remove that before we release Emacs 30. It's wrong to interpret quoting this way. > > If the user wants to specify a local file name while default-directory > > is remote, the user can use the normal Tramp "/METHOD:..." notation. > > How about a new "local" method? Then users would type > "/local::~/some-file.txt". That's more typing, but it's also more clear, > and doesn't repurpose an existing syntax used elsewhere in Emacs. Don't we already have that with "/localhost:" or somesuch? > If I go this route, I'm not sure whether it would be better to make > "local" a real file name handler available everywhere in Emacs despite > only being useful for Eshell, or if Eshell should just strip out the > "/local::" prefix before sending it to other parts of Emacs. I'm leaning > towards the former though, since the latter seems like a hack that could > have unforeseen consequences. I'd like Michael's opinion on this, since we will be "invading" the Tramp methods space.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.
Received: (at 70792) by debbugs.gnu.org; 8 May 2024 18:18:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 08 14:18:05 2024
Received: from localhost ([127.0.0.1]:50120 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s4lrg-00072k-PW
for submit <at> debbugs.gnu.org; Wed, 08 May 2024 14:18:05 -0400
Received: from mout.gmx.net ([212.227.15.15]:33505)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <michael.albinus@HIDDEN>) id 1s4lrc-00072K-Vx
for 70792 <at> debbugs.gnu.org; Wed, 08 May 2024 14:18:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1715192248; x=1715797048; i=michael.albinus@HIDDEN;
bh=AtnP01dizX/+ivANomp68+iavpmR/NanXHLGgGfJllM=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=IaA4ExZInfwchkNrw251OXhIzi68EvkfWZyl5tggMrOfE2A3g5J6uRUtkiz4s698
7xczCm6tyUIbSW3/he7eoWIvxX2l6VKBV6Ry5k0X5i8Em64pSi0XPYAeLdQIZ5txW
UH58zpLfAK1FCXvoQjqsBTOaIeRAf9K/necs0XmEHNgbID7jdutd5U2muprtIA1rq
wPBc1qRD6FpDMlgtcYQEjqb9auwC5rG1/7GK8df+LEPqj+qcafTTg3sX+nkpb/8oX
p3eqUITtEW4OO+KJGQEQf58PkxH7xjB2R4TnDmXTSPQcETbcKa6l8DEqAqHrDRBTZ
vv8j9N/JjMI49/mrGQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from gandalf.gmx.de ([185.89.39.4]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU9Z-1sYcl12grb-00hvvP; Wed, 08
May 2024 20:17:28 +0200
From: Michael Albinus <michael.albinus@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
absolute file names within the current remote connection
In-Reply-To: <86a5l0a195.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 08 May
2024 16:20:38 +0300")
References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN>
<86y18nb3ap.fsf@HIDDEN>
<fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN>
<86cypybx3f.fsf@HIDDEN>
<320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN>
<865xvpbzvq.fsf@HIDDEN>
<920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN>
<86a5l0a195.fsf@HIDDEN>
Date: Wed, 08 May 2024 20:17:27 +0200
Message-ID: <87ttj82mo8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:BFKbeCzc2r6FUMkj0JV8Lg+0AnW7UFiES5s1zQLyI1/ftys+XpZ
LlJMY+N1oNGEITeIKp72tnjDr+5Q/dVOWQNC40fI7M6BDOLKE7Ct7VXKZ8Rv2BRdKlBjwSr
MiPJRLJCCm6ef0B9mRm/m4GOZ+NUjXatMXyUe0LzCl3qbL919BbVS2vp1TX7twfUS0Jn7Tv
uF0iad3C/RA+bxCoEEQUA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:BvHmmyPaS0s=;UWrQfMkzCDMkhxxLHSgBHK1LN4D
8JwxWSkga61TC4h/ib+TZad0ER11jq8hijlS7qnZG5hbEKlJ63DU7jx/gAOd+9xHfqpdKQEkT
FURj+bwaA9YT4efibRAMjU3tpkYB1nISEuJ5LRFMRERSQb54JPqswpscPc7I+7yJcRTILTqjg
dEEoUuEWotrTvO2xPYb9+yTDIX8oq5qMKiCfWkVytDDQDMn7o2QebLIZyUIOt9VdKz12pLTte
5RyrJR/OvZX8f26ctagAaesNiJWHqSB09kdJv6sNbjesP7/wsHzAbrYjljBaI4uD8TUB1Ga/l
JMDBKkTmkUzjGNagjacmrsEZlgRHz1HUsESRYUCZvWprlWPYBZdARsf7hNuGR3arJlGWljfAa
dxYFDSQ76VgQvWSg/QhzQ78tTIxVfUQw9XNg1nhY8USG0SoNlVdmJENzs0KH1bCFQib+1UKt8
zvlQJJYifeyHnT0VtWKEcbJ1WMc0fKC0ilmnRSKl3B1dFXOZ9R+v3ODQohB1c0E2J0ScP65FZ
u7W8Qu5gpCPX1EKA5zNLNedCtRa7KW4MvdQQEZbZD8vk4RHYifWYtTlE+yeKkxu2Ws7qFPOYl
XJSIJeUs5Wrt7CENO7rFgjo+aAxW1iMUXDxGOkXJ/FNUv38UvoHf3s1ZuTOlwHcFpX18o2bQh
Nnfr4famUnjPWsUQpqH2EZW2CgoD8K20KQpIY3vV0ylgBK4hU5mYwiisHnhBopVA4CLgy2+9P
W+GLvdsa7uUmZa4LPQjBhKtzPTyYrwi4n/y79hhFvu1r692K5PrBNSIapwaCAO1nylkOag/sx
YSqegCfk2l5nAcQRQAglwPVBZmksOkPIPEZiuwVSxZZgg=
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi, >> There's just one open question
with this: if I'm on a remote system, how >> do I type the fully-qualified
*local* file name? I propose using "/:" as >> the prefix to mean "always
look on the local [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.15 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.39.4 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.15 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70792
Cc: Jim Porter <jporterbugs@HIDDEN>, 70792 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi, >> There's just one open question
with this: if I'm on a remote system, how >> do I type the fully-qualified
*local* file name? I propose using "/:" as >> the prefix to mean "always
look on the local [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.15 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.15 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.39.4 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Eli Zaretskii <eliz@HIDDEN> writes:
Hi,
>> There's just one open question with this: if I'm on a remote system, ho=
w
>> do I type the fully-qualified *local* file name? I propose using "/:" a=
s
>> the prefix to mean "always look on the local host", so "/:/etc/foo.log"
>> is a local file name no matter what. For this case, I'm open to other
>> spellings, so long as we have *some* way to fully-qualify a local file =
name.
>
> I think "/:" quoting should not change the host of the file name.
> That's because the user might need this quoting for file names on the
> remote host.
>
> If the user wants to specify a local file name while default-directory
> is remote, the user can use the normal Tramp "/METHOD:..." notation.
FTR, we *have* already two different kinds of quoting. "/:<something>"
makes <something> local, whatever syntax it has (for example, Tramp file
name syntax).
"/method:user@host:/:<something>" makes <something> "local" on
"/method:user@host:" whatever syntax it has.
=2D-8<---------------cut here---------------start------------->8---
(expand-file-name "/:/ssh::.emacs") =3D> "/:/ssh::.emacs"
(file-truename "/:/ssh::.emacs") =3D> "/:/ssh::.emacs"
(file-remote-p "/:/ssh::.emacs") =3D> nil
(file-local-name "/:/ssh::.emacs") =3D> "/:/ssh::.emacs"
(expand-file-name "/ssh::/:.emacs") =3D> "/ssh:gandalf:/:.emacs"
(file-truename "/ssh::/:.emacs") =3D> "/ssh:gandalf:/:/home/albinus/.emacs=
"
(file-remote-p "/ssh::/:.emacs") =3D> "/ssh:gandalf:"
(file-local-name "/ssh::/:.emacs") =3D> "/:.emacs"
=2D-8<---------------cut here---------------end--------------->8---
Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 8 May 2024 16:14:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 08 12:14:33 2024 Received: from localhost ([127.0.0.1]:49624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4jw8-0005Z3-RH for submit <at> debbugs.gnu.org; Wed, 08 May 2024 12:14:33 -0400 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:58669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jporterbugs@HIDDEN>) id 1s4jw6-0005Yv-Lr for 70792 <at> debbugs.gnu.org; Wed, 08 May 2024 12:14:31 -0400 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1eb24e3a2d9so42829605ad.1 for <70792 <at> debbugs.gnu.org>; Wed, 08 May 2024 09:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715184839; x=1715789639; 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=GuQZ2yn0abNcdEzgMS7E5GlcYw7U8aixSZxwXNKtN9g=; b=cKLBivDsPY5kXVxUd0X4NFVVIzAEUaYr/kyVWMlkTIWeE4TbtH6cBx35sS5ZTnR8I2 0oANH7uQT8kuUR4B6PftBMx4PGfec5ZlfFgrxitCRbezjIVgdYmv3h3j3DBcdsCH6MCj ZZ+LhcqWiKcDBvSmq2H/z8cz8AOnvGL5lDkRrG44U/vFZhaUrZ9SmATg7pOxJ8UjIFM8 ahVNjje53LG5Kg4mCW8pNUTOdWIwCYiqsH3nAZD46TIroxNEzZtrVpW8DENuRhMKRy9k dM+cPIk2bRyoMiTR9V30p7deF2u7rYeKp2bc2DyxKEL3o6M3U6BDtGoPPmX1cj9J9Vk6 T88w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715184839; x=1715789639; 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=GuQZ2yn0abNcdEzgMS7E5GlcYw7U8aixSZxwXNKtN9g=; b=Cy5c9hs+Wi8BtCsK329j2uOVLuqM7vUJUGNEH8xw0I7V9cM0RXKgaa6HFXTFtcWXpH wiFrU9geT4Bxor8UAUuHJTFADSEjGDI9iSs1CrNs1eqXvE9Nz+ecclPnJMrWhFax0qQV YxZ4hAiBgT2sOnsong+tBlMTViEf9n9XOcAM7YHTkYchUSUZB3RX9HEKpPc6cl3YJ7rO +Dqo9WivhpZlAH72FoZxO5ZSnnLIbISlwHyvJPuuW8cBs+RYnQdRe7rEYgQ6htmlxVOW PT+rM5c6iGdZVqRZ9zNQZuYC/Xl5mDGpBn9Hse8RBLWur48qbCIsX5OWI9kRpMNQek0m ZDLQ== X-Gm-Message-State: AOJu0YzYretp+5jQURXWcr56ctrrcSfYGhs0dOtUtT6uVK7OGT3Pc4de lZiLYaFJRkmDI1z7rdeel1OZRBqwxostu0C1b2sWwctwU4dVt+PN X-Google-Smtp-Source: AGHT+IGjUyZhKjGSpjFLqtsNKbd+wN965D4LvBIBK5Ebm997c4zaKOXPDGNmcDqTPtUxcPXhHilaBQ== X-Received: by 2002:a17:902:b085:b0:1e5:a025:12f9 with SMTP id d9443c01a7336-1eeb03a1fbfmr32028435ad.28.1715184839131; Wed, 08 May 2024 09:13:59 -0700 (PDT) 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 d13-20020a170903230d00b001e43df03096sm12059755plh.30.2024.05.08.09.13.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 May 2024 09:13:58 -0700 (PDT) Message-ID: <b7c6a012-cdb0-5f1e-59fc-42dc7470a8dc@HIDDEN> Date: Wed, 8 May 2024 09:13:59 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> <865xvpbzvq.fsf@HIDDEN> <920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN> <86a5l0a195.fsf@HIDDEN> From: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <86a5l0a195.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 5/8/2024 6:20 AM, Eli Zaretskii wrote: > I think "/:" quoting should not change the host of the file name. > That's because the user might need this quoting for file names on the > remote host. Not to say we *should* do this, but if we kept the "/:" syntax of my patch, a user could still /:-quote a remote file name in Eshell by using the fully-qualified name like: "/ssh:user@remote:/:/blah". I can construct an argument for why using /: this way in Eshell would make sense, but maybe it's just needlessly "clever"... (As a note, Eshell already uses /:-quoting to mean "on the local host" in one spot: for the command to run. However, I added that for Emacs 30, so we can still change it without worrying about compatibility issues. See the manual here for more info: <https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.) > If the user wants to specify a local file name while default-directory > is remote, the user can use the normal Tramp "/METHOD:..." notation. How about a new "local" method? Then users would type "/local::~/some-file.txt". That's more typing, but it's also more clear, and doesn't repurpose an existing syntax used elsewhere in Emacs. I don't think the extra typing is *too* bad, since cross-host file names are probably a lot rarer than regular intra-host ones. Most likely, users will use cross-host file names primarily when cd'ing to a different host. If I go this route, I'm not sure whether it would be better to make "local" a real file name handler available everywhere in Emacs despite only being useful for Eshell, or if Eshell should just strip out the "/local::" prefix before sending it to other parts of Emacs. I'm leaning towards the former though, since the latter seems like a hack that could have unforeseen consequences.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 8 May 2024 13:21:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 08 09:21:35 2024 Received: from localhost ([127.0.0.1]:48889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4hEk-0006FQ-Vd for submit <at> debbugs.gnu.org; Wed, 08 May 2024 09:21:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s4hEj-0006F5-7L for 70792 <at> debbugs.gnu.org; Wed, 08 May 2024 09:21:33 -0400 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 <eliz@HIDDEN>) id 1s4hED-0003AI-UP; Wed, 08 May 2024 09:21:01 -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=zu6eBMF/CR2lQzlDxHhytsfc93ckyKLVNkojUt1EsAI=; b=rHpfSZcARRib Ft92Vz1k7dn6sDvaeqkB2IcP+NJ4hDOSGGrGtDbIux5Pp9SJXALvea4OMgRV6cyowRge5vR+dhojB /w+mLQkwstXUaVlFPMKJenvWd+7YZqCahYwlh4tvJFavHFtLFXYvuiPAhPPKgRyHyVZfghLU4lTpC NWC5BhDdTy9NVkikJXR8DLwKkw5r3Akx7r2hX+aIDREP/omcRHJpsE7QQOa0KbKgELolQ0I+HPykN I28STaSebuG1DcKH27mEYSj2fWuVfOaSe6VlGhusw1XVuglF1y/FTpum0Ex5sSFLRpy0BWsEVha2D StTdeOX9PAAXW0kf3YO9RA==; Date: Wed, 08 May 2024 16:20:38 +0300 Message-Id: <86a5l0a195.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN> (message from Jim Porter on Tue, 7 May 2024 11:54:26 -0700) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> <865xvpbzvq.fsf@HIDDEN> <920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 7 May 2024 11:54:26 -0700 > Cc: 70792 <at> debbugs.gnu.org > From: Jim Porter <jporterbugs@HIDDEN> > > There's just one open question with this: if I'm on a remote system, how > do I type the fully-qualified *local* file name? I propose using "/:" as > the prefix to mean "always look on the local host", so "/:/etc/foo.log" > is a local file name no matter what. For this case, I'm open to other > spellings, so long as we have *some* way to fully-qualify a local file name. I think "/:" quoting should not change the host of the file name. That's because the user might need this quoting for file names on the remote host. If the user wants to specify a local file name while default-directory is remote, the user can use the normal Tramp "/METHOD:..." notation.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.
Received: (at 70792) by debbugs.gnu.org; 7 May 2024 18:55:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 07 14:55:36 2024
Received: from localhost ([127.0.0.1]:44132 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s4PyR-0007tm-HB
for submit <at> debbugs.gnu.org; Tue, 07 May 2024 14:55:36 -0400
Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:43231)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <jporterbugs@HIDDEN>) id 1s4PyN-0007ta-R3
for 70792 <at> debbugs.gnu.org; Tue, 07 May 2024 14:55:34 -0400
Received: by mail-pf1-x430.google.com with SMTP id
d2e1a72fcca58-6f457853950so53429b3a.0
for <70792 <at> debbugs.gnu.org>; Tue, 07 May 2024 11:55:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1715108101; x=1715712901; 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=lT0IyE2C1POTOOVsueal8LX7+Z/slUwS49zZd4xesrU=;
b=NpKeMKgz7nvjVFJMKuCjpvGyUyfwzqzjENuvjzpOUe3y+CTq8hnOFGTaonq7CKuWX8
P/2aOHEz9PvhE1CcHNVa+XTrvF8qZWKy4gx69deTVV+CoPK1/QUdunNe2K8+irInBJ9w
GhvhNE5egN7cR9nRcU1S698EDjiiCLTakUDRx+yScyJVj8Lr4KIWhxhoXl8QCs4j/Gg9
GfLgnDQpQD4BfSMaceNzkdMz4WRpl6o1RrcJS51xS4uqZ1853OGx8wwryS4dgKmmjGNP
45KkT1viketgaVtbZnqRJlToF+3m8kstWVg/yz4BOeCMUZ0MGYKCXYeLfqzlI2Von5es
M7Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1715108101; x=1715712901;
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=lT0IyE2C1POTOOVsueal8LX7+Z/slUwS49zZd4xesrU=;
b=Fh5oMt8cqx7ag60VJ2VKdwNEEiD2ohdwpW7f2QcYLmVbCOlVbt/Fgj7VYna9JD1iLi
Q3rZeqMRqbWkAdHGRELIycfFp+s1o1NZkUTUeYicecNeYy/FUqIn2h6MW9kiLgzJMWzP
mqUjw4wFwtHmkRAxj+mHuQPUYN3gX4TANwvV2HuvHiMQGOoaOyN1u4PzfdbRavEK/2Yp
o8hPObFrtIrF7kqTJ31DN4mTqH3buERNvpmMOL3V5X7HgIhaGZHeaxg4UoY9pAybbHyI
ERgCtICavQZSZNRKwxxWXU8rQENqY+jqgf/V6Ru62Z2ahyE0Noran01l/tTCl+QhOdVA
t5Dw==
X-Gm-Message-State: AOJu0YxBuXB34En7rFibb2ucsb197eghJlw38bgQYlv1i70wkDZkv0Ag
rQmDLe04XF4iS093kDDvqvEQeqBLUB9ZDW/ASzS8nyVeUkemM0tn
X-Google-Smtp-Source: AGHT+IFTDmCbkDq5tfBsp1TDDDU5Nk1wy0pa3XuunDZ6pgu2qaOPYqngU42TWr5btfAyWYvtNg0/1g==
X-Received: by 2002:a05:6a20:d805:b0:1a7:590e:279e with SMTP id
adf61e73a8af0-1afc8727013mr942727637.5.1715108100666;
Tue, 07 May 2024 11:55:00 -0700 (PDT)
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
c11-20020aa7880b000000b006ecf3e302ffsm10074396pfo.174.2024.05.07.11.54.27
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 07 May 2024 11:54:44 -0700 (PDT)
Message-ID: <920fab98-d9e8-b4cd-c9bd-8bec428813eb@HIDDEN>
Date: Tue, 7 May 2024 11:54:26 -0700
MIME-Version: 1.0
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
absolute file names within the current remote connection
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>
References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN>
<86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN>
<86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN>
<865xvpbzvq.fsf@HIDDEN>
From: Jim Porter <jporterbugs@HIDDEN>
In-Reply-To: <865xvpbzvq.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 70792
Cc: 70792 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
(Replying a bit out of order to make the structure of my responses clearer.)
On 5/7/2024 4:55 AM, Eli Zaretskii wrote:
>> 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.
I think we must be close to seeing things the same way, since your
explanation is almost exactly how I proposed to fix this initially. In
retrospect, I should probably have spent a bit more space introducing
the issue and explaining why I did what I did; most of my initial
explanation was simply on *how* the patch works.
So I'll try to provide a summary of this problem from a user POV to make
sure we're on the same page:
----- SUMMARY -----
Currently, Eshell has a problem: when connected to a remote host (i.e.
cd'ed into a remote dir), sometimes an absolute file name like
"/foo/bar" means "a file on the current host", and sometimes it means "a
file on the *local* host". This new option lets you change that so an
absolute file name *always* means "a file on the current host"; this
matches the behavior of normal shells. If you want to refer to a file on
a different host, you instead type the fully-qualified remote file name
("/ssh:remote:/foo/bar"); this always means "/foo/bar on remote".
----- END SUMMARY -----
There's just one open question with this: if I'm on a remote system, how
do I type the fully-qualified *local* file name? I propose using "/:" as
the prefix to mean "always look on the local host", so "/:/etc/foo.log"
is a local file name no matter what. For this case, I'm open to other
spellings, so long as we have *some* way to fully-qualify a local file name.
>> 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.
Based on your longer explanation above, I think we agree entirely here.
>>> 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.
That's fine by me; I could remove options 2-4 from this list (so that
they mean "/etc on the current host"). I had chosen this set of options
to match the escaping logic for "~" in Eshell. However, I think I agree
that that's too invasive: a user might want to write a file name with
spaces "/something/like this.txt", and would be surprised if that
escaped to a local filename.
>>>> ##### 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_!
Note that these extra characters *only* come up if you're connected to a
remote host and need to explicitly refer to a file on your local system.
With this new option enabled, the "normal" spelling of "~/blah" would be
on the current host, just like normal shells. The "/:" is there to
explicitly override that behavior by fully-qualifying the name. (This
makes the common case - everything on the same host - easier to type.
You just type the normal, unqualified name.)
>> 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.
Agreed. With this option, an unqualified file name will refer to the
"state" (current remote host) to resolve the name.
>> 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.
Eshell already has a lot of logic for determining whether to run a Lisp
implementation of a command or an external program, so I don't think we
can change that without breaking many things. However, once Eshell has
determined the variety of the command, it can provide file names in the
correct syntax for that variety. (In other words, Lisp code will see the
fully-qualified file name[1], and external commands will see the
unqualified file name.)
[1] It might be wise to let Lisp-based commands request unqualified file
names too; Eshell already does similar things for determining when to
turn a string like "123" into a Lisp number.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 7 May 2024 11:55:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 07 07:55:46 2024 Received: from localhost ([127.0.0.1]:42572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4JQ9-0003Rt-Ns for submit <at> debbugs.gnu.org; Tue, 07 May 2024 07:55:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s4JQ4-0003Rg-98 for 70792 <at> debbugs.gnu.org; Tue, 07 May 2024 07:55:44 -0400 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 <eliz@HIDDEN>) 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==; Date: Tue, 07 May 2024 14:55:05 +0300 Message-Id: <865xvpbzvq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> (message from Jim Porter on Mon, 6 May 2024 13:05:28 -0700) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 6 May 2024 13:05:28 -0700 > Cc: 70792 <at> debbugs.gnu.org > From: Jim Porter <jporterbugs@HIDDEN> > > 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.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 7 May 2024 08:51:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 07 04:51:31 2024 Received: from localhost ([127.0.0.1]:42443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4GXq-0006mF-OD for submit <at> debbugs.gnu.org; Tue, 07 May 2024 04:51:31 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:45556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1s4GXn-0006lt-1L for 70792 <at> 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 <at> debbugs.gnu.org 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) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id E4B09940403; Tue, 7 May 2024 09:50:51 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection In-Reply-To: <fb5d7849-9aa4-665d-a34e-4d60243f78b5@HIDDEN> (Jim Porter's message of "Mon, 6 May 2024 11:28:54 -0700") References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <87y18mdglp.fsf@HIDDEN> <fb5d7849-9aa4-665d-a34e-4d60243f78b5@HIDDEN> Date: Tue, 07 May 2024 09:50:51 +0100 Message-ID: <87pltyatuc.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.
Received: (at 70792) by debbugs.gnu.org; 7 May 2024 08:13:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 07 04:13:30 2024
Received: from localhost ([127.0.0.1]:42408 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s4Fx4-0006P3-9h
for submit <at> debbugs.gnu.org; Tue, 07 May 2024 04:13:30 -0400
Received: from mout.gmx.net ([212.227.17.21]:35025)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <michael.albinus@HIDDEN>) id 1s4Fwy-0006Ow-Mv
for 70792 <at> debbugs.gnu.org; Tue, 07 May 2024 04:13:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1715069573; x=1715674373; i=michael.albinus@HIDDEN;
bh=B4PnC/BeQVUXRLtvPfETyebWCMUeD6wlNSgKMpwaScc=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=WutmFWzjDaJw+D5Uk7QX6epBL/bEAHO4y42tNdHxj1qEC5Mg8WQ6KBCseLWJedKk
rbqzT2o3bNdicw1J6e7xMBHJeGw+O2AqeuN3Cx3tN09mzJvWz9+CvPfvm8liL+nRf
hWwMreVsCCeaIj6UoMgGszhh8ecsBT1sAxjIpXLHEFg8Y1b1IrSUmrrv02mJJHqpG
VKX2LLGa08MziBQ/WrgxjQbpu3DZfTGPmNgedkeOky7DYY03ZA7Sy1FpHzCS00w7o
1A1Bi1tR49BxEmmViYc96wtpOXXUxmD8ZXNV1trFn4roH/D1XwHtv0cA+CNMR+DUq
4UvT/41fntrD4GsUnQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from gandalf.gmx.de ([185.89.39.16]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MIdeX-1rrs1I0SW5-00EcNm; Tue, 07
May 2024 10:12:53 +0200
From: Michael Albinus <michael.albinus@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding
absolute file names within the current remote connection
In-Reply-To: <86cypybx3f.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 06 May
2024 21:43:00 +0300")
References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN>
<86y18nb3ap.fsf@HIDDEN>
<fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN>
<86cypybx3f.fsf@HIDDEN>
Date: Tue, 07 May 2024 10:12:52 +0200
Message-ID: <878r0m59bv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:hcrdcpXxEYRuLhWqwiS830Gsq5wjjzckpPZsCbqEL0lxIzfaqXo
nMsNf7p0jy9GdD49XKUrjWXLBIWcIkYJnQarcalmEb4bbiXRbJ+kMMrGiOxDLrxjL6RTUNW
8qYXLTk5WJqHS3XTO2TkpQ9VE8Oxiv9ZVQN5OETwOi/DLX8NhlxPZVIf7kyx8TuZYHFcIw2
hax2WjwOwUInspVXq7+wg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:tejh24/P8t0=;Iddw+POUKkHxcKdZhu1MMgTZGBs
Ah9YLEr4yO/D5Etr/sPdn91P6M0oucXPmx6bl7rCl7a0oCxes8DHcfIxV3RO5H3Mvn1qEeVeo
o+s/V7YCeGrgxfiYqox+k+svWvpeYROjJJtfuFD01wq+LVPiaS2zRblTrwWQ1cG7rYQujnORH
PnCu66PGq9i5r/lRXC6wB7S9oZLZ4U7lyACCNB6Yi5jDuWFnmZt2c4870MbLAdTKnaKX171j6
WZ6YNpFxFCGd0vtn27/s9fkxaCF/S0AT4sEdWpKAOC6TnOSEOue+Lx3KLNhdyFpd7J4GiOLfD
8eIq/ReIB8offZULF07dcXLpSsx5Xf0YoWABcZbqC2ims5R8RI2jl33EIpyGM3c7KaJH3VKeu
ZjnolEfsxC6E9Q97wVogG337iZU/SP7g2BrrKW5ML9NN9ovyvatW6vkrcbKvEXmO44Tu9TasB
LWK94DoBgUR1v9LuIBo4nIw+DAEqyZ0NmG4smMX4qcDPCRIsQj/kR0ZiV0fpQjefyDnml3Ynf
ZuRGBe7M1TyyVkYE3zM3zjy55OMselbWqvGVrhqgx7FNDBTHENwU730R8+kRWBn2KBgfdQqM3
WUZfqXnh82SiBvVXyE3Qcb7Z82XuRQsMJF4X07LFVlF54XXBWED1PuUFUF3QJPkjTwORfN1Pk
UcA8DIBLLAj0IgceNkEz+uYzrosixtScbmxGXP4sJNsR/YLa619/CZGL8or9VfwNSaVxjUh80
n84l7ceZoIV3ugLF3fQfDYieY/2vRT7CvbuvxNZ+nsAeiqWksWLplv1oqeKkCWpDZ0fO/Drou
jAuvZC426E3GIc5y5y8g2x8rdz/z7Fww+6QyVugKLbisfS9iFeoQcuPB6deKCALOGH
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi, > 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 [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.39.16 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.21 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70792
Cc: Jim Porter <jporterbugs@HIDDEN>, 70792 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi, > 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 [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.21 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.39.16 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Eli Zaretskii <eliz@HIDDEN> writes:
Hi,
> 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.
>
> Bottom line: instead of trying to improve our guesswork, I suggest to
> explore the possibility of adding new command(s) that will tell Eshell
> exactly what the user means wrt local/remote operation.
Perhaps we start with a first step to make it visible, what a file name
is intended to be. We could use different faces for local and remote
file names in a command line of Eshell which hasn't been sent yet, as
Eshell would treat them.
Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 7 May 2024 02:01:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 22:01:46 2024 Received: from localhost ([127.0.0.1]:41430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4A9J-00029l-M9 for submit <at> debbugs.gnu.org; Mon, 06 May 2024 22:01:46 -0400 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]:43451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jporterbugs@HIDDEN>) id 1s4A9G-00029f-GC for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 22:01:44 -0400 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-61f2dc31be4so2163085a12.1 for <70792 <at> debbugs.gnu.org>; Mon, 06 May 2024 19:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715047272; x=1715652072; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=1OcAgq5NEYUkGNF8Cg5P56mydM9X/DL2yEyN2buPpuk=; b=nqs9Q/WClXaEo6CD3B7jcEtTec4mdTlQUzTPfom/V0G5yzkOiU3AFa6ISfHXT4v0CE iRNBElDrbXyTdYbyswerh4Z6ZuvC+NDIwy5mfEDrywGbZxUI5z2drhfdDGA7Du3TCHWv qgN96leVWGgx+vJuAiusPPLT7ZJUzQRqD1Az/KZz5HzJck2mFoMATjWfLQuTcqWnOOsO eLxg/VuDFlZQGVt+G4mqcSidrVhz1FaE1dyTxuvLJl/JNtXXZ7x65r0D33DRhodvo9hQ s/qR4ho2kyj3dPeeNwPI3R8T3Ex3hx2jN+5JtCzb/r2M3Q47GJFoIuVVkI58fbyt34SP z0Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715047272; x=1715652072; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1OcAgq5NEYUkGNF8Cg5P56mydM9X/DL2yEyN2buPpuk=; b=ffvzQEf3sjEDxMWZ53LRo0V5AtCb9zySaTAjrBZEg1b//ZoFD1Jzgke/tiP12gnBM1 UaYGwL2ODqjZ1Y5/8bgJZwNTZkbT/jVIV87d7EiKlLWe6VnT8e58/cDTW8r4CkP0jbk9 jwRx+0C+sOdhlUML7OLEHshBCoyOdwIKM0VFZOfhXHj3EtJ7BVUxmjMb/5Wrpaash0EQ tJqdzhLckIkFMeGfGouEQPNKxicyLADWYe1oHGw+t6RVQ8y1phLVWkJ1sm2C9YKfpMLh AzE/0pxiOrCDP1ULTXqJfr+KDsgIJE1e7cBUZvn9+nALSIK8R8o1DNBY5EH3CUMS+JUC WZkw== X-Gm-Message-State: AOJu0YwCAnd9KHYUWHGqHhY3PlAj8Ht6bHtd5ou/IR4YDBxX4CfL9KPW kwKX9uJ2lPMgV0LX0bTDMueR3uReEM+6YXjAOmttpWqqV8ULzcuA X-Google-Smtp-Source: AGHT+IESm/svomjnkAjIMRDiguXKyyMFL8Jf3Aq9iKIrtyLGFZmd+4aapd3/ehfsbWXO3BfTToze9Q== X-Received: by 2002:a17:90a:ab83:b0:2b1:54e4:e125 with SMTP id n3-20020a17090aab8300b002b154e4e125mr1867064pjq.22.1715047271782; Mon, 06 May 2024 19:01:11 -0700 (PDT) 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 fv2-20020a17090b0e8200b002b30ed21a96sm8717451pjb.11.2024.05.06.19.01.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 19:01:11 -0700 (PDT) Message-ID: <76d00fef-6902-6cd7-adc7-4f40308ed865@HIDDEN> Date: Mon, 6 May 2024 19:01:11 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Content-Language: en-US From: Jim Porter <jporterbugs@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> In-Reply-To: <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 5/6/2024 1:05 PM, Jim Porter wrote: > 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. One final point I'd like to make here is that this new (opt-in) behavior to treat "absolute" file names relative to the current remote connection already has precedent in Eshell. It's how Eshell looks for *commands* (as far as I know, it's always been this way). That means that "/bin/whoami" is the local whoami if the cwd is local, but it's the remote whoami is the cwd is remote: ~ $ /bin/whoami jim ~ $ cd /sudo:: /sudo:root@host:~ # /bin/whoami root By enabling this new option, Eshell will treat arguments much the same as it treats command names. (Of course, I'm happy to explain any part of this in more detail, and to add more documentation to the manual for whatever outcome we can agree to. The behavior around Tramp + Eshell in general is non-obvious, hence my hesitance to submit this patch without thinking it over for a *long* time. As the diff says, I finished the initial version of this last September and have spent much of the intervening time considering whether this behavior makes sense and how/if it could go wrong.)
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 20:06:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 16:06:17 2024 Received: from localhost ([127.0.0.1]:39994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s44bI-0006kv-5C for submit <at> debbugs.gnu.org; Mon, 06 May 2024 16:06:17 -0400 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 <jporterbugs@HIDDEN>) id 1s44b2-0006kS-Mx for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 16:06:15 -0400 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1eb24e3a2d9so22813535ad.1 for <70792 <at> 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) 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) Message-ID: <320dbb86-07b5-03ce-3ef0-a25d7978c214@HIDDEN> Date: Mon, 6 May 2024 13:05:28 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> <86cypybx3f.fsf@HIDDEN> From: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <86cypybx3f.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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."
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:43:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 14:43:49 2024 Received: from localhost ([127.0.0.1]:39594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s43JU-0005gs-Un for submit <at> debbugs.gnu.org; Mon, 06 May 2024 14:43:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s43JG-0005gY-Q0 for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 14:43:47 -0400 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 <eliz@HIDDEN>) id 1s43In-0003eV-3n; Mon, 06 May 2024 14:43:05 -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=+ZUcysqxL6FD9h1hGQ6vQz1wMSqaTfA9RaJtVdPziug=; b=ne2P7RLE3a/Q WnBImOes9StDNqir5qTkc9EkmrW1AzHk096xjCAeA9cWQx0mFi0KFG6f8mHHAUKnGXI6ifhVRD7KU Unqe+ql/XYpKhNymYsfLgC4QTO3kn2xEnNcIAPFaEbsKiMXcHkSKrXGcRf0oll0lhyYLHTz70lC4l 0yYKkhI0GWXQR56FQoMe4k2YjR9bPpjgPXHDcDZLBqkclAG0Gy0pFlybgbJHOIj1q731dsZBejRB0 XNF/3jHsAFwvF+2Fa5ZaCQ6Lag2zYJw8/JpnZBG2knYgk+yPxQv1P0+iqi261M9DBv9MG2QcJlFpD jStBBC/4cFYE3S+Z1y1SNw==; Date: Mon, 06 May 2024 21:43:00 +0300 Message-Id: <86cypybx3f.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> (message from Jim Porter on Mon, 6 May 2024 11:13:20 -0700) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 6 May 2024 11:13:20 -0700 > Cc: 70792 <at> debbugs.gnu.org > From: Jim Porter <jporterbugs@HIDDEN> > > File names are expanded according to the current working directory when > you enter your command, so unless you explicitly type out the host in a > file name, it's treated as belonging to the host associated with cwd. 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. > ##### 1. Change to root > ~ $ cd /sudo:: > /sudo:root@host:~ # pwd; *pwd > /sudo:root@host:/root > /root > > ##### 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? > ##### 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? > ##### 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! 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? > ##### 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.) > 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?? > 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. > 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. Bottom line: instead of trying to improve our guesswork, I suggest to explore the possibility of adding new command(s) that will tell Eshell exactly what the user means wrt local/remote operation.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:37:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 14:37:40 2024 Received: from localhost ([127.0.0.1]:39555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s43DY-0005aX-GL for submit <at> debbugs.gnu.org; Mon, 06 May 2024 14:37:40 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:60859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jporterbugs@HIDDEN>) id 1s43DW-0005aM-BP for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 14:37:39 -0400 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6f447976de7so1636482b3a.1 for <70792 <at> debbugs.gnu.org>; Mon, 06 May 2024 11:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715020628; x=1715625428; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=QoNiiwxuHGCAMJcsI2dfsMRLeHIoP3nlx+oWF8oL/Fs=; b=TFt9aAGMhLXwdKWbSfxGvQHpitaml6AxBSGRmmuLNMlTi2HsmEGKSyYIHLe3exiLiu C9IzlyMpRufmLSoUOw+lcRk3pruCF4j+zoRxSwMrOVVH0WgAvmMXSy457Ku7z+a4QVom 90If1ELtEthx28vZ/Q8ut5Gd8BZGydw9C4VB4QdnfXKx2HysorxWszyf7eShDp4zcKGg BMPdTkG+ypbzkWoLJk/nUGq8xqAI2AcusPyHqrnv2AlBtTKlLojTMHdmy0MnS1e5vrjJ uVD1i0A87TxQCFoeuqD9HkTLP6uMlWv1BvY6qZe7IkwmTw75zDPQbRtGXSFX6TZ1Hc3r Bp+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715020628; x=1715625428; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QoNiiwxuHGCAMJcsI2dfsMRLeHIoP3nlx+oWF8oL/Fs=; b=njElHKfpRGWX19p3RGfZ03+HdvpV/KyVHMMN/KBDVjsvMFKTvRRCqYw88RK5gJgI3f QVKP6bZvBKLViu5SMg8zspVqzOgxOZ7A5KS7J4whub/EVu1EA+mWRygpmSfOnR9DClqN 9IyPMF7o76Dz1cTgwltWmDuaJhmvo1ZWEDvuLTfgLQnLBiPvpKfoSPVgFtk89eV4saNP WVv95zieuID5R7aCNDar9IuA05R9TTMts4bWLtD+xl+/lBj0rfcxhQljIH5sD8UFrdlJ QCeQGrtC05US+hu6Hw1thQIcJuM5LL1uUNSjKj6fdeOwZV100LDFHmuDM0b2IcGi/G2X vC4g== X-Gm-Message-State: AOJu0YzfI46cmFQFhPUaLX0GDrTae557w6GpXVo5kE2pg2G5dkDf5u1w SQW47g4gjJ5yGcAGF1ky0jwDmGJ0LUrrRI7OQKM6bwozZIAN5wtV X-Google-Smtp-Source: AGHT+IGxscmh61D4CLHE5esEtd+SLin6XBKXKNLdzVaPaczJmOgp3VMgVsibHvgrhAjVp9o3UikMQA== X-Received: by 2002:a05:6a00:a23:b0:6ed:41f3:431d with SMTP id p35-20020a056a000a2300b006ed41f3431dmr11918954pfh.0.1715020627782; Mon, 06 May 2024 11:37:07 -0700 (PDT) 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 g6-20020aa79f06000000b006edca18c194sm3262584pfr.22.2024.05.06.11.37.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 11:37:07 -0700 (PDT) Message-ID: <3940954c-a0e7-e10c-2291-9c9392dda37f@HIDDEN> Date: Mon, 6 May 2024 11:37:06 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Content-Language: en-US From: Jim Porter <jporterbugs@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <87y18mdglp.fsf@HIDDEN> <fb5d7849-9aa4-665d-a34e-4d60243f78b5@HIDDEN> In-Reply-To: <fb5d7849-9aa4-665d-a34e-4d60243f78b5@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 5/6/2024 11:28 AM, Jim Porter wrote: > 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... By "work" here, I mean, "cp will copy the file, but to a place you likely didn't intend."
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:29:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 14:29:30 2024 Received: from localhost ([127.0.0.1]:39510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s435d-0005Ss-Kx for submit <at> debbugs.gnu.org; Mon, 06 May 2024 14:29:29 -0400 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 <jporterbugs@HIDDEN>) id 1s435a-0005Sm-L9 for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 14:29:27 -0400 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1ed835f3c3cso21563815ad.3 for <70792 <at> 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) 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) Message-ID: <fb5d7849-9aa4-665d-a34e-4d60243f78b5@HIDDEN> Date: Mon, 6 May 2024 11:28:54 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Content-Language: en-US To: Sean Whitton <spwhitton@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <87y18mdglp.fsf@HIDDEN> From: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <87y18mdglp.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:14:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 14:14:06 2024 Received: from localhost ([127.0.0.1]:39439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s42qc-0005I2-Ke for submit <at> debbugs.gnu.org; Mon, 06 May 2024 14:14:06 -0400 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:49508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jporterbugs@HIDDEN>) id 1s42qW-0005Hs-Tg for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 14:13:57 -0400 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1ed835f3c3cso21415175ad.3 for <70792 <at> debbugs.gnu.org>; Mon, 06 May 2024 11:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715019202; x=1715624002; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=sgTa6TkieWS2H/W6lLEppxhisesg7MX3SlztfTuci80=; b=nBdm04kWpipQJC00xJhht/QyiqM0s0NLg+RDyLgnDd8c2EfeQjwAIIvlFkdwrq/bve nt8EDAdFXHHHVl2W27jvdkoyGcrJ5NtdSq1FPcH3qfIiQgiGjGH8tbDjEZ/v1eaqiYkZ Ue8aHmOiHpZihjIJnd23NRqWK6h8u16oS6DoUbyNyZ25f0HrB/7P+Hp1AMRd5aj8lYft cx2OcTkF43QSYOXZr5Bhgxr7LT0fdBhFJz64vS4OCmsI0g+5qa9tanWklHWM45kkXrEv qXiTJefzt/m02Luzf8fE71xLJnE/Xg+WwvcpIGiXdQbD9yx1gVhuRnzj8aOmFpH5zsxr +5SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715019202; x=1715624002; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sgTa6TkieWS2H/W6lLEppxhisesg7MX3SlztfTuci80=; b=HGeezSExs8ELLnsobF0CI+HN5ebPX/egzvIf/nf64OADdjyJDu4kJyFBkFInp2pses WO1sH/ji9sSy20uaAnQkM86pYRtPrS5H/0kH1tCJp3yEsv0kASIAzqk3LQL/8VMOv6C2 ntaw3t0J9sffGUTIkCu9Cidrh97+JV26dHPfz2aRXiWbsmzuBy9EXib4vVSG8Zp/z+hP JuKC/o5EtNzsMhnFUnPYRJdX1nMRTM73gJY/X1dxiXh481A3zV+YzAfCkvdOE8EAHbQc 6nfeKAtw7qqofywPghHJ3uYbLXFD9HUuHfaZFjXJTRPhITroRj7aP4rqvH+pRdop/Rye HKeQ== X-Gm-Message-State: AOJu0Ywh1rTmWymoWVdJXQ2nYfMksTplf7//H0ps3J6a8uxgsJkf8fgz H2wtUjC1KIJ5qbxhmackqwYk2fdyNe6O1tEu70gvNeoeWA5LpN8R X-Google-Smtp-Source: AGHT+IGxeRNw2qyVBxUOhvv2kI5xV7YcDBOZh514bPcbqwdyLPo6Pp1irXvq0bn1f75WBV0vh9PaZg== X-Received: by 2002:a17:902:f64f:b0:1e6:116b:b0d3 with SMTP id m15-20020a170902f64f00b001e6116bb0d3mr15181261plg.28.1715019202293; Mon, 06 May 2024 11:13:22 -0700 (PDT) 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 j9-20020a170902da8900b001e5331a0b91sm8566965plx.218.2024.05.06.11.13.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 11:13:21 -0700 (PDT) Message-ID: <fe51fb39-13c0-05a9-0204-daab292cf34f@HIDDEN> Date: Mon, 6 May 2024 11:13:20 -0700 MIME-Version: 1.0 Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection To: Eli Zaretskii <eliz@HIDDEN> References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <86y18nb3ap.fsf@HIDDEN> Content-Language: en-US From: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <86y18nb3ap.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 5/6/2024 4:14 AM, Eli Zaretskii wrote: > 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? Thanks for taking a look. I'll try to explain this in more detail, since it's a fairly subtle interaction, especially if you don't use Tramp + Eshell heavily. (With the benefit of hindsight, we might have chosen not to handle remote access in Eshell the way it does, but it's now one of the big features users mention when they describe what they like about it. This patch is my best attempt at smoothing some of the existing rough edges here so that remote access in Eshell doesn't feel so capricious.) Anyway... File names are expanded according to the current working directory when you enter your command, so unless you explicitly type out the host in a file name, it's treated as belonging to the host associated with cwd. (If it helps, this is sort of like how "~" is expanded in regular shells. The shell expands it early on when parsing your input, so "sudo echo ~" outputs *your* homedir, not root's.) Here are some examples with the new option enabled (note that "*" before a program name means "always execute the external program on the host"): ##### 1. Change to root ~ $ cd /sudo:: /sudo:root@host:~ # pwd; *pwd /sudo:root@host:/root /root ##### 2. Change to an absolute directory, stay as root /sudo:root@host:~ # cd /etc; pwd; *pwd /sudo:root@host:/etc /etc ##### 3. Change to the home directory, stay as root /sudo:root@host:~ # cd ~; pwd; *pwd /sudo:root@host:/root /root ##### 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 ##### 6. "bar.txt" ended up here ~ $ cat bar.txt ['-c', '/root/foo.txt'] In the last line above, note that the value we wrote to our file is just the local part. There's no Tramp remote host part here because Python (or other any other external program) wouldn't understand that syntax. Eshell strips off the remote part for you, unless you escape the argument, e.g. by surrounding it with quotes. (When doing this unexpanding, Eshell also makes sure that the remote host of the file name matches the host where the program will run.) > 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? 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: ##### 3b. Change to the home directory; stop being root(!) /sudo:root@host:~ # cd ~; pwd; *pwd /home/jim /home/jim 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.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 18:00:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 14:00:06 2024 Received: from localhost ([127.0.0.1]:39379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s42dB-00058b-RO for submit <at> debbugs.gnu.org; Mon, 06 May 2024 14:00:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s42d7-00057g-GU for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 14:00:05 -0400 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 <eliz@HIDDEN>) id 1s42cc-0000t6-HJ; Mon, 06 May 2024 13:59:30 -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=bP+8UodLfcL5F+1Trkf9LFL963t5Jyec16q55fIIZgI=; b=q5Wz9mXL6Qxb SkLyN9WjFrDR45wW3zmAKw2ULAdtuXvFQOOFaD0a75lVULA6EFZwVbMtICGObfqNoCGi8tKd6AG9n 0nOxp5eFAd4nZTLsJ4h0xvTa1FggXR6Y1wlY3HIwJ3FK6DRVaOam8+pfnJB9CgUrMesceRRXLEGcL 4ugy8Fyy7Tbu6xf0j98xsRDztEvTi/hYrqVdCuJ9oWMFRGFrOgbbPl7jVD5ZwBE2hukjQgZVzIKDj 2hZvMXYVC4+SNVvYDa3RBZUg/gP6Lxy4WPgEARyv2l3oVw1rExJC3z/vxe0x/ZuseDOQnZivv9PZ/ uihSihC1G4YyCy8YQUqJQg==; Date: Mon, 06 May 2024 20:59:22 +0300 Message-Id: <86h6fabz45.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Sean Whitton <spwhitton@HIDDEN> In-Reply-To: <87y18mdglp.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> <87y18mdglp.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70792 Cc: jporterbugs@HIDDEN, 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 70792 <at> debbugs.gnu.org > Date: Mon, 06 May 2024 17:56:18 +0100 > From: Sean Whitton via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > Isn't this by design? It lets you, e.g, transparently copy a file from > the local to the remote host just with 'cp'. Which 'cp'? the built-in one or the external one? And how do you tell which one will be invoked?
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 16:56:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 12:56:55 2024 Received: from localhost ([127.0.0.1]:39091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s41e3-0007Jy-Ie for submit <at> debbugs.gnu.org; Mon, 06 May 2024 12:56:55 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:57560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1s41dx-0007Js-Fp for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 12:56:53 -0400 DKIM-Signature: a=rsa-sha256; b=E6xvEH8dYCR0IS4He9f9nNGtb7YfZBJHIzGXF8fwAInR0MSU0fG8R8MpRef/7Q2Aq7RyZvrhQL5zNUuvxH8kWP4zAGLG02tvJEYCh5q5LsfaLRcWPEQ5wURFmTCOct8ve+TJI6tNf4Hfyr9LtJZhLpTb663/FAKRCDjRzVvGzBYxUmiC8pQ/duVn6ei9CSIof0L7fyNxRGYEJukZKtBJEwtrnWZ3SfR6KixWrtjMB89zMRmB3hh8CdmRXKzaG3JSgOjZ+GOLn3VNm+Wx4DmfKYQiRjmJ7e3pQLQva9+5jsdSlDKimvgHx0h0GpLkT55+ICfDbmQOubO9X1mto4YtZA==; s=purelymail2; d=spwhitton.name; v=1; bh=PVnJGiTdUEfmc5fV/c1h/kA1gBbXo32N31PiKUGShBc=; h=Received:Received:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=bn3gCS4uw7IwTRVj/7GMa2zyQlSGxz6ZFV2y3rQ5M1AdriA6UcQGk+78Fsyso+coT12EtEClVcgo977wynCC6YxA7taXfonhvSHtjb/h88xDSkcuo1wpCWA4+D26m8KzCyhBoIXta0auPBjHk9dfb01uNWFuVN0Sw8hEg9tTgjmwtBXqE8Eq7A1qspFZ3AjEUIe9qiRY9i8iaTCqr4sXUHSGuFHOinPNAs/GSwIy9A9IDZERjCsE0xDWfe4SaPtdnJ7qP3y4TEVFaXRmqPO7NRQcsE7GSzx80vquQ2VwCMPrgTfTexw6+qJH4/e0wrxpymngtJcxpH3TKCoXrlkT7g==; s=purelymail2; d=purelymail.com; v=1; bh=PVnJGiTdUEfmc5fV/c1h/kA1gBbXo32N31PiKUGShBc=; h=Feedback-ID:Received:Received:From:To:Subject; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 70792 <at> debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1854597812; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 06 May 2024 16:56:19 +0000 (UTC) Received: by zephyr.silentflame.com (Postfix, from userid 1000) id 20C14947D9B; Mon, 6 May 2024 17:56:18 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection In-Reply-To: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> (Jim Porter's message of "Sun, 5 May 2024 13:58:55 -0700") References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> Date: Mon, 06 May 2024 17:56:18 +0100 Message-ID: <87y18mdglp.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, On Sun 05 May 2024 at 01:58pm -07, Jim Porter wrote: > 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. Isn't this by design? It lets you, e.g, transparently copy a file from the local to the remote host just with 'cp'. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at 70792) by debbugs.gnu.org; 6 May 2024 11:15:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 06 07:15:07 2024 Received: from localhost ([127.0.0.1]:37366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s3wJG-0008LQ-Np for submit <at> debbugs.gnu.org; Mon, 06 May 2024 07:15:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s3wJB-0008Kg-9K for 70792 <at> debbugs.gnu.org; Mon, 06 May 2024 07:15:05 -0400 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 <eliz@HIDDEN>) id 1s3wIh-00019e-Kv; Mon, 06 May 2024 07:14:31 -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=BzaN+O/mt+Bvj7iWA8bnZND9Wxo7qr/0W1inOnL80KQ=; b=Cd6tzMTH/Ij6 AL652SC2CRp7lfSqWNP2cXDmM8gBTiEGdU7iE4MXajYB1xwWlR/RpWp2EqS9yXN/RvYlOnAWV8hOs RMQKRI38IYVY0H9tgj2VomsMyBNPC2kaQwBaJvG51mZkmbhTBveJ1a2KZJ52Cc5nsnwFyIb/dborR nZyvUnzksgqKcjB8vwfhgm5s82hI/KolUfhlLYmtxOf1MlUR4wooRdNE9WSMz8+w6CZyxReC0QuTT hi2+pStayw73LA6+/4RVN4cwCrQt2IWF5UXLxfvxXyiRR72UtHxfjln0V6BdzvPDbOeWEXUJtt+7o hALWLtAxWqhLNcHAmAVcpw==; Date: Mon, 06 May 2024 14:14:22 +0300 Message-Id: <86y18nb3ap.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jim Porter <jporterbugs@HIDDEN> In-Reply-To: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> (message from Jim Porter on Sun, 5 May 2024 13:58:55 -0700) Subject: Re: bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection References: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70792 Cc: 70792 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 5 May 2024 13:58:55 -0700 > From: Jim Porter <jporterbugs@HIDDEN> > > 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.
bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 May 2024 20:59:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 05 16:59:38 2024 Received: from localhost ([127.0.0.1]:33532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s3ixM-0007KO-Cx for submit <at> debbugs.gnu.org; Sun, 05 May 2024 16:59:37 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jporterbugs@HIDDEN>) id 1s3ixH-0007KB-VV for submit <at> debbugs.gnu.org; Sun, 05 May 2024 16:59:35 -0400 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 <jporterbugs@HIDDEN>) id 1s3iwo-0007vG-7H for bug-gnu-emacs@HIDDEN; Sun, 05 May 2024 16:59:02 -0400 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jporterbugs@HIDDEN>) id 1s3iwk-0003FQ-R4 for bug-gnu-emacs@HIDDEN; Sun, 05 May 2024 16:59:01 -0400 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-6001399f22bso1028714a12.0 for <bug-gnu-emacs@HIDDEN>; Sun, 05 May 2024 13:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714942737; x=1715547537; darn=gnu.org; h=subject:from:to:content-language:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=RDP0VimP84J9Xhu6ufjjEsbvB6CcQfOZ6RxjBladNfw=; b=KMeYifqkKq8jcL5djzzh7a9I/Fv/gMaIuYSFL3BH38hyRQFu4ZCsNGPctekEjcnkO8 FEB4vsl55Hg8OnRNOGSndPzlkMA/s5NR7CsstYHE0uu09L7uAR20Hac2sB6/SgI+7XKt bOq+ldny4woLa7NvkBw0AiMhAPfJ9qCBwm4pPNr8hs+6wGelirtSIOJvT3jvrwc2Ouyk dFdvgBGBhyc/5n2+juP5G6D/InA5UDMATh5qqxjZvYP3QeYOsF0KUOUA92q0PxJb4sJK MOyXo5UiL4rC7RxMw3uJsYmD39PCKe5ux8QdFgLzDRS7luXVptv+Q13nUXi6CkuZXnst y4Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714942737; x=1715547537; h=subject:from:to:content-language:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RDP0VimP84J9Xhu6ufjjEsbvB6CcQfOZ6RxjBladNfw=; b=rzkrCusjVH962teXODj+ir8oteMBHPHW5aTTXfQ3WBD6zR+XsTxZgP8A4VvQfjZ+yS f46ac8J4XO4SbnQjPnWW0qaBVs3dCqGbWdb35dNmJXzN2+ZRxpBnXGtFSh5rp8e6awBQ YgEtTe2VPYv2ZRZWwtGH8ofNVQ6+NiRQwde5Vgbv+5wLJKXZPFUVkVtQtYL7BmK3BaKq Pszea7u87rEp0Il2Z9njrPBoUnP/T8oeUojr+iXhhoqB7ZSNZCZk7K3hrrOtWIWxDwHX eQGS7jSBFVkHcxzb1oecxBipxmxVJkgTDtT8jUYegGKJCKzQgFZE9mNCI71XRpFt2aaZ Dk6A== X-Gm-Message-State: AOJu0YyylweUxsq//VvEBxfHGj1NDkweO/0gZRkCikSMGRkd2hVtRowm be+xW0DIJaTV6LbUHnrXO/LyxP/awCZH2SHM/VaOkGx8PevDfnenQ4fdaw== X-Google-Smtp-Source: AGHT+IGX5ZTiHhMKEAQWpmedCOCwoqoeXwMyeaTe6BaawYBUqD9vAimSqygGwxYClzNBxUV6oHRlrA== X-Received: by 2002:a17:902:d3d3:b0:1e5:5c49:ad4b with SMTP id w19-20020a170902d3d300b001e55c49ad4bmr8563171plb.38.1714942736721; Sun, 05 May 2024 13:58:56 -0700 (PDT) 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 ja18-20020a170902efd200b001e403970ec0sm6825133plb.277.2024.05.05.13.58.55 for <bug-gnu-emacs@HIDDEN> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 May 2024 13:58:56 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------vuDo0Zym7x6wfKUFkl9ikDoF" Message-ID: <5b881f54-4c29-f8d8-d1f7-57b44e7cfc80@HIDDEN> Date: Sun, 5 May 2024 13:58:55 -0700 MIME-Version: 1.0 X-Mozilla-News-Host: news://news.gmane.io:119 Content-Language: en-US To: bug-gnu-emacs@HIDDEN From: Jim Porter <jporterbugs@HIDDEN> Subject: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection Received-SPF: pass client-ip=2607:f8b0:4864:20::535; envelope-from=jporterbugs@HIDDEN; helo=mail-pg1-x535.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) This is a multi-part message in MIME format. --------------vuDo0Zym7x6wfKUFkl9ikDoF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 ~. --------------vuDo0Zym7x6wfKUFkl9ikDoF Content-Type: text/plain; charset=UTF-8; name="0001-Mark-all-backslash-escaped-characters-in-Eshell-as-e.patch" Content-Disposition: attachment; filename*0="0001-Mark-all-backslash-escaped-characters-in-Eshell-as-e.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSBkZDVhNDIzYzFkOWYyYzAzM2U0NGFiZTVkYWUzZjVhM2EzMTI4MDJiIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IFNhdCwgMiBTZXAgMjAyMyAyMjoyOToyMiAtMDcwMApTdWJqZWN0OiBbUEFU Q0ggMS8yXSBNYXJrIGFsbCBiYWNrc2xhc2gtZXNjYXBlZCBjaGFyYWN0ZXJzIGluIEVzaGVs bCBhcwogJ2VzY2FwZWQnCgoqIGxpc3AvZXNoZWxsL2VzaC1hcmcuZWwgKGVzaGVsbC1wYXJz ZS1iYWNrc2xhc2gpOiBNYXJrIGFsbApiYWNrc2xhc2gtZXNjYXBlZCBjaGFyYWN0ZXJzIHdp dGggdGhlICdlc2NhcGVkJyBwcm9wZXJ0eSwgZXZlbiBpZgp0aGV5J3JlIG5vbi1zcGVjaWFs LgoKKiB0ZXN0L2xpc3AvZXNoZWxsL2VzaC1hcmctdGVzdHMuZWwKKGVzaC1hcmctdGVzdC9l c2NhcGUvYmFja3NsYXNoLW5vbnNwZWNpYWwpCihlc2gtYXJnLXRlc3QvZXNjYXBlL2JhY2tz bGFzaC1ub25zcGVjaWFsLXVuaWNvZGUpCihlc2gtYXJnLXRlc3QvZXNjYXBlL2JhY2tzbGFz aC1zcGVjaWFsKQooZXNoLWFyZy10ZXN0L2VzY2FwZS9iYWNrc2xhc2gtbmV3bGluZSkKKGVz aC1hcmctdGVzdC9lc2NhcGUvYmFja3NsYXNoLW5ld2xpbmUtY29uZGl0aW9uYWwpCihlc2gt YXJnLXRlc3QvZXNjYXBlLXF1b3RlZC9iYWNrc2xhc2gtbm9uc3BlY2lhbCkKKGVzaC1hcmct dGVzdC9lc2NhcGUtcXVvdGVkL2JhY2tzbGFzaC1zcGVjaWFsKQooZXNoLWFyZy10ZXN0L2Vz Y2FwZS1xdW90ZWQvYmFja3NsYXNoLW5ld2xpbmUpOiBSZW5hbWUgdGVzdHMsIGFuZApjaGVj ayBzdHJpbmcgcHJvcGVydGllcy4KKGVzaC1hcmctdGVzdC9lc2NhcGUtcXVvdGVkL2Jhc2lj KQooZXNoLWFyZy10ZXN0L2VzY2FwZS1zaW5nbGUtcXVvdGVkL2Jhc2ljKQooZXNoLWFyZy10 ZXN0L2VzY2FwZS1zaW5nbGUtcXVvdGVkL3NpbmdsZS1xdW90ZSk6IE5ldyB0ZXN0cy4KLS0t CiBsaXNwL2VzaGVsbC9lc2gtYXJnLmVsICAgICAgICAgICAgfCAgIDcgKy0KIHRlc3QvbGlz cC9lc2hlbGwvZXNoLWFyZy10ZXN0cy5lbCB8IDEyNCArKysrKysrKysrKysrKysrKy0tLS0t LS0tLS0tLS0KIDIgZmlsZXMgY2hhbmdlZCwgNzQgaW5zZXJ0aW9ucygrKSwgNTcgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9lc2hlbGwvZXNoLWFyZy5lbCBiL2xpc3AvZXNo ZWxsL2VzaC1hcmcuZWwKaW5kZXggNzhjZjI4ZDc4NWEuLmI2MmYwODkzZTg5IDEwMDY0NAot LS0gYS9saXNwL2VzaGVsbC9lc2gtYXJnLmVsCisrKyBiL2xpc3AvZXNoZWxsL2VzaC1hcmcu ZWwKQEAgLTQ3NywxNSArNDc3LDE0IEBAIGVzaGVsbC1wYXJzZS1iYWNrc2xhc2gKICAgICAg ICA7OyBtdWx0aXBsZSBsaW5lcy4KICAgICAgICAoKGVxIChjaGFyLWJlZm9yZSkgP1xuKQog ICAgICAgICAnZXNoZWxsLWVtcHR5LXRva2VuKQotICAgICAgICgobWVtcSAoY2hhci1iZWZv cmUpIHNwZWNpYWwtY2hhcnMpCi0gICAgICAgIChsaXN0ICdlc2hlbGwtZXNjYXBlLWFyZyAo Y2hhci10by1zdHJpbmcgKGNoYXItYmVmb3JlKSkpKQogICAgICAgIDs7IElmIHRoZSBjaGFy IGlzIGluIGEgcXVvdGUsIGJhY2tzbGFzaCBvbmx5IGhhcyBzcGVjaWFsCiAgICAgICAgOzsg bWVhbmluZyBpZiBpdCBpcyBlc2NhcGluZyBhIHNwZWNpYWwgY2hhci4gIE90aGVyd2lzZSwg dGhlCiAgICAgICAgOzsgcmVzdWx0IGlzIHRoZSBsaXRlcmFsIHN0cmluZyAiXGMiLgotICAg ICAgIChlc2hlbGwtY3VycmVudC1xdW90ZWQKKyAgICAgICAoKGFuZCBlc2hlbGwtY3VycmVu dC1xdW90ZWQKKyAgICAgICAgICAgICAobm90IChtZW1xIChjaGFyLWJlZm9yZSkgc3BlY2lh bC1jaGFycykpKQogICAgICAgICAoY29uY2F0ICJcXCIgKGNoYXItdG8tc3RyaW5nIChjaGFy LWJlZm9yZSkpKSkKICAgICAgICAodAotICAgICAgICAoY2hhci10by1zdHJpbmcgKGNoYXIt YmVmb3JlKSkpKSkpKQorICAgICAgICAobGlzdCAnZXNoZWxsLWVzY2FwZS1hcmcgKGNoYXIt dG8tc3RyaW5nIChjaGFyLWJlZm9yZSkpKSkpKSkpCiAKIChkZWZ1biBlc2hlbGwtcGFyc2Ut bGl0ZXJhbC1xdW90ZSAoKQogICAiUGFyc2UgYSBsaXRlcmFsbHkgcXVvdGVkIHN0cmluZy4g IE5vdGhpbmcgaGFzIHNwZWNpYWwgbWVhbmluZyEiCmRpZmYgLS1naXQgYS90ZXN0L2xpc3Av ZXNoZWxsL2VzaC1hcmctdGVzdHMuZWwgYi90ZXN0L2xpc3AvZXNoZWxsL2VzaC1hcmctdGVz dHMuZWwKaW5kZXggYjc0OGM1YWI0YzAuLjhjMTM5Y2VlNTg5IDEwMDY0NAotLS0gYS90ZXN0 L2xpc3AvZXNoZWxsL2VzaC1hcmctdGVzdHMuZWwKKysrIGIvdGVzdC9saXNwL2VzaGVsbC9l c2gtYXJnLXRlc3RzLmVsCkBAIC0zNiw0MiArMzYsNDAgQEAgZXNoZWxsLXRlc3QtdmFsdWUK IAogOzs7IFRlc3RzOgogCi0oZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS9ub25z cGVjaWFsICgpCi0gICJUZXN0IHRoYXQgXCJcXGNcIiBhbmQgXCJjXCIgYXJlIGVxdWl2YWxl bnQgd2hlbiBcImNcIiBpcyBub3QgYQotc3BlY2lhbCBjaGFyYWN0ZXIuIgotICAod2l0aC10 ZW1wLWVzaGVsbAotICAgKGVzaGVsbC1tYXRjaC1jb21tYW5kLW91dHB1dCAiZWNobyBoZVxc bGxvIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaGVsbG9cbiIpKSkKLQot KGVydC1kZWZ0ZXN0IGVzaC1hcmctdGVzdC9lc2NhcGUvbm9uc3BlY2lhbC11bmljb2RlICgp Ci0gICJUZXN0IHRoYXQgXCJcXGNcIiBhbmQgXCJjXCIgYXJlIGVxdWl2YWxlbnQgd2hlbiBc ImNcIiBpcyBhCi11bmljb2RlIGNoYXJhY3RlciAodW5pY29kZSBjaGFyYWN0ZXJzIGFyZSBu b25zcGVjaWFsIGJ5Ci1kZWZpbml0aW9uKS4iCi0gICh3aXRoLXRlbXAtZXNoZWxsCi0gICAo ZXNoZWxsLW1hdGNoLWNvbW1hbmQtb3V0cHV0ICJlY2hvIFZpZFxcw6lvcyIKLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIlZpZMOpb3NcbiIpKSkKLQotKGVydC1kZWZ0ZXN0 IGVzaC1hcmctdGVzdC9lc2NhcGUvc3BlY2lhbCAoKQotICAiVGVzdCB0aGF0IHRoZSBiYWNr c2xhc2ggaXMgbm90IHByZXNlcnZlZCBmb3IgZXNjYXBlZCBzcGVjaWFsCi1jaGFycy4iCi0g ICh3aXRoLXRlbXAtZXNoZWxsCi0gICAoZXNoZWxsLW1hdGNoLWNvbW1hbmQtb3V0cHV0ICJl Y2hvIGhlXFxcXGxsbyIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOzsgQmFj a3NsYXNoZXMgYXJlIGRvdWJsZWQgZm9yIHJlZ2V4cC4KLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgImhlXFxcXGxsb1xuIikpKQotCi0oZXJ0LWRlZnRlc3QgZXNoLWFyZy10 ZXN0L2VzY2FwZS9uZXdsaW5lICgpCi0gICJUZXN0IHRoYXQgYW4gZXNjYXBlZCBuZXdsaW5l IGlzIGVxdWl2YWxlbnQgdG8gdGhlIGVtcHR5IHN0cmluZy4iCi0gICh3aXRoLXRlbXAtZXNo ZWxsCi0gICAoZXNoZWxsLW1hdGNoLWNvbW1hbmQtb3V0cHV0ICJlY2hvIGhpXFxcbnRoZXJl IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaGl0aGVyZVxuIikpKQotCi0o ZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS90cmFpbGluZy1uZXdsaW5lICgpCi0g ICJUZXN0IHRoYXQgYW4gZXNjYXBlZCBuZXdsaW5lIGlzIGVxdWl2YWxlbnQgdG8gdGhlIGVt cHR5IHN0cmluZy4iCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS9iYWNrc2xh c2gtbm9uc3BlY2lhbCAoKQorICAiVGVzdCB0aGF0IFwiXFxjXCIgZXhwYW5kcyB0byBcImNc IiB3aGVuIFwiY1wiIGlzIG5vdCBhIHNwZWNpYWwgY2hhcmFjdGVyLgorSXQgc2hvdWxkIG1h cmsgXCJjXCIgYXMgYmVpbmcgZXNjYXBlZCwgdGhvdWdoLiIKKyAgKHNob3VsZCAoZXF1YWwt aW5jbHVkaW5nLXByb3BlcnRpZXMKKyAgICAgICAgICAgKGVzaGVsbC10ZXN0LWNvbW1hbmQt cmVzdWx0ICJlY2hvIGhlXFxsbG8iKQorICAgICAgICAgICAjKCJoZWxsbyIgMiAzIChlc2Nh cGVkIHQpKSkpKQorCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS9iYWNrc2xh c2gtbm9uc3BlY2lhbC11bmljb2RlICgpCisgICJUZXN0IHRoYXQgXCJcXGNcIiBleHBhbmRz IHRvIFwiY1wiIHdoZW4gXCJjXCIgaXMgYSBVbmljb2RlIGNoYXJhY3Rlci4KK1VuaWNvZGUg Y2hhcmFjdGVycyBhcmUgbm9uc3BlY2lhbCBieSBkZWZpbml0aW9uLiAgQXMgYWJvdmUsIHRo aXMKK3dvdWxkIG1hcmsgXCJjXCIgYXMgZXNjYXBlZC4iCisgIChzaG91bGQgKGVxdWFsLWlu Y2x1ZGluZy1wcm9wZXJ0aWVzCisgICAgICAgICAgIChlc2hlbGwtdGVzdC1jb21tYW5kLXJl c3VsdCAiZWNobyBWaWRcXMOpb3MiKQorICAgICAgICAgICAjKCJWaWTDqW9zIiAzIDQgKGVz Y2FwZWQgdCkpKSkpCisKKyhlcnQtZGVmdGVzdCBlc2gtYXJnLXRlc3QvZXNjYXBlL2JhY2tz bGFzaC1zcGVjaWFsICgpCisgICJUZXN0IHRoYXQgdGhlIGJhY2tzbGFzaCBpcyByZW1vdmVk IGZvciBlc2NhcGVkIHNwZWNpYWwgY2hhcmFjdGVycy4iCisgIChzaG91bGQgKGVxdWFsLWlu Y2x1ZGluZy1wcm9wZXJ0aWVzCisgICAgICAgICAgIChlc2hlbGwtdGVzdC1jb21tYW5kLXJl c3VsdCAiZWNobyBoZVxcXFxsbG8iKQorICAgICAgICAgICAjKCJoZVxcbGxvIiAyIDMgKGVz Y2FwZWQgdCkpKSkpCisKKyhlcnQtZGVmdGVzdCBlc2gtYXJnLXRlc3QvZXNjYXBlL2JhY2tz bGFzaC1uZXdsaW5lICgpCisgICJUZXN0IHRoYXQgYW4gZXNjYXBlZCBuZXdsaW5lIGV4cGFu ZHMgdG8gdGhlIGVtcHR5IHN0cmluZy4iCisgIChzaG91bGQgKGVxdWFsLWluY2x1ZGluZy1w cm9wZXJ0aWVzCisgICAgICAgICAgIChlc2hlbGwtdGVzdC1jb21tYW5kLXJlc3VsdCAiZWNo byBoaVxcXG50aGVyZSIpCisgICAgICAgICAgICJoaXRoZXJlIikpKQorCisoZXJ0LWRlZnRl c3QgZXNoLWFyZy10ZXN0L2VzY2FwZS90cmFpbGluZy1iYWNrc2xhc2gtbmV3bGluZSAoKQor ICAiVGVzdCB0aGF0IGFuIGVzY2FwZWQgbmV3bGluZSBleHBhbmRzIHRvIHRoZSBlbXB0eSBz dHJpbmcuIgogICAod2l0aC10ZW1wLWVzaGVsbAogICAgKGVzaGVsbC1tYXRjaC1jb21tYW5k LW91dHB1dCAiZWNobyBoaVxcXG4iCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICJoaVxuIikpKQogCi0oZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS9uZXdsaW5l LWNvbmRpdGlvbmFsICgpCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS9iYWNr c2xhc2gtbmV3bGluZS1jb25kaXRpb25hbCAoKQogICAiVGVzdCBpbnZvY2F0aW9uIG9mIGFu IGlmL2Vsc2Ugc3RhdGVtZW50IHVzaW5nIGxpbmUgY29udGludWF0aW9ucy4iCiAgIChsZXQg KChlc2hlbGwtdGVzdC12YWx1ZSB0KSkKICAgICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVx dWFsCkBAIC04MiwyNyArODAsNDcgQEAgZXNoLWFyZy10ZXN0L2VzY2FwZS9uZXdsaW5lLWNv bmRpdGlvbmFsCiAgICAgICJpZiAkZXNoZWxsLXRlc3QtdmFsdWUgXFxcbntlY2hvIHllc30g XFxcbntlY2hvIG5vfSIKICAgICAgIm5vIikpKQogCi0oZXJ0LWRlZnRlc3QgZXNoLWFyZy10 ZXN0L2VzY2FwZS1xdW90ZWQvbm9uc3BlY2lhbCAoKQotICAiVGVzdCB0aGF0IHRoZSBiYWNr c2xhc2ggaXMgcHJlc2VydmVkIGZvciBlc2NhcGVkIG5vbnNwZWNpYWwKLWNoYXJzLiIKLSAg KHdpdGgtdGVtcC1lc2hlbGwKLSAgIChlc2hlbGwtbWF0Y2gtY29tbWFuZC1vdXRwdXQgImVj aG8gXCJoXFxpXCIiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IEJhY2tz bGFzaGVzIGFyZSBkb3VibGVkIGZvciByZWdleHAuCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICJoXFxcXGlcbiIpKSkKLQotKGVydC1kZWZ0ZXN0IGVzaC1hcmctdGVzdC9l c2NhcGUtcXVvdGVkL3NwZWNpYWwgKCkKLSAgIlRlc3QgdGhhdCB0aGUgYmFja3NsYXNoIGlz IG5vdCBwcmVzZXJ2ZWQgZm9yIGVzY2FwZWQgc3BlY2lhbAotY2hhcnMuIgotICAod2l0aC10 ZW1wLWVzaGVsbAotICAgKGVzaGVsbC1tYXRjaC1jb21tYW5kLW91dHB1dCAiZWNobyBcIlxc XCJoaVxcXFxcIiIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOzsgQmFja3Ns YXNoZXMgYXJlIGRvdWJsZWQgZm9yIHJlZ2V4cC4KLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIlxcXCJoaVxcXFxcbiIpKSkKLQotKGVydC1kZWZ0ZXN0IGVzaC1hcmctdGVz dC9lc2NhcGUtcXVvdGVkL25ld2xpbmUgKCkKLSAgIlRlc3QgdGhhdCBhbiBlc2NhcGVkIG5l d2xpbmUgaXMgZXF1aXZhbGVudCB0byB0aGUgZW1wdHkgc3RyaW5nLiIKLSAgKHdpdGgtdGVt cC1lc2hlbGwKLSAgIChlc2hlbGwtbWF0Y2gtY29tbWFuZC1vdXRwdXQgImVjaG8gXCJoaVxc XG50aGVyZVwiIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaGl0aGVyZVxu IikpKQorKGVydC1kZWZ0ZXN0IGVzaC1hcmctdGVzdC9lc2NhcGUtcXVvdGVkL2Jhc2ljICgp CisgICJUZXN0IHRoYXQgZG91YmxlLXF1b3RlZCB0ZXh0IGlzIG1hcmtlZCBhcyBlc2NhcGVk LiIKKyAgKHNob3VsZCAoZXF1YWwtaW5jbHVkaW5nLXByb3BlcnRpZXMKKyAgICAgICAgICAg KGVzaGVsbC10ZXN0LWNvbW1hbmQtcmVzdWx0ICJlY2hvIFwiaGlcIiIpCisgICAgICAgICAg ICMoImhpIiAwIDIgKGVzY2FwZWQgdCkpKSkKKyAgKHNob3VsZCAoZXF1YWwtaW5jbHVkaW5n LXByb3BlcnRpZXMKKyAgICAgICAgICAgKGVzaGVsbC10ZXN0LWNvbW1hbmQtcmVzdWx0ICJl Y2hvIFwiaGlcInRoZXJlIikKKyAgICAgICAgICAgIygiaGl0aGVyZSIgMCAyIChlc2NhcGVk IHQpKSkpKQorCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS1xdW90ZWQvYmFj a3NsYXNoLW5vbnNwZWNpYWwgKCkKKyAgIlRlc3QgdGhhdCBpbiBkb3VibGUtcXVvdGVzLCBc IlxcXCIgaXMgcHJlc2VydmVkIGJlZm9yZSBub25zcGVjaWFsIGNoYXJzLiIKKyAgKHNob3Vs ZCAoZXF1YWwtaW5jbHVkaW5nLXByb3BlcnRpZXMKKyAgICAgICAgICAgKGVzaGVsbC10ZXN0 LWNvbW1hbmQtcmVzdWx0ICJlY2hvIFwiaFxcaVwiIikKKyAgICAgICAgICAgIygiaFxcaSIg MCAzIChlc2NhcGVkIHQpKSkpKQorCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2Fw ZS1xdW90ZWQvYmFja3NsYXNoLXNwZWNpYWwgKCkKKyAgIlRlc3QgdGhhdCBpbiBkb3VibGUt cXVvdGVzLCBcIlxcXCIgaXMgbm90IHByZXNlcnZlZCBiZWZvcmUgc3BlY2lhbCBjaGFycy4i CisgIChzaG91bGQgKGVxdWFsLWluY2x1ZGluZy1wcm9wZXJ0aWVzCisgICAgICAgICAgIChl c2hlbGwtdGVzdC1jb21tYW5kLXJlc3VsdCAiZWNobyBcIlxcXCJoaVxcXFxcIiIpCisgICAg ICAgICAgICMoIlwiaGlcXCIgMCA0IChlc2NhcGVkIHQpKSkpKQorCisoZXJ0LWRlZnRlc3Qg ZXNoLWFyZy10ZXN0L2VzY2FwZS1xdW90ZWQvYmFja3NsYXNoLW5ld2xpbmUgKCkKKyAgIlRl c3QgdGhhdCBpbiBkb3VibGUtcXVvdGVzLCBhbiBlc2NhcGVkIG5ld2xpbmUgZXhwYW5kcyB0 byB0aGUgZW1wdHkgc3RyaW5nLiIKKyAgKHNob3VsZCAoZXF1YWwtaW5jbHVkaW5nLXByb3Bl cnRpZXMKKyAgICAgICAgICAgKGVzaGVsbC10ZXN0LWNvbW1hbmQtcmVzdWx0ICJlY2hvIFwi aGlcXFxudGhlcmVcIiIpCisgICAgICAgICAgICMoImhpdGhlcmUiIDAgNyAoZXNjYXBlZCB0 KSkpKSkKKworKGVydC1kZWZ0ZXN0IGVzaC1hcmctdGVzdC9lc2NhcGUtc2luZ2xlLXF1b3Rl ZC9iYXNpYyAoKQorICAiVGVzdCB0aGF0IHNpbmdsZS1xdW90ZWQgdGV4dCBpcyBtYXJrZWQg YXMgZXNjYXBlZC4iCisgIChzaG91bGQgKGVxdWFsLWluY2x1ZGluZy1wcm9wZXJ0aWVzCisg ICAgICAgICAgIChlc2hlbGwtdGVzdC1jb21tYW5kLXJlc3VsdCAiZWNobyAnaGknIikKKyAg ICAgICAgICAgIygiaGkiIDAgMiAoZXNjYXBlZCB0KSkpKQorICAoc2hvdWxkIChlcXVhbC1p bmNsdWRpbmctcHJvcGVydGllcworICAgICAgICAgICAoZXNoZWxsLXRlc3QtY29tbWFuZC1y ZXN1bHQgImVjaG8gJ2hpJ3RoZXJlIikKKyAgICAgICAgICAgIygiaGl0aGVyZSIgMCAyIChl c2NhcGVkIHQpKSkpKQorCisoZXJ0LWRlZnRlc3QgZXNoLWFyZy10ZXN0L2VzY2FwZS1zaW5n bGUtcXVvdGVkL3NpbmdsZS1xdW90ZSAoKQorICAiVGVzdCB0aGF0IGEgZG91YmxlZCBzaW5n bGUtcXVvdGUgaW5zaWRlIHNpbmdsZS1xdW90ZXMgaXMgb25lIHNpbmdsZS1xdW90ZS4iCisg IChzaG91bGQgKGVxdWFsLWluY2x1ZGluZy1wcm9wZXJ0aWVzCisgICAgICAgICAgIChlc2hl bGwtdGVzdC1jb21tYW5kLXJlc3VsdCAiZWNobyAnaXQnJ3MgbWUnIikKKyAgICAgICAgICAg IygiaXQncyBtZSIgMCA3IChlc2NhcGVkIHQpKSkpKQogCiAoZXJ0LWRlZnRlc3QgZXNoLWFy Zy10ZXN0L3NwZWNpYWwtcmVmZXJlbmNlL2RlZmF1bHQgKCkKICAgIlRlc3QgdGhhdCBcIiM8 YnVmPlwiIHJlZmVycyB0byB0aGUgYnVmZmVyIFwiYnVmXCIuIgotLSAKMi4yNS4xCgo= --------------vuDo0Zym7x6wfKUFkl9ikDoF Content-Type: text/plain; charset=UTF-8; name="0002-Let-Eshell-expand-absolute-file-names-via-the-curren.patch" Content-Disposition: attachment; filename*0="0002-Let-Eshell-expand-absolute-file-names-via-the-curren.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA5Njc1ZTExMWY3NzRjNmU4NzQ4Y2Y3MjI2ZDk3MGQxNmRiZmE3ZjFmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IFNhdCwgOSBTZXAgMjAyMyAxNTo0MTo1MyAtMDcwMApTdWJqZWN0OiBbUEFU Q0ggMi8yXSBMZXQgRXNoZWxsIGV4cGFuZCBhYnNvbHV0ZSBmaWxlIG5hbWVzIHZpYSB0aGUg Y3VycmVudAogcmVtb3RlIGNvbm5lY3Rpb24KCiogbGlzcC9lc2hlbGwvZW0tZGlycy5lbCAo ZXNoZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1uYW1lcyk6IE5ldwpvcHRpb24uCihlc2hl bGwtcGFyc2UtYWJzb2x1dGUtZmlsZSk6IE5ldyBmdW5jdGlvbi4uLgooZXNoZWxsLWRpcnMt aW5pdGlhbGl6ZSk6IC4uLiB1c2UgaXQuCihlc2hlbGwtZXhwYW5kLWFic29sdXRlLWZpbGUp OiBOZXcgZnVuY3Rpb24uLi4KKGVzaGVsbC1wYXJzZS11c2VyLXJlZmVyZW5jZSk6IC4uLiB1 c2UgaXQuCihlc2hlbGwtZmlsZS1leHRlcm5hbC1uYW1lKTogTmV3IGZ1bmN0aW9uLgoKKiBs aXNwL2VzaGVsbC9lc2gtZXh0LmVsIChlc2hlbGwtLWZpbGUtZXh0ZXJuYWwtbmFtZXMpOiBO ZXcgZnVuY3Rpb24uLi4KKGVzaGVsbC1leHRlcm5hbC1jb21tYW5kKTogLi4uIHVzZSBpdC4K CiogdGVzdC9saXNwL2VzaGVsbC9lbS1kaXJzLXRlc3RzLmVsICh0cmFtcCk6IFJlcXVpcmUu CihlbS1kaXJzLXRlc3QvZXhwYW5kLXVzZXItcmVmZXJlbmNlL3JlbW90ZSkKKGVtLWRpcnMt dGVzdC9leHBhbmQtYWJzb2x1dGUtZmlsZS9sb2NhbCkKKGVtLWRpcnMtdGVzdC9leHBhbmQt YWJzb2x1dGUtZmlsZS9yZW1vdGUpCihlbS1kaXJzLXRlc3QvZXhwYW5kLWFic29sdXRlLWZp bGUvcXVvdGVkKTogTmV3IHRlc3RzLgoKKiB0ZXN0L2xpc3AvZXNoZWxsL2VzaC1leHQtdGVz dHMuZWwgKGVtLWRpcnMpOiBSZXF1aXJlLgooZW0tZXh0LXRlc3QvdW5leHBhbmQtcmVtb3Rl LWZpbGUvbG9jYWwpCihlbS1leHQtdGVzdC91bmV4cGFuZC1hYnNvbHV0ZS1maWxlL3JlbW90 ZSk6IE5ldyB0ZXN0cy4KCiogdGVzdC9saXNwL2VzaGVsbC9lc2hlbGwtdGVzdHMtaGVscGVy cy5lbAooZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsKTogTmV3IGFyZ3VtZW50IElHTk9S RS1FUlJPUlMuCgoqIGRvYy9taXNjL2VzaGVsbC50ZXhpIChSZW1vdGUgQWNjZXNzKTogRG9j dW1lbnQKJ2VzaGVsbC1jb25uZWN0aW9uLWxvY2FsLWZpbGUtbmFtZXMnLgoKKiBldGMvTkVX UzogQW5ub3VuY2UgdGhpcyBjaGFuZ2UuCi0tLQogZG9jL21pc2MvZXNoZWxsLnRleGkgICAg ICAgICAgICAgICAgICAgICB8IDM3ICsrKysrKysrKysrKy0tCiBldGMvTkVXUyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgMjUgKysrKystLS0tCiBsaXNwL2VzaGVsbC9l bS1kaXJzLmVsICAgICAgICAgICAgICAgICAgIHwgNjQgKysrKysrKysrKysrKysrKysrKysr KysrCiBsaXNwL2VzaGVsbC9lc2gtZXh0LmVsICAgICAgICAgICAgICAgICAgIHwgMTYgKysr KystCiB0ZXN0L2xpc3AvZXNoZWxsL2VtLWRpcnMtdGVzdHMuZWwgICAgICAgIHwgNDggKysr KysrKysrKysrKysrKysrCiB0ZXN0L2xpc3AvZXNoZWxsL2VzaC1leHQtdGVzdHMuZWwgICAg ICAgIHwgNDMgKysrKysrKysrKysrKysrKwogdGVzdC9saXNwL2VzaGVsbC9lc2hlbGwtdGVz dHMtaGVscGVycy5lbCB8IDE1ICsrKy0tLQogNyBmaWxlcyBjaGFuZ2VkLCAyMjkgaW5zZXJ0 aW9ucygrKSwgMTkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZG9jL21pc2MvZXNoZWxs LnRleGkgYi9kb2MvbWlzYy9lc2hlbGwudGV4aQppbmRleCAzMGM4NWRhNzk1Yi4uYmJkNTcw OTIzZjcgMTAwNjQ0Ci0tLSBhL2RvYy9taXNjL2VzaGVsbC50ZXhpCisrKyBiL2RvYy9taXNj L2VzaGVsbC50ZXhpCkBAIC0xNTI3LDkgKzE1MjcsNDAgQEAgUmVtb3RlIEFjY2VzcwogYnVp bHQtaW4gY29tbWFuZHMgb3IgTGlzcCBmdW5jdGlvbnMgZnJvbSBhIHJlbW90ZSBkaXJlY3Rv cnksIHlvdSBtdXN0CiBiZSBjYXJlZnVsIGFib3V0IHNwZWNpZnlpbmcgYWJzb2x1dGUgZmls ZSBuYW1lczogQHNhbXB7Y2F0CiAvdmFyL291dHB1dC5sb2d9IHdpbGwgYWx3YXlzIHByaW50 IHRoZSBjb250ZW50cyBvZiB5b3VyIEBlbXBoe2xvY2FsfQotQGZpbGV7L3Zhci9vdXRwdXQu bG9nfSwgZXZlbiBmcm9tIGEgcmVtb3RlIGRpcmVjdG9yeS4gIElmIHlvdSBmaW5kCi10aGlz IGJlaGF2aW9yIGFubm95aW5nLCB5b3UgY2FuIGVuYWJsZSB0aGUgb3B0aW9uYWwgZWxlY3Ry aWMgZm9yd2FyZAotc2xhc2ggbW9kdWxlIChAcHhyZWZ7RWxlY3RyaWMgZm9yd2FyZCBzbGFz aH0pLgorQGZpbGV7L3Zhci9vdXRwdXQubG9nfSwgZXZlbiBmcm9tIGEgcmVtb3RlIGRpcmVj dG9yeS4KKworQHZpbmRleCBlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzCitJ ZiB5b3UgZmluZCB0aGlzIGJlaGF2aW9yIGFubm95aW5nLCB5b3UgY2FuIGN1c3RvbWl6ZSBF c2hlbGwgdG8gaGVscCB5b3UKK3JlZmVyIHRvIHJlbW90ZSBmaWxlcyB3aGVuIGluIGEgcmVt b3RlIGRpcmVjdG9yeS4gIEJ5IHNldHRpbmcKK0Bjb2Rle2VzaGVsbC1jb25uZWN0aW9uLWxv Y2FsLWZpbGUtbmFtZXN9IHRvIEBjb2Rle3R9LCB5b3UgY2FuIG1ha2UKK0VzaGVsbCBleHBh bmQgYWJzb2x1dGUgZmlsZSBuYW1lcyBsaWtlIEBmaWxley92YXIvb3V0cHV0LmxvZ30gb3IK K0BmaWxle351c2VyfSB3aXRoaW4gdGhlIHJlbW90ZSBjb25uZWN0aW9uIGFzc29jYXRlZCB3 aXRoIHRoZSBjdXJyZW50CitkaXJlY3Rvcnk6CisKK0BleGFtcGxlCisvc3NoOnVzZXJAQHJl bW90ZTp+ICQgY29uY2F0ICJsb2cgaXMgYXQgIiAvdmFyL291dHB1dC5sb2cKK2xvZyBpcyBh dCAvc3NoOnVzZXJAQHJlbW90ZTovdmFyL291dHB1dC5sb2cKK0BlbmQgZXhhbXBsZQorCitX aGVuIHVzaW5nIHRoaXMgb3B0aW9uLCB5b3UgY2FuIGF2b2lkIHRoaXMgZXhwYW5zaW9uIGJ5 CitxdW90aW5nIG9yIGVzY2FwaW5nIHRoZSBpbml0aWFsIEBzYW1wey99IG9yIEBzYW1we359 LCBvciBieSBleHBsaWNpdGx5Cit0eXBpbmcgdGhlIGNvbm5lY3Rpb24uICBUbyBleHBsaWNp dGx5IHJlZmVyIHRvIGEgQGVtcGh7bG9jYWx9IGZpbGUsIHlvdQorY2FuIHF1b3RlIHRoZSBm aWxlIG5hbWU6CisKK0BleGFtcGxlCisvc3NoOnVzZXJAQHJlbW90ZTovZXRjICQgY2Qgfgor L3NzaDp1c2VyQEByZW1vdGU6fiAkIGNkIC86fgorfiAkCitAZW5kIGV4YW1wbGUKKworV2hl biB0aGlzIG9wdGlvbiBpcyBlbmFibGVkLCBFc2hlbGwgd2lsbCBhbHNvIGBgdW5leHBhbmQn JyBhbnkgcmVtb3RlCitmaWxlIG5hbWVzIChlLmcuQDogQHNhbXB7L3NzaDp1c2VyQEByZW1v dGU6ZmlsZS50eHR9KSBvciBiZWZvcmUgc2VuZGluZwordGhlbSB0byBleHRlcm5hbCBjb21t YW5kcywgc28gdGhvc2UgY29tbWFuZHMgb25seSBzZWUgQGZpbGV7ZmlsZS50eHR9IGFzCit0 aGV5IGV4cGVjdC4KKworSWYgeW91IGluc3RlYWQgcHJlZmVyIHRvIGtlZXAgdGhlIGRlZmF1 bHQgbG9naWMgYnV0IG1ha2UgaXQgZWFzaWVyIHRvCit0eXBlIHRoZSBmdWxsIHJlbW90ZSBm aWxlIG5hbWVzLCB5b3UgY2FuIGVuYWJsZSB0aGUgb3B0aW9uYWwgZWxlY3RyaWMKK2Zvcndh cmQgc2xhc2ggbW9kdWxlIChAcHhyZWZ7RWxlY3RyaWMgZm9yd2FyZCBzbGFzaH0pLgogCiBA dmluZGV4IGVzaGVsbC1leHBsaWNpdC1yZW1vdGUtY29tbWFuZHMKIFdoZW4gcnVubmluZyBj b21tYW5kcywgeW91IGNhbiBhbHNvIG1ha2UgdGhlbSBleHBsaWNpdGx5IHJlbW90ZSBieQpk aWZmIC0tZ2l0IGEvZXRjL05FV1MgYi9ldGMvTkVXUwppbmRleCA0NTZmOWI4ZjhiOC4uNGM0 YjgwN2I0ZjMgMTAwNjQ0Ci0tLSBhL2V0Yy9ORVdTCisrKyBiL2V0Yy9ORVdTCkBAIC04NTQs NiArODU0LDIyIEBAIHVzaW5nIHRoaXMgbmV3IG9wdGlvbi4gIChPciBzZXQgJ2Rpc3BsYXkt YnVmZmVyLWFsaXN0JyBkaXJlY3RseS4pCiAKICoqIEVzaGVsbAogCisrKysKKyoqKiBFc2hl bGwgY29tbWFuZHMgY2FuIG5vdyBiZSBleHBsaWNpdGx5LXJlbW90ZSAob3IgbG9jYWwpLgor QnkgcHJlZml4aW5nIGEgY29tbWFuZCBuYW1lIGluIEVzaGVsbCB3aXRoIGEgcmVtb3RlIGlk ZW50aWZpZXIsIGxpa2UKKyIvc3NoOnVzZXJAcmVtb3RlOndob2FtaSIsIHlvdSBjYW4gbm93 IHJ1biBjb21tYW5kcyBvbiBhIHBhcnRpY3VsYXIKK2hvc3Qgbm8gbWF0dGVyIHlvdXIgY3Vy cmVudCBkaXJlY3RvcnkuICBMaWtld2lzZSwgeW91IGNhbiBydW4gYQorY29tbWFuZCBvbiB5 b3VyIGxvY2FsIHN5c3RlbSBubyBtYXR0ZXIgeW91ciBjdXJyZW50IGRpcmVjdG9yeSB2aWEK KyIvOndob2FtaSIuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgc2VlIHRoZSAiKGVzaGVsbCkg UmVtb3RlIEFjY2VzcyIKK25vZGUgaW4gdGhlIEVzaGVsbCBtYW51YWwuCisKKysrKworKioq IE5ldyBvcHRpb24gdG8gZXhwYW5kIGFic29sdXRlIGZpbGUgbmFtZXMgdmlhIHRoZSBjdXJy ZW50IHJlbW90ZSBjb25uZWN0aW9uLgorQnkgc2V0dGluZyAnZXNoZWxsLWNvbm5lY3Rpb24t bG9jYWwtZmlsZS1uYW1lcycgdG8gYSBub24tbmlsIHZhbHVlLAorRXNoZWxsIHdpbGwgZXhw YW5kIGFic29sdXRlIGZpbGUgbmFtZXMgbGlrZSAiL2Zvby9iYXIiIG9yICJ+L3VzZXIiCit3 aXRoaW4gdGhlIGN1cnJlbnQgcmVtb3RlIGNvbm5lY3Rpb24uICBTZWUgIihlc2hlbGwpIFJl bW90ZSBBY2Nlc3MiIGZvcgorbW9yZSBkZXRhaWxzLgorCiArKysKICoqKiBOZXcgYnVpbHRp biBFc2hlbGwgY29tbWFuZCAnY29tcGlsZScuCiBUaGlzIGNvbW1hbmQgcnVucyBhbm90aGVy IGNvbW1hbmQsIHNlbmRpbmcgaXRzIG91dHB1dCB0byBhIGNvbXBpbGF0aW9uCkBAIC05MDks MTUgKzkyNSw2IEBAIG9yIGdldCBhIHN1Ymxpc3Qgb2YgZWxlbWVudHMgMiB0aHJvdWdoIDQg d2l0aCAnJG15LWxpc3RbMi4uNV0nLiAgRm9yCiBtb3JlIGluZm9ybWF0aW9uLCBzZWUgdGhl ICIoZXNoZWxsKSBEb2xsYXJzIEV4cGFuc2lvbiIgbm9kZSBpbiB0aGUKIEVzaGVsbCBtYW51 YWwuCiAKLSsrKwotKioqIEVzaGVsbCBjb21tYW5kcyBjYW4gbm93IGJlIGV4cGxpY2l0bHkt cmVtb3RlIChvciBsb2NhbCkuCi1CeSBwcmVmaXhpbmcgYSBjb21tYW5kIG5hbWUgaW4gRXNo ZWxsIHdpdGggYSByZW1vdGUgaWRlbnRpZmllciwgbGlrZQotIi9zc2g6dXNlckByZW1vdGU6 d2hvYW1pIiwgeW91IGNhbiBub3cgcnVuIGNvbW1hbmRzIG9uIGEgcGFydGljdWxhcgotaG9z dCBubyBtYXR0ZXIgeW91ciBjdXJyZW50IGRpcmVjdG9yeS4gIExpa2V3aXNlLCB5b3UgY2Fu IHJ1biBhCi1jb21tYW5kIG9uIHlvdXIgbG9jYWwgc3lzdGVtIG5vIG1hdHRlciB5b3VyIGN1 cnJlbnQgZGlyZWN0b3J5IHZpYQotIi86d2hvYW1pIi4gIEZvciBtb3JlIGluZm9ybWF0aW9u LCBzZWUgdGhlICIoZXNoZWxsKSBSZW1vdGUgQWNjZXNzIgotbm9kZSBpbiB0aGUgRXNoZWxs IG1hbnVhbC4KLQogKysrCiAqKiogRXNoZWxsJ3MgJyRVSUQnIGFuZCAnJEdJRCcgdmFyaWFi bGVzIGFyZSBub3cgY29ubmVjdGlvbi1hd2FyZS4KIE5vdywgd2hlbiBleHBhbmRpbmcgJyRV SUQnIG9yICckR0lEJyBpbiBhIHJlbW90ZSBkaXJlY3RvcnksIHRoZSB2YWx1ZQpkaWZmIC0t Z2l0IGEvbGlzcC9lc2hlbGwvZW0tZGlycy5lbCBiL2xpc3AvZXNoZWxsL2VtLWRpcnMuZWwK aW5kZXggMDcwNjNhZmMyODYuLjg2NDJkZWUxODU1IDEwMDY0NAotLS0gYS9saXNwL2VzaGVs bC9lbS1kaXJzLmVsCisrKyBiL2xpc3AvZXNoZWxsL2VtLWRpcnMuZWwKQEAgLTY1LDYgKzY1 LDE4IEBAIGVzaGVsbC1kaXJzLWxvYWQtaG9vawogICA6dmVyc2lvbiAiMjQuMSIJCQk7IHJl bW92ZWQgZXNoZWxsLWRpcnMtaW5pdGlhbGl6ZQogICA6dHlwZSAnaG9vaykKIAorKGRlZmN1 c3RvbSBlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzIG5pbAorICAiSWYgbm9u LW5pbCwgZXhwYW5kIGFic29sdXRlIGZpbGUgbmFtZSB3aXRoaW4gdGhlIGN1cnJlbnQgcmVt b3RlIGNvbm5lY3Rpb24uCitXaGVuIHRoaXMgb3B0aW9uIGlzIGVuYWJsZWQsIEVzaGVsbCBl eHBhbmRzIGFic29sdXRlIGZpbGUgbmFtZXMgbGlrZQorXCIvZm9vL2JhclwiIG9yIFwifnVz ZXJcIiB3aXRoaW4gdGhlIHJlbW90ZSBjb25uZWN0aW9uIGFzc29jaWF0ZWQgd2l0aAordGhl IGN1cnJlbnQgd29ya2luZyBkaXJlY3RvcnkuCisKK0FkZGl0aW9uYWxseSwgd2hlbiB0aGlz IG9wdGlvbiBpcyBlbmFibGVkLCBFc2hlbGwgd2lsbAorXCJ1bmV4cGFuZFwiIHJlbW90ZSBv ciBxdW90ZWQgZmlsZSBuYW1lcyBiZWZvcmUgcGFzc2luZyB0aGVtIHRvCitleHRlcm5hbCBj b21tYW5kcyAoc2VlIGBlc2hlbGwtZmlsZS1leHRlcm5hbC1uYW1lJykuIgorICA6dmVyc2lv biAiMzAuMSIKKyAgOnR5cGUgJ2Jvb2xlYW4pCisKIChkZWZjdXN0b20gZXNoZWxsLXB3ZC1j b252ZXJ0LWZ1bmN0aW9uIChpZiAoZXNoZWxsLXVuZGVyLXdpbmRvd3MtcCkKIAkJCQkJICAg IydleHBhbmQtZmlsZS1uYW1lCiAJCQkJCSAjJ2lkZW50aXR5KQpAQCAtMjA1LDYgKzIxNyw5 IEBAIGVzaGVsbC1kaXJzLWluaXRpYWxpemUKIAogICAoYWRkLWhvb2sgJ2VzaGVsbC1wYXJz ZS1hcmd1bWVudC1ob29rCiAJICAgICMnZXNoZWxsLXBhcnNlLXVzZXItcmVmZXJlbmNlIG5p bCB0KQorICAod2hlbiBlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzCisgICAg KGFkZC1ob29rICdlc2hlbGwtcGFyc2UtYXJndW1lbnQtaG9vaworCSAgICAgICMnZXNoZWxs LXBhcnNlLWFic29sdXRlLWZpbGUgbmlsIHQpKQogICAoaWYgKGVzaGVsbC11bmRlci13aW5k b3dzLXApCiAgICAgICAoYWRkLWhvb2sgJ2VzaGVsbC1wYXJzZS1hcmd1bWVudC1ob29rCiAJ CSMnZXNoZWxsLXBhcnNlLWRyaXZlLWxldHRlciBuaWwgdCkpCkBAIC0yNjcsOSArMjgyLDU4 IEBAIGVzaGVsbC1wYXJzZS11c2VyLXJlZmVyZW5jZQogICAgIDs7IEFwcGx5IHRoaXMgbW9k aWZpZXIgZmFpcmx5IGVhcmx5IHNvIGl0IGhhcHBlbnMgYmVmb3JlIHRoaW5ncwogICAgIDs7 IGxpa2UgZ2xvYiBleHBhbnNpb24uCiAgICAgKGFkZC1ob29rICdlc2hlbGwtY3VycmVudC1t b2RpZmllcnMgIydlc2hlbGwtZXhwYW5kLXVzZXItcmVmZXJlbmNlIC01MCkKKyAgICAod2hl biBlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzCisgICAgICAoYWRkLWhvb2sg J2VzaGVsbC1jdXJyZW50LW1vZGlmaWVycyAjJ2VzaGVsbC1leHBhbmQtYWJzb2x1dGUtZmls ZSAtNDApKQorICAgIChmb3J3YXJkLWNoYXIpCisgICAgKGNoYXItdG8tc3RyaW5nIChjaGFy LWJlZm9yZSkpKSkKKworKGRlZnVuIGVzaGVsbC1leHBhbmQtYWJzb2x1dGUtZmlsZSAoZmls ZSkKKyAgIkV4cGFuZCBhbiBhYnNvbHV0ZSBGSUxFIGxpa2UgXCIvZm9vL2JhclwiIHRvIGJl IG9uIHRoZSBjdXJyZW50IHJlbW90ZSBob3N0LgorVGhpcyB0cmVhdHMgcXVvdGVkIGZpbGUg bmFtZXMgbGlrZSBcIi86L2Zvby9iYXJcIiBsaXRlcmFsbHkuIgorICAoaWYgKG9yIChmaWxl LW5hbWUtcXVvdGVkLXAgZmlsZSB0KQorICAgICAgICAgIChmaWxlLXJlbW90ZS1wIGZpbGUp CisgICAgICAgICAgOzsgRG9uJ3QgZXhwYW5kIHZpcnR1YWwgdGFyZ2V0czsgb3RoZXJ3aXNl LCB3ZSdkIGZhaWwgdG8KKyAgICAgICAgICA7OyBmaW5kIHRoZW0gbGF0ZXIgaW4gYGVzaGVs bC1nZXQtdGFyZ2V0Jy4KKyAgICAgICAgICAoYXNzb2MgZmlsZSBlc2hlbGwtdmlydHVhbC10 YXJnZXRzKSkKKyAgICAgIGZpbGUKKyAgICAoY29uY2F0IChmaWxlLXJlbW90ZS1wIGRlZmF1 bHQtZGlyZWN0b3J5KSBmaWxlKSkpCisKKyhkZWZ1biBlc2hlbGwtcGFyc2UtYWJzb2x1dGUt ZmlsZSAoKQorICAiQW4gYXJndW1lbnQgYmVnaW5uaW5nIHdpdGggLyBpcyBhIGZpbGVuYW1l IHRvIGJlIGV4cGFuZGVkLiIKKyAgKHdoZW4gKGFuZCAobm90IGVzaGVsbC1jdXJyZW50LWFy Z3VtZW50KQorICAgICAgICAgICAgIChub3QgZXNoZWxsLWN1cnJlbnQtcXVvdGVkKQorICAg ICAgICAgICAgIChlcSAoY2hhci1hZnRlcikgPy8pKQorICAgIChhZGQtaG9vayAnZXNoZWxs LWN1cnJlbnQtbW9kaWZpZXJzICMnZXNoZWxsLWV4cGFuZC1hYnNvbHV0ZS1maWxlIC01MCkK ICAgICAoZm9yd2FyZC1jaGFyKQogICAgIChjaGFyLXRvLXN0cmluZyAoY2hhci1iZWZvcmUp KSkpCiAKKyhkZWZ1biBlc2hlbGwtZmlsZS1leHRlcm5hbC1uYW1lIChmaWxlKQorICAiU2lt cGxpZnkgRklMRSBzbyB0aGF0IGV4dGVybmFsIGNvbW1hbmRzIGNhbiB1bmRlcnN0YW5kIGl0 LgorVGhpcyByZXR1cm5zIHRoZSB1bnF1b3RlZCBsb2NhbCBwYXJ0IG9mIHRoZSBmaWxlIG5h bWUuICBJZiB0aGUKK3JlbW90ZSBjb25uZWN0aW9uIGFzc29jaWF0ZWQgd2l0aCBGSUxFIGRv ZXNuJ3QgbWF0Y2gKK2BkZWZhdWx0LWRpcmVjdG9yeScsIHNpZ25hbCBhbiBlcnJvci4KKwor V2hlbiBGSUxFIGRvZXNuJ3Qgc3RhcnQgd2l0aCBhIFwiL1wiLCBvciB0aGUgbGVhZGluZyBc Ii9cIiBpcworZXNjYXBlZCwganVzdCByZXR1cm4gRklMRSBhcy1pcy4iCisgIChpZiAob3Ig KG5vdCAoZXEgKGFyZWYgZmlsZSAwKSA/LykpCisgICAgICAgICAgKGdldC10ZXh0LXByb3Bl cnR5IDAgJ2VzY2FwZWQgZmlsZSkpCisgICAgICBmaWxlCisgICAgOzsgQ2hlY2sgdGhhdCB0 aGUgZmlsZSBhbmQgY3dkIGNvbm5lY3Rpb25zIGFyZSB0aGUgc2FtZS4KKyAgICAobGV0ICgo ZmlsZS1jb25uZWN0aW9uIChmaWxlLXJlbW90ZS1wIGZpbGUpKQorICAgICAgICAgIChjd2Qt Y29ubmVjdGlvbiAoZmlsZS1yZW1vdGUtcCBkZWZhdWx0LWRpcmVjdG9yeSkpKQorICAgICAg KGNvbmQKKyAgICAgICAoKGVxdWFsIGZpbGUtY29ubmVjdGlvbiBjd2QtY29ubmVjdGlvbikp IDsgSXQncyBvayEKKyAgICAgICAoKG5vdCBmaWxlLWNvbm5lY3Rpb24pCisgICAgICAgIChl cnJvciAiYCVzJyBpcyBsb2NhbCwgYnV0IGN1cnJlbnQgZGlyZWN0b3J5IGlzIHJlbW90ZSAo YCVzJykiCisgICAgICAgICAgICAgICBmaWxlIGN3ZC1jb25uZWN0aW9uKSkKKyAgICAgICAo KG5vdCBjd2QtY29ubmVjdGlvbikKKyAgICAgICAgKGVycm9yICJgJXMnIGlzIHJlbW90ZSwg YnV0IGN1cnJlbnQgZGlyZWN0b3J5IGlzIGxvY2FsIgorICAgICAgICAgICAgICAgZmlsZSkp CisgICAgICAgKHQKKyAgICAgICAgKGVycm9yICJgJXMnIGRvZXMgbm90IG1hdGNoIGN1cnJl bnQgY29ubmVjdGlvbiBgJXMnIgorICAgICAgICAgICAgICAgZmlsZSBjd2QtY29ubmVjdGlv bikpKSkKKyAgICAoZmlsZS1uYW1lLXVucXVvdGUgKGZpbGUtbG9jYWwtbmFtZSBmaWxlKSB0 KSkpCisKIChkZWZ1biBlc2hlbGwtcGFyc2UtZHJpdmUtbGV0dGVyICgpCiAgICJBbiBhcmd1 bWVudCBiZWdpbm5pbmcgd2l0aCBYOlteL10gaXMgYSBkcml2ZSBsZXR0ZXIgcmVmZXJlbmNl LiIKICAgKHdoZW4gKGFuZCAobm90IGVzaGVsbC1jdXJyZW50LWFyZ3VtZW50KQpkaWZmIC0t Z2l0IGEvbGlzcC9lc2hlbGwvZXNoLWV4dC5lbCBiL2xpc3AvZXNoZWxsL2VzaC1leHQuZWwK aW5kZXggNDQ4NjFjMjIyYjguLjYzNTExNGJjZWE0IDEwMDY0NAotLS0gYS9saXNwL2VzaGVs bC9lc2gtZXh0LmVsCisrKyBiL2xpc3AvZXNoZWxsL2VzaC1leHQuZWwKQEAgLTIyOSw5ICsy MjksMjMgQEAgZXNoZWxsLXJlbW90ZS1jb21tYW5kCiAgICAgICAoZXJyb3IgIiVzOiBub3Qg YSByZW1vdGUgY29tbWFuZCIgY29tbWFuZCkpCiAgICAgKGVzaGVsbC1leHRlcm5hbC1jb21t YW5kIGNvbW1hbmQtbG9jYWxuYW1lIGFyZ3MpKSkKIAorKGRlZnVuIGVzaGVsbC0tZmlsZS1l eHRlcm5hbC1uYW1lcyAoYXJncykKKyAgIlNpbXBsaWZ5IEFSR1Mgc28gdGhhdCBleHRlcm5h bCBjb21tYW5kcyBjYW4gdW5kZXJzdGFuZCBhbnkgZmlsZSBuYW1lcy4KK0lmIGBlc2hlbGwt Y29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzJyBpcyBuaWwgb3IgdGhlIGBlc2hlbGwtZGly cycKK21vZHVsZSBpcyBkaXNhYmxlZCwganVzdCByZXR1cm4gQVJHUyB1bmNoYW5nZWQuIgor ICAoZGVjbGFyZS1mdW5jdGlvbiBlc2hlbGwtZmlsZS1leHRlcm5hbC1uYW1lICJlbS1kaXJz IiAoZmlsZSkpCisgIChkZWZ2YXIgZXNoZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1uYW1l cykKKyAgKGlmIChhbmQgKGVzaGVsbC11c2luZy1tb2R1bGUgJ2VzaGVsbC1kaXJzKQorICAg ICAgICAgICAoYm91bmQtYW5kLXRydWUtcCBlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxl LW5hbWVzKSkKKyAgICAgIChtYXBjYXIgKGxhbWJkYSAoYXJnKQorICAgICAgICAgICAgICAg IChpZiAoc3RyaW5ncCBhcmcpIChlc2hlbGwtZmlsZS1leHRlcm5hbC1uYW1lIGFyZykgYXJn KSkKKyAgICAgICAgICAgICAgYXJncykKKyAgICBhcmdzKSkKKwogKGRlZnVuIGVzaGVsbC1l eHRlcm5hbC1jb21tYW5kIChjb21tYW5kIGFyZ3MpCiAgICJJbnNlcnQgb3V0cHV0IGZyb20g YW4gZXh0ZXJuYWwgQ09NTUFORCwgdXNpbmcgQVJHUy4iCi0gIChzZXRxIGFyZ3MgKGVzaGVs bC1zdHJpbmdpZnktbGlzdCAoZmxhdHRlbi10cmVlIGFyZ3MpKSkKKyAgKHNldHEgYXJncyAo ZXNoZWxsLXN0cmluZ2lmeS1saXN0CisgICAgICAgICAgICAgIChlc2hlbGwtLWZpbGUtZXh0 ZXJuYWwtbmFtZXMgKGZsYXR0ZW4tdHJlZSBhcmdzKSkpKQogICAobGV0ICgoaW50ZXJwIChl c2hlbGwtZmluZC1pbnRlcnByZXRlcgogCQkgY29tbWFuZAogCQkgYXJncwpkaWZmIC0tZ2l0 IGEvdGVzdC9saXNwL2VzaGVsbC9lbS1kaXJzLXRlc3RzLmVsIGIvdGVzdC9saXNwL2VzaGVs bC9lbS1kaXJzLXRlc3RzLmVsCmluZGV4IDk3ODllNTE5ZjRjLi4zMjhjZWMyOTk0ZCAxMDA2 NDQKLS0tIGEvdGVzdC9saXNwL2VzaGVsbC9lbS1kaXJzLXRlc3RzLmVsCisrKyBiL3Rlc3Qv bGlzcC9lc2hlbGwvZW0tZGlycy10ZXN0cy5lbApAQCAtMjMsNiArMjMsNyBAQAogCiA7Ozsg Q29kZToKIAorKHJlcXVpcmUgJ3RyYW1wKQogKHJlcXVpcmUgJ2VydCkKIChyZXF1aXJlICdl c2gtbW9kZSkKIChyZXF1aXJlICdlc2hlbGwpCkBAIC0xMTIsMTIgKzExMyw1OSBAQCBlbS1k aXJzLXRlc3QvZXhwYW5kLXVzZXItcmVmZXJlbmNlL2xvY2FsCiAgICAoZm9ybWF0ICJlY2hv IH4lcyIgdXNlci1sb2dpbi1uYW1lKQogICAgKGV4cGFuZC1maWxlLW5hbWUgKGZvcm1hdCAi fiVzIiB1c2VyLWxvZ2luLW5hbWUpKSkpCiAKKyhlcnQtZGVmdGVzdCBlbS1kaXJzLXRlc3Qv ZXhwYW5kLXVzZXItcmVmZXJlbmNlL3JlbW90ZSAoKQorICAiVGVzdCBleHBhbnNpb24gb2Yg XCJ+VVNFUlwiIHJlZmVyZW5jZXMgaW4gcmVtb3RlIGRpcmVjdG9yaWVzLiIKKyAgKHNraXAt dW5sZXNzIChlc2hlbGwtdGVzdHMtcmVtb3RlLWFjY2Vzc2libGUtcCkpCisgIChsZXQqICgo ZGVmYXVsdC1kaXJlY3RvcnkgZXJ0LXJlbW90ZS10ZW1wb3JhcnktZmlsZS1kaXJlY3Rvcnkp CisgICAgICAgICAocmVtb3RlIChmaWxlLXJlbW90ZS1wIGRlZmF1bHQtZGlyZWN0b3J5KSkp CisgICAgKGxldCAoKGVzaGVsbC1jb25uZWN0aW9uLWxvY2FsLWZpbGUtbmFtZXMgdCkpCisg ICAgICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsCisgICAgICAgImVjaG8gfiIKKyAg ICAgICAoY29uY2F0IHJlbW90ZSAoZXhwYW5kLWZpbGUtbmFtZSAifiIpKSkKKyAgICAgIChl c2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwKKyAgICAgICAoZm9ybWF0ICJlY2hvIH4lcyIg dXNlci1sb2dpbi1uYW1lKQorICAgICAgIChjb25jYXQgcmVtb3RlIChleHBhbmQtZmlsZS1u YW1lIChmb3JtYXQgIn4lcyIgdXNlci1sb2dpbi1uYW1lKSkpKSkKKyAgICAobGV0ICgoZXNo ZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1uYW1lcyBuaWwpKQorICAgICAgKGVzaGVsbC1j b21tYW5kLXJlc3VsdC1lcXVhbCAiZWNobyB+IiAoZXhwYW5kLWZpbGUtbmFtZSAifiIpKQor ICAgICAgKGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbAorICAgICAgIChmb3JtYXQgImVj aG8gfiVzIiB1c2VyLWxvZ2luLW5hbWUpCisgICAgICAgKGV4cGFuZC1maWxlLW5hbWUgKGZv cm1hdCAifiVzIiB1c2VyLWxvZ2luLW5hbWUpKSkpKSkKKwogKGVydC1kZWZ0ZXN0IGVtLWRp cnMtdGVzdC9leHBhbmQtdXNlci1yZWZlcmVuY2UvcXVvdGVkICgpCiAgICJUZXN0IHRoYXQg YSBxdW90ZWQgXCJ+XCIgaXNuJ3QgZXhwYW5kZWQuIgogICAoZXNoZWxsLWNvbW1hbmQtcmVz dWx0LWVxdWFsICJlY2hvIFxcfiIgIn4iKQogICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVx dWFsICJlY2hvIFwiflwiIiAifiIpCiAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwg ImVjaG8gJ34nIiAifiIpKQogCisoZXJ0LWRlZnRlc3QgZW0tZGlycy10ZXN0L2V4cGFuZC1h YnNvbHV0ZS1maWxlL2xvY2FsICgpCisgICJUZXN0IFwiZXhwYW5zaW9uXCIgb2YgYWJzb2x1 dGUgZmlsZXMgaW4gbG9jYWwgZGlyZWN0b3JpZXMuCitUaGlzIHNob3VsZCBhbHdheXMgYmUg YSBuby1vcC4iCisgIChsZXQgKChlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVz IHQpKQorICAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgImVjaG8gL2Jpbi9mb28i ICIvYmluL2ZvbyIpKQorICAobGV0ICgoZXNoZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1u YW1lcyBuaWwpKQorICAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgImVjaG8gL2Jp bi9mb28iICIvYmluL2ZvbyIpKSkKKworKGVydC1kZWZ0ZXN0IGVtLWRpcnMtdGVzdC9leHBh bmQtYWJzb2x1dGUtZmlsZS9yZW1vdGUgKCkKKyAgIlRlc3QgZXhwYW5zaW9uIG9mIGFic29s dXRlIGZpbGVzIGluIHJlbW90ZSBkaXJlY3Rvcmllcy4KK1RoaXMgc2hvdWxkIGJlIGEgZmls ZSBuYW1lIG9uIHRoZSByZW1vdGUgaG9zdCB3aGVuCitgZXNoZWxsLWNvbm5lY3Rpb24tbG9j YWwtZmlsZS1uYW1lcycgaXMgbm9uLW5pbC4iCisgIChza2lwLXVubGVzcyAoZXNoZWxsLXRl c3RzLXJlbW90ZS1hY2Nlc3NpYmxlLXApKQorICAobGV0KiAoKGRlZmF1bHQtZGlyZWN0b3J5 IGVydC1yZW1vdGUtdGVtcG9yYXJ5LWZpbGUtZGlyZWN0b3J5KQorICAgICAgICAgKHJlbW90 ZSAoZmlsZS1yZW1vdGUtcCBkZWZhdWx0LWRpcmVjdG9yeSkpKQorICAgIChsZXQgKChlc2hl bGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzIHQpKQorICAgICAgKGVzaGVsbC1jb21t YW5kLXJlc3VsdC1lcXVhbCAiZWNobyAvYmluL2ZvbyIgKGNvbmNhdCByZW1vdGUgIi9iaW4v Zm9vIikpKQorICAgIChsZXQgKChlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVz IG5pbCkpCisgICAgICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsICJlY2hvIC9iaW4v Zm9vIiAiL2Jpbi9mb28iKSkpKQorCisoZXJ0LWRlZnRlc3QgZW0tZGlycy10ZXN0L2V4cGFu ZC1hYnNvbHV0ZS1maWxlL3F1b3RlZCAoKQorICAiVGVzdCB0aGF0IGEgcXVvdGVkIFwiL1wi IGZvciBhbiBhYnNvbHV0ZSBmaWxlIGlzbid0IGV4cGFuZGVkLiIKKyAgKHNraXAtdW5sZXNz IChlc2hlbGwtdGVzdHMtcmVtb3RlLWFjY2Vzc2libGUtcCkpCisgIChsZXQgKChkZWZhdWx0 LWRpcmVjdG9yeSBlcnQtcmVtb3RlLXRlbXBvcmFyeS1maWxlLWRpcmVjdG9yeSkKKyAgICAg ICAgKGVzaGVsbC1jb25uZWN0aW9uLWxvY2FsLWZpbGUtbmFtZXMgdCkpCisgICAgKGVzaGVs bC1jb21tYW5kLXJlc3VsdC1lcXVhbCAiZWNobyBcXC9iaW4vZm9vIiAiL2Jpbi9mb28iKQor ICAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgImVjaG8gXCIvYmluL2Zvb1wiIiAi L2Jpbi9mb28iKQorICAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgImVjaG8gJy9i aW4vZm9vJyIgIi9iaW4vZm9vIikpKQorCiAMCiA7OyBgY2QnCiAKZGlmZiAtLWdpdCBhL3Rl c3QvbGlzcC9lc2hlbGwvZXNoLWV4dC10ZXN0cy5lbCBiL3Rlc3QvbGlzcC9lc2hlbGwvZXNo LWV4dC10ZXN0cy5lbAppbmRleCA4YWJiZDc0ZjczNy4uYWFjMTNjM2Q4ZWEgMTAwNjQ0Ci0t LSBhL3Rlc3QvbGlzcC9lc2hlbGwvZXNoLWV4dC10ZXN0cy5lbAorKysgYi90ZXN0L2xpc3Av ZXNoZWxsL2VzaC1leHQtdGVzdHMuZWwKQEAgLTI3LDYgKzI3LDcgQEAKIChyZXF1aXJlICdl cnQpCiAocmVxdWlyZSAnZXNoLW1vZGUpCiAocmVxdWlyZSAnZXNoLWV4dCkKKyhyZXF1aXJl ICdlbS1kaXJzKQogKHJlcXVpcmUgJ2VzaGVsbCkKIAogKHJlcXVpcmUgJ2VzaGVsbC10ZXN0 cy1oZWxwZXJzCkBAIC03NCw2ICs3NSw0OCBAQCBlc2gtZXh0LXRlc3QvYWRkcGF0aC9zZXQt bG9jYWxseQogICAgICAoZXNoZWxsLW1hdGNoLWNvbW1hbmQtb3V0cHV0ICJlY2hvICRQQVRI IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjb25jYXQgb3JpZ2luYWwt cGF0aCAiXG4iKSkpKSkKIAorKGVydC1kZWZ0ZXN0IGVtLWV4dC10ZXN0L3VuZXhwYW5kLXJl bW90ZS1maWxlL2xvY2FsICgpCisgICJUZXN0IHVuZXhwYW5zaW9uIG9mIHJlbW90ZSBmaWxl IG5hbWVzIHdpdGggYSBsb2NhbCwgZXh0ZXJuYWwgY29tbWFuZC4iCisgIChza2lwLXVubGVz cyAoYW5kIChlc2hlbGwtdGVzdHMtcmVtb3RlLWFjY2Vzc2libGUtcCkKKyAgICAgICAgICAg ICAgICAgICAgKGV4ZWN1dGFibGUtZmluZCAiZWNobyIpKSkKKyAgKGxldCogKChkZWZhdWx0 LWRpcmVjdG9yeSBlcnQtcmVtb3RlLXRlbXBvcmFyeS1maWxlLWRpcmVjdG9yeSkKKyAgICAg ICAgIChyZW1vdGUgKGZpbGUtcmVtb3RlLXAgZGVmYXVsdC1kaXJlY3RvcnkpKSkKKyAgICAo bGV0ICgoZXNoZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1uYW1lcyB0KSkKKyAgICAgIChl c2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgIiplY2hvIC9iaW4vZm9vIiAiL2Jpbi9mb29c biIpCisgICAgICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsIChmb3JtYXQgIiplY2hv ICVzL2Jpbi9mb28iIHJlbW90ZSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIi9iaW4vZm9vXG4iKQorICAgICAgKHNob3VsZC1lcnJvciAoZXNoZWxsLWNvbW1hbmQt cmVzdWx0LWVxdWFsCisgICAgICAgICAgICAgICAgICAgICAiKmVjaG8gL3NzaDpub3doZXJl LmludmFsaWQ6L2Jpbi9mb28iCisgICAgICAgICAgICAgICAgICAgICAiL2Jpbi9mb29cbiIg dCkpKQorICAgIChsZXQgKChlc2hlbGwtY29ubmVjdGlvbi1sb2NhbC1maWxlLW5hbWVzIG5p bCkpCisgICAgICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsICIqZWNobyAvYmluL2Zv byIgIi9iaW4vZm9vXG4iKQorICAgICAgKGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbCAo Zm9ybWF0ICIqZWNobyAlcy9iaW4vZm9vIiByZW1vdGUpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChjb25jYXQgcmVtb3RlICIvYmluL2Zvb1xuIikpCisgICAgICAo ZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsCisgICAgICAgIiplY2hvIC9zc2g6bm93aGVy ZS5pbnZhbGlkOi9iaW4vZm9vIgorICAgICAgICIvc3NoOm5vd2hlcmUuaW52YWxpZDovYmlu L2Zvb1xuIikpKSkKKworKGVydC1kZWZ0ZXN0IGVtLWV4dC10ZXN0L3VuZXhwYW5kLWFic29s dXRlLWZpbGUvcmVtb3RlICgpCisgICJUZXN0IHVuZXhwYW5zaW9uIG9mIHJlbW90ZSBmaWxl IG5hbWVzIHdpdGggYSByZW1vdGUsIGV4dGVybmFsIGNvbW1hbmQuIgorICAoc2tpcC11bmxl c3MgKGFuZCAoZXNoZWxsLXRlc3RzLXJlbW90ZS1hY2Nlc3NpYmxlLXApCisgICAgICAgICAg ICAgICAgICAgIChleGVjdXRhYmxlLWZpbmQgImVjaG8iKSkpCisgIChsZXQqICgoZGVmYXVs dC1kaXJlY3RvcnkgZXJ0LXJlbW90ZS10ZW1wb3JhcnktZmlsZS1kaXJlY3RvcnkpCisgICAg ICAgICAocmVtb3RlIChmaWxlLXJlbW90ZS1wIGRlZmF1bHQtZGlyZWN0b3J5KSkpCisgICAg KGxldCAoKGVzaGVsbC1jb25uZWN0aW9uLWxvY2FsLWZpbGUtbmFtZXMgdCkpCisgICAgICAo ZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsICIqZWNobyAvYmluL2ZvbyIgIi9iaW4vZm9v XG4iKQorICAgICAgKGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbCAoZm9ybWF0ICIqZWNo byAlcy9iaW4vZm9vIiByZW1vdGUpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICIvYmluL2Zvb1xuIikKKyAgICAgIChzaG91bGQtZXJyb3IgKGVzaGVsbC1jb21tYW5k LXJlc3VsdC1lcXVhbAorICAgICAgICAgICAgICAgICAgICAgIiplY2hvIC9zc2g6bm93aGVy ZS5pbnZhbGlkOi9iaW4vZm9vIgorICAgICAgICAgICAgICAgICAgICAgIi9iaW4vZm9vXG4i IHQpKSkKKyAgICAobGV0ICgoZXNoZWxsLWNvbm5lY3Rpb24tbG9jYWwtZmlsZS1uYW1lcyBu aWwpKQorICAgICAgKGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbCAiKmVjaG8gL2Jpbi9m b28iICIvYmluL2Zvb1xuIikKKyAgICAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwg KGZvcm1hdCAiKmVjaG8gJXMvYmluL2ZvbyIgcmVtb3RlKQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAoY29uY2F0IHJlbW90ZSAiL2Jpbi9mb29cbiIpKQorICAgICAg KGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbAorICAgICAgICIqZWNobyAvc3NoOm5vd2hl cmUuaW52YWxpZDovYmluL2ZvbyIKKyAgICAgICAiL3NzaDpub3doZXJlLmludmFsaWQ6L2Jp bi9mb29cbiIpKSkpCisKIChlcnQtZGVmdGVzdCBlc2gtZXh0LXRlc3QvZXhwbGljaXRseS1y ZW1vdGUtY29tbWFuZCAoKQogICAiVGVzdCB0aGF0IGFuIGV4cGxpY2l0bHktcmVtb3RlIGNv bW1hbmQgaXMgcmVtb3RlIG5vIG1hdHRlciB0aGUgY3VycmVudCBkaXIuIgogICAoc2tpcC11 bmxlc3MgKGFuZCAoZXNoZWxsLXRlc3RzLXJlbW90ZS1hY2Nlc3NpYmxlLXApCmRpZmYgLS1n aXQgYS90ZXN0L2xpc3AvZXNoZWxsL2VzaGVsbC10ZXN0cy1oZWxwZXJzLmVsIGIvdGVzdC9s aXNwL2VzaGVsbC9lc2hlbGwtdGVzdHMtaGVscGVycy5lbAppbmRleCA2NTIxNDZmZWZjYy4u OWRiMTNjYzYxN2YgMTAwNjQ0Ci0tLSBhL3Rlc3QvbGlzcC9lc2hlbGwvZXNoZWxsLXRlc3Rz LWhlbHBlcnMuZWwKKysrIGIvdGVzdC9saXNwL2VzaGVsbC9lc2hlbGwtdGVzdHMtaGVscGVy cy5lbApAQCAtMTgwLDEzICsxODAsMTYgQEAgZXNoZWxsLWNvbW1hbmQtcmVzdWx0LS1lcXVh bC1leHBsYWluZXIKIChwdXQgJ2VzaGVsbC1jb21tYW5kLXJlc3VsdC0tZXF1YWwgJ2VydC1l eHBsYWluZXIKICAgICAgIydlc2hlbGwtY29tbWFuZC1yZXN1bHQtLWVxdWFsLWV4cGxhaW5l cikKIAotKGRlZnVuIGVzaGVsbC1jb21tYW5kLXJlc3VsdC1lcXVhbCAoY29tbWFuZCByZXN1 bHQpCi0gICJFeGVjdXRlIENPTU1BTkQgbm9uLWludGVyYWN0aXZlbHkgYW5kIGNvbXBhcmUg aXQgdG8gUkVTVUxULiIKKyhkZWZ1biBlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwgKGNv bW1hbmQgcmVzdWx0ICZvcHRpb25hbCBpZ25vcmUtZXJyb3JzKQorICAiRXhlY3V0ZSBDT01N QU5EIG5vbi1pbnRlcmFjdGl2ZWx5IGFuZCBjb21wYXJlIGl0IHRvIFJFU1VMVC4KK0lmIElH Tk9SRS1FUlJPUlMgaXMgbm9uLW5pbCwgaWdub3JlIGFueSBlcnJvcnMgc2lnbmFsZWQgd2hl bgoraW5zZXJ0aW5nIHRoZSBjb21tYW5kLiIKICAgKGVydC1pbmZvICgjJ2VzaGVsbC1nZXQt ZGVidWctbG9ncyA6cHJlZml4ICJDb21tYW5kIGxvZ3M6ICIpCi0gICAgKHNob3VsZCAoZXNo ZWxsLWNvbW1hbmQtcmVzdWx0LS1lcXVhbAotICAgICAgICAgICAgIGNvbW1hbmQKLSAgICAg ICAgICAgICAoZXNoZWxsLXRlc3QtY29tbWFuZC1yZXN1bHQgY29tbWFuZCkKLSAgICAgICAg ICAgICByZXN1bHQpKSkpCisgICAgKGxldCAoKGRlYnVnLW9uLWVycm9yIChhbmQgKG5vdCBp Z25vcmUtZXJyb3JzKSBkZWJ1Zy1vbi1lcnJvcikpKQorICAgICAgKHNob3VsZCAoZXNoZWxs LWNvbW1hbmQtcmVzdWx0LS1lcXVhbAorICAgICAgICAgICAgICAgY29tbWFuZAorICAgICAg ICAgICAgICAgKGVzaGVsbC10ZXN0LWNvbW1hbmQtcmVzdWx0IGNvbW1hbmQpCisgICAgICAg ICAgICAgICByZXN1bHQpKSkpKQogCiAocHJvdmlkZSAnZXNoZWxsLXRlc3RzLWhlbHBlcnMp CiAKLS0gCjIuMjUuMQoK --------------vuDo0Zym7x6wfKUFkl9ikDoF--
Jim Porter <jporterbugs@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#70792; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.