Re: setenv

[Miles Bader]

"Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> writes:
> While the Emacs sources know about process-environment, the libraries
> it's linked to don't.  xlib, for example.  So imagine code like the
> following to make a new frame on a forwarding X server set up by sshd:
> 
> (setenv "XAUTHORITY" (find-xauthority-for-display ":10.0"))
> (make-frame-on-display ":10.0")
> 
> it will fail (and crash Emacs as an extra benefit), because from
> xlib's point of view, setenv is a no-op.  I can't think of any
> Emacs21-specific examples off the top of my head, but as more
> libraries get added, the chance of another something like this popping
> up can only increase.

I can see three obvious ways around this problem:

 1) Have every call to elisp's `setenv' update the real environment as
    well as `process-environment'; this seems not good because we want
    calls to `setenv' to be no different than simply modifying the
    variable `process-environment'.

 2) As was suggested earlier, rename the existing elisp `setenv', and
    add a new elisp `setenv' that directly updates the real environment.
    This seems bad because it then requires the _users_ to know about
    two sorts of environments, and when they should use one and when the
    other.

 3) Making any emacs primitives that call such `environment grokking'
    library functions propagate any related enviroment variables from
    `process-environment' into the real environment when needed.  This
    requires the affected primitives to know when such action is needed,
    but this is no more burden than that of option (2), and it has the
    big advantage of putting the onus on the emacs developers rather
    than on the users!

As you can see, I like option (3).

-Miles
-- 
Run away!  Run away!