bug#6401:

[Glenn Morris]

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