From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.bugs Subject: bug#6401: Date: Tue, 22 Nov 2011 17:15:48 -0500 Message-ID: References: <3ECA75E7-611F-4D2A-B6B9-C0FEC96D1070@hofland.no> <822479C3-8B02-4BD7-AB56-C5D7DD31D9D6@tenkan.org> <2cmxboiol1.fsf@fencepost.gnu.org> <4taa7o9hpy.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1322000211 25968 80.91.229.12 (22 Nov 2011 22:16:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 Nov 2011 22:16:51 +0000 (UTC) To: 6401@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 22 23:16:45 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RSydx-0005bR-Jw for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Nov 2011 23:16:45 +0100 Original-Received: from localhost ([::1]:46958 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSydx-0006Vg-5U for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Nov 2011 17:16:45 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:45973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSydt-0006Pk-N8 for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2011 17:16:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSyds-0007g8-Dt for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2011 17:16:41 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSyds-0007g4-BP for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2011 17:16:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RSyfB-0006kb-UO for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2011 17:18:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <3ECA75E7-611F-4D2A-B6B9-C0FEC96D1070@hofland.no> Resent-From: Glenn Morris Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Nov 2011 22:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6401 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6401-submit@debbugs.gnu.org id=B6401.132200023425886 (code B ref 6401); Tue, 22 Nov 2011 22:18:01 +0000 Original-Received: (at 6401) by debbugs.gnu.org; 22 Nov 2011 22:17:14 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSyeP-0006jT-Lw for submit@debbugs.gnu.org; Tue, 22 Nov 2011 17:17:14 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSyeN-0006jM-In for 6401@debbugs.gnu.org; Tue, 22 Nov 2011 17:17:12 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RSyd3-0004Cb-Aa; Tue, 22 Nov 2011 17:15:49 -0500 X-Spook: red noise emc cryptanalysis Majic mania propaganda X-Ran: wP6CCaZ3k3>C?CE&&G].CA/*gUs'HVD*2d List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54185 Archived-At: Glenn Morris wrote: > To be clear, I'm asking why ns_init_paths needs to do this kind of thing: > > if (!getenv ("EMACSDATA")) > setenv ("EMACSDATA", [resourcePath UTF8String], 1); IIUC, what's going on is: The NS build can be made as some kind of relocatable "app bundle" where paths to the doc file etc are not set during the build, but are figured out at runtime. So there needs to be special NS-specific code to initialize Vdata_directory etc. Rather than do this directly, the method adopted is to call ns_init_paths early on in startup, to set environment variables EMACSDATA etc. init_callproc_1 then uses these to initialize Vdata_directory etc. After this point, the environment variables hang around affecting all sub-processes started by Emacs for no good reason. I imagine the NS build could unset these environment variables, if it set them itself, after initialization is complete. Or an NS-specific init_callproc_1 would seem less clunky to me. I also note that nsterm.m is still setting INFOPATH whereas w32.c has stopped doing that. The complete list is internal variables: Vexec_path, Vdata_directory, Vdoc_directory, Vload_path, Info-directory-list being set via env-vars: EMACSPATH, EMACSDATA, EMACSDOC, EMACSLOADPATH, INFOPATH