From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Environment variables for remote processes Date: Wed, 19 Nov 2014 23:29:58 -0500 Message-ID: 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> <87h9xwdvxx.fsf@gmx.de> <87egsz3vhc.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416457850 5915 80.91.229.3 (20 Nov 2014 04:30:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2014 04:30:50 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, dpittman@fb.com To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 20 05:30:43 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 1XrJOD-0000M5-7R for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 05:30:41 +0100 Original-Received: from localhost ([::1]:33509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrJOC-00068g-Nw for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 23:30:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrJNm-00067T-72 for emacs-devel@gnu.org; Wed, 19 Nov 2014 23:30:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrJNe-00031g-OG for emacs-devel@gnu.org; Wed, 19 Nov 2014 23:30:14 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:47745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrJNe-00030X-Jc; Wed, 19 Nov 2014 23:30:06 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id sAK4Tx0c025101; Wed, 19 Nov 2014 23:29:59 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id EECFC3D01; Wed, 19 Nov 2014 23:29:58 -0500 (EST) In-Reply-To: <87egsz3vhc.fsf@gmx.de> (Michael Albinus's message of "Wed, 19 Nov 2014 19:18:07 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5130=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5130> : inlines <1546> : streams <1345469> : uri <1835378> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:177852 Archived-At: > But then you change the definition of process-environment. The docstring > says "let-binding `process-environment' is an easy way to temporarily > change the value of an environment variable". It does not say it should > be the only way to do that, especially for process-file. What other way do you have in mind? If you just use straight `setq' this will affect all subsequent executions of subprocesses, so it only makes sense for env settings which are not specific for one particular subprocess. Of course, you could use (setq process-environment ) ... (setq process-environment ) but that's quite less convenient and efficient than using `let', so I'm not worried if we don't handle that case. > And you still have the distinction between processes on the local host, > and processes on the remote host. The former ones can expect all > settings from process-environment, the latter ones can expect only the > environment vatriables which are different to the toplevel value. That's right. > Up to now, nobody had to care about processes running locally or > remote; process-file did arrange it magically. That's not true: vc-hg.el now even has to test file-remote-p to decide which command to run, specifically because process-file does not arrange it magically. Currently, process-file simply ignores process-environment, which works OK in some cases but is clearly not quite right. > Nitpicking: there is no clean way to remove an environment variable, > which might have been set remotely and which you do not want to have > set while executing process-file. Actually, C-h v process-environment says: irrespective of where it comes from. To use `process-environment' to remove an environment variable, include only its name in the list, without "=VALUE". -- Stefan