From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: Environment variables for remote processes Date: Tue, 18 Nov 2014 22:45:46 +0100 Message-ID: <87h9xwdvxx.fsf@gmx.de> References: <030C5AEB-C009-4995-B153-6EECD44802C8@fb.com> <87y4rkhdt6.fsf@gmx.de> <87y4rf2jtx.fsf@gmx.de> <87r3x6eq8w.fsf@gmx.de> <87mw7rtnxg.fsf@gmx.de> <83a93rduz4.fsf@gnu.org> <87h9xxvf31.fsf_-_@gmx.de> <87mw7oe2y3.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416347196 14982 80.91.229.3 (18 Nov 2014 21:46:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 21:46:36 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, dpittman@fb.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 22:46:28 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqqbS-0008BA-6L for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 22:46:26 +0100 Original-Received: from localhost ([::1]:55562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqqbR-0002eE-RF for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 16:46:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqqb7-0002dx-Ah for emacs-devel@gnu.org; Tue, 18 Nov 2014 16:46:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xqqb1-0002qU-E9 for emacs-devel@gnu.org; Tue, 18 Nov 2014 16:46:05 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:63405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqqau-0002nu-Uu; Tue, 18 Nov 2014 16:45:53 -0500 Original-Received: from detlef.gmx.de ([79.195.18.210]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mgc0l-1XdyBA2sAZ-00O1zw; Tue, 18 Nov 2014 22:45:47 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 18 Nov 2014 16:24:11 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:ExIw/HhVALxKlSVeaAQ/PacF8e3ONc/q4AA37mM9vG2E2NWDyxs G3vjFkREPkSY+wau92FVIPUXA1BT6t2NW7a/8dVrAsrQKQJQx+XYPRHjloKNhIXmyuF0xUJ 6AG9iTRd7/3RCVspekPexZbh4e/gLt4kG934SuiMRELfN5J4HAyJuPNRJDrBBSIOQ2Pwlse Tth/4GdkuctYS0GV19ijw== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177670 Archived-At: Stefan Monnier writes: > Not sure what you mean by "before Tramp connection". The issue is what > environment to give to the command run via `process-file'. > Whether there's a pre-existing Tramp connection or not is an > implementation detail of Tramp. But the semantics of `process-file' is > clearly that it should receive in its environment the things that are in > `process-environment', and currently Tramp fails to obey this part of > the semantics of `process-file'. > > Of course, it wouldn't be correct to inherit the whole of > `process-environment' either. And of course, I understand that > implementing this environment handling might take more than a quick > half-hour hack. It's not so simple to decide what's appropriate settings. You do NOT want to propagate all your local environment variables to the remote process. Your local settings of DISPLAY or DBUS_SESSION_BUS_ADDRESS, to give prominent examples, would confuse your remote process heavily. And there might be application specific environment variables we've never heard about, which could damage the remote process as well. How to decide what's appropriate for the remote process? I don't know. > In my naive mental model, Tramp's implementation of `process-file' will > run "env " on the remote host, so we could use "-u" > to remove elements from the environment. No. With a sufficient amount of environment variables, you would exceed the maximum length of shell command lines. Tramp did it several times already, and I had to work-around that. Then "env ..." construct is applicable only, when you know in advance that there aren't too many settings. > But let's start by handling additions, and then we'll see if/when we need to > handle removals. > >>>> Furthermore, some remote settings might be requested which are not in >>>> process-environment by default. >>> Not sure what you're referring to here, but it seems like a different >>> issue than the one at hand (which is to propagate let-bound >>> process-environment values). >> I'm speaking about tramp-remote-process-environment, which uses another >> mechanism. But if we have an accepted mechanism for environment >> variables on remote hosts, there shall be only The One Way to set them. > > So it does seem like a completely different issue. What I'm concerned > here is about the environment that is "per subprocess" rather than "per > connection". Yes, but here we must speak about implementation. Tramp opens a connection (a shell) on the remote host, and sends all its internal commands via this shell. It sends also the command intended for process-file to that shell. It does *not* open a new (sub)process, which could inherit environment variables from Emacs, and alike. The environment is the same as when that shell has been started. That's why it is, at least as of today, "per connection". > Stefan Best regards, Michael.