From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not recognized as an internal or external command... Date: Mon, 28 Aug 2023 11:01:13 -0700 Message-ID: <0dcc88be-6326-f1d8-9dbc-e2bce7b8fc64@gmail.com> References: <861qfpnb9y.fsf@gmx.com> <87sf84s7bf.fsf@gmx.de> <3792bc23-2bad-8262-c674-26cec9d47b65@gmail.com> <877cpf31hs.fsf@gmx.de> <3e1db580-d1b3-1c96-ad3c-ba6e95eca8a3@gmail.com> <87il8zul5h.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16565"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jordan Wilson , 65551@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 28 20:02:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qagZ3-00045Y-4o for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Aug 2023 20:02:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qagYq-0004JN-NH; Mon, 28 Aug 2023 14:02:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qagYm-0004GO-BX for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 14:01:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qagYl-00083o-RZ for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 14:01:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qagYr-000288-Vd for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 14:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Aug 2023 18:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65551 X-GNU-PR-Package: emacs Original-Received: via spool by 65551-submit@debbugs.gnu.org id=B65551.16932456868134 (code B ref 65551); Mon, 28 Aug 2023 18:02:01 +0000 Original-Received: (at 65551) by debbugs.gnu.org; 28 Aug 2023 18:01:26 +0000 Original-Received: from localhost ([127.0.0.1]:49018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qagYI-000277-7V for submit@debbugs.gnu.org; Mon, 28 Aug 2023 14:01:26 -0400 Original-Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]:50639) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qagYG-00026r-IF for 65551@debbugs.gnu.org; Mon, 28 Aug 2023 14:01:25 -0400 Original-Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1c09673b006so16423045ad.1 for <65551@debbugs.gnu.org>; Mon, 28 Aug 2023 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693245672; x=1693850472; 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=fr7ksk7or0pILXV2dSLKAwfHsuidtFUx6YDsBD+uqdg=; b=mMIedxuec5Cr93tcsD0ApEDBIs+TMdrGWrgdWu9XbuqMZRRCmmc91frUTvDuWcKN0Y LT6OjtvSCp7GyVjdu3RaGPja50FGK3e6c3UgWuMCNgvHVdluuLZP9VXXfoIMvaqXtOuP sJOJ6uVqiQ7s2zMf3IkWgs/pi5WomqGHuU76OTZFbkIbDes6smMBimQ3WUQ6Ap++2xCt LnHEW4ON3uwy9LW/ZGW3IuxHQ0D1Wa7qPmKrPlqKL04LCynlhFeWh0eo8MxuRJm8wUhw Z+ZDjAB5aV1wqOQFn0OS/Nk1etlluItytxBwpD8r608VuBneiOGgJdDN9v5witJQzOHU S14g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693245672; x=1693850472; 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=fr7ksk7or0pILXV2dSLKAwfHsuidtFUx6YDsBD+uqdg=; b=QuVB07ryXEgePU96sEVE23LIKNa0mSlglLLws1TREdiBsj9FqCPO3D9uDMSFNpElq9 quQES4KeOS7nfXhupdUYDd/6OYc6ty3xZ3Y05SQelb4ffXASjm6LnU8KGac//l8WNkNK XDXZ7/f3KcAf1gP0cpHzKs2U1iS1BVACPlpXMkR6+TWL1dzs42DNOclgYBAcjp6JKgnj LhrO5pOWp2dozKGEQycE4k9jTN6smILkxqTu8AdBgQO8ALfTmejP8vxxLXCtchoBmq77 N0JbGGty952+cIqQQb2H/S2tmQph66TYDexKauk71jm1m9eGrXKIPApCwbwPGxxIOlL/ r3XQ== X-Gm-Message-State: AOJu0YzpdFl2+fmnQsSS+81cbNabaqKn5Mq2uhZtOsPe1HAVqZ1Pe4EN sK8lCpySVGnlsYkrqAK6uuI= X-Google-Smtp-Source: AGHT+IEPL4nl2ydsJvgzkY1Zz4QUtodYw0wCS4xzJloqkyUkRqi/QXmWK6X/EcNJN64IftK59jz4lw== X-Received: by 2002:a17:902:c1c4:b0:1bc:73bf:304c with SMTP id c4-20020a170902c1c400b001bc73bf304cmr20887188plc.48.1693245671941; Mon, 28 Aug 2023 11:01:11 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id iy20-20020a170903131400b001b89466a5f4sm7679138plb.105.2023.08.28.11.01.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Aug 2023 11:01:11 -0700 (PDT) Content-Language: en-US In-Reply-To: <87il8zul5h.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268649 Archived-At: On 8/28/2023 10:33 AM, Michael Albinus wrote: > tramp-remote-path is just a template, It is taken the very first time > you connect to a remote host in order to determine proper PATH > settings. The result is cached in the connection property "remote-path". Yeah, I believe this result is where we get the starting value for PATH for remote hosts. If we don't already have a cached PATH for the remote host in Eshell, we get it by calling '(exec-path)', which I'm guessing uses tramp-remote-path (at least indirectly). > If a user changes PATH for a remote connection in eshell (I don't recall > how, but I'm sure it is possible in Eshell), you just have to change the > respective connection property "remote-path" in Tramp. > See (info "(tramp) Predefined connection information") Changing the PATH is pretty simple: just run "export PATH=blah" or "set PATH blah". > There is an exception: If a user has the symbol tramp-own-remote-path > in tramp-remote-path, the cached value is not used for a new process, > and PATH is recomputed based on tramp-remote-path. I think we want to handle this case too: for example, I use 'tramp-own-remote-path' so that I can pick up my remote hosts' PATH values, but then I might want to change that value in Eshell later. If Eshell let-binds and sets 'tramp-remote-path' when starting the remote process, it can override the 'tramp-own-remote-path' setting temporarily, which I think is what we want. We'd lose the ability for Tramp to recompute the remote PATH on its own, but in the context of Eshell I think that should be ok. > Writing this, it sounds to me too complex. OTOH, no other package has > tried yet to play with the remote PATH. There are bug reports by users > who request a simplification (bug#61926, bug#62326). Perhaps it is time > to redesign the machinery in Tramp. Yeah, this is pretty tricky code to work with on both sides (both Tramp/remote connections and Eshell). One option that might make sense is if we could pass the environment vars for the subprocess as a key in 'make-process', like ':env'. That would let us make sure that the env vars are only used exactly where we want them. For the Eshell side, I think this bug has shown that it's time to review how it handles environment variables in general for remote hosts. Another interesting bug is how we set PWD and OLDPWD to Tramp filenames on remote hosts. When running an external process on that host, we should probably use the local file name instead, since non-Emacs programs won't understand our remote file syntax. I'm sure there are other bugs besides that too. Maybe the default behavior for env vars is that they should be connection-local (so remote hosts don't see your env vars), and then we can opt into passing certain special vars (like TERM) to all remote hosts. I'll think about this some more and file a bug when I have something more concrete.