From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local process environments Date: Sat, 08 May 2021 19:51:18 +0200 Message-ID: <87wns9glm1.fsf@gmx.de> References: <87eeets6jf.fsf@gmail.com> <8735v99f4i.fsf@gmail.com> <87y2d1xada.fsf@gmx.de> <877dkkcjrj.fsf@gmail.com> <87tunoyzzd.fsf@gmx.de> <87eeerby1n.fsf@gmail.com> <87a6pfepo6.fsf@gmx.de> <874kflmzn3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35643"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier , emacs-devel@gnu.org To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 08 19:52:17 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lfR7f-00096Q-G3 for ged-emacs-devel@m.gmane-mx.org; Sat, 08 May 2021 19:52:15 +0200 Original-Received: from localhost ([::1]:51166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfR7e-0002B9-JY for ged-emacs-devel@m.gmane-mx.org; Sat, 08 May 2021 13:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfR6t-0001Qa-MM for emacs-devel@gnu.org; Sat, 08 May 2021 13:51:27 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:41481) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfR6r-0000Vx-H5 for emacs-devel@gnu.org; Sat, 08 May 2021 13:51:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1620496279; bh=aTxUMAixo7kOOpUBvE67h9xjsVNFQ7VZK5F8VAwCvXk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=IBRobtchvVJxhoK0OLGlxCeT6sFze8rXt6+227Q8g6oh4Ym5cBF5kQcGMYwjqeUlh DSuiWSzzCLY3WtV6OHkws/EDrrL5iE7D/NzEkZy4wSE2fMDeRnMVg+MJ3FxMemzuqi DbZI5P+u3L6K+juoii8zvB97gTzSHjM24INpIOQM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([79.140.118.236]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrhQC-1l9RoJ2CAe-00niUi; Sat, 08 May 2021 19:51:19 +0200 In-Reply-To: <874kflmzn3.fsf@gmail.com> (Augusto Stoffel's message of "Sun, 02 May 2021 08:13:36 +0200") X-Provags-ID: V03:K1:pguUxRKlZzsQIedsAy0mR41clTHKs6S++XVPWiHOeDkcR6WSEmZ Dnr2Hcr5k9N7LQ8s4f02CFco/isEG+ybUYIALPlui0W++O7GRhWTiM2q8b4SUHfQ2tldP2c B0oA7i/WzvUkyv6ELBWrJrpS8InJMonFLzXXBiMGpaFmYGwzcHOULiTCMBaYMFN6DCDC/XV tVi15Xgp9quQMvjJ9c/1g== X-UI-Out-Filterresults: notjunk:1;V03:K0:28LQ1GJoihA=:gTtPoYWMHsOU/Q/5XBOg1Y qJnc4Ib/IPTDbqspMiR+Ni6miFXMigJWhWw/wEp0xFwup3sgxm2YjaR1jAnIocTT1ayncivNO D+npAwsal6SPqveehgzTecH3xe85Z1SAVaESnMkeJo5TwK6ySdWRHKhWBYo98jjVqtHxADMUJ 03rTkks2uEBzWhqO2IRvkyyZ4HWiEA6pswIBjScMRlsVxOA+lg4RHaCb4X7D+AD9kTYpgVnL8 Y8Zm4B9mnnVeAr+Lnautqe4DdW7YMyEhg/wRpV9FI2VcJcDjkQeWkyAqR0URba0eo9QSwu/a9 55n3xY817j0AeqkUrV1OT48OG4tMXJ5aJWY2IIZx1OUtGhKy44XiDY1UdYjtTrpXbP9cZAlWE p1Hwd/cXGwigVI7DK50apxeqrbFQEbz6vlQidI33AvWnrAYhd74zIdX/e8p5oENmmc63ivL2v k6tGEueiWrUU/qrAVbrxjb8S4zsmLpc9OWgSdX8PzT1vyRo5Ei9vWWXeYs3cU7spycwvQKB0c qLffeKifdgdF5oQ61wUdw9c+HhVjLyio3+YPLPFO9p+p0iBruYSeKEXhDtZmFZkTIYUOaPDA3 LmQ4cPThC4WN1MfuNDeazOlQ/RrfaCbonUSTcOagRw2jzQoHwZSXs+CLxjEQqlHY2tbbOpEAX Odm83vaM1RonA4euTwmudgrOwWacO1Wre0bpYLOMfZVmHv4NphFqNsYPzqMAeVinp0Qk/6WdC mwyIloQ27faKQLtT21peUNI0otvesAzLA1wNiNuUR8oj7LViLJEuHdr4JQRY2WOnGt6b+g74 Received-SPF: pass client-ip=212.227.17.20; envelope-from=michael.albinus@gmx.de; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269062 Archived-At: Augusto Stoffel writes: > Hi Michael, Hi Augusto, > I can only think of two alternatives: > > 1. Introduce a whitelist of variables that can be exported to a remote. > Then drop entirely the current hack and just check whether > `process-environment' contains any exportable variables. For > flexibility, you can allow whitelisting a variable name (any value), > or a specific VAR=VALUE pair. > > The whitelist can be set globally or dynamically. So, for instance, > the vc files could just append "BZR_LOG", "HGPLAIN" and whatnot > globally to this list and never worry again. > > Obviously, this will break third-party code, but the fix is quite > easy. Nobody could bash you for that. We have already a white list, which is tramp-remote-process-environment. I'm reluctant to add package specific entries there by default, it would be an endless story. PAGER is included as being a general purpose environment variable, BZR_LOG and HGPLAIN are not. If packages believe they shall be added, this could be done in vc-bzr.el or vc-hg.el. Tramp is a stupid library, it shouldn't try to be clever. > 2. Introduce a blacklist of variables that are never exported to a > remote. This can be done by extending > `tramp-remote-process-environment' to follow the same convention of > `process-environment' that an entry of the form VAR, without the > =VALUE, means removing the variable. There are already such variables to be unset. These are the variables without any value, like "HISTORY=" > So, for instance, entries "PATH" and "TERM" should be added to the > default value of `tramp-remote-process-environment'. This would > solve the unintuitive (if not buggy) behavior I pointed out a few > messages back in this thread. TERM is handled special. All Tramp connections add "TERM=dumb", hard-coded. Since this shall not be changed by a user, it isn't configurable here. PATH is handled by tramp-remote-path. This is a variable on its own, because just setting a simple string "PATH=/abc:/def" isn't sufficient, often. > As another example, python.el would append "PYTHONPATH" and > "PYTHONHOME" globally to `tramp-remote-process-environment', since > these variables hold directory names. Yes, if python.el developers prefer that. However, I doubt, that this value is always the same for all different remote hosts, the value might differ depending on the OS the remote host is running. > This option is fully backwards compatible, but keeps the hack you > said you don't like anyway. So in fact, this solution is almost the current implementation. > It's also conceivable do to both things, but instead of enforcing 1., > just give a warning. Then eventually you could get rid of the hack > without breaking other packages. As said, variant 1. isn't applicable in my eyes. Best regards, Michael.