Re: setenv

[Thomas F. Burdick]

rms@gnu.org (Richard Stallman) writes:

> >  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).
>
>   Unfortunately, option 3 depends on intimate knowledge of the library
>   internals, and might mean you will need ugly system-dependent code
>   that potentially needs to be changed when new versions of the
>   libraries are released on each system.

Now that I think about it a little more, I think I like option (4) best:

  (4) getenv and setenv both work on process-environment as they do
      now, but before returning, ensure that Emacs' actual environment
      reflects the content of this variable.  This will allow the
      Elisp user to modify Emacs' own actual environment, won't
      require any special knowledge of the system, and won't break any
      existing code that may modify process-environment directly.

Maybe they could both effect the process-environment => actual
environment synchronization through a thrid function,
`synchronize-environment' or some such, in case the user wanted to do
something like:

(let ((process-environment (remove-if
                             #'(lambda (string)
                                 (let* ((s "DISPLAY")
                                        (l (length s)))
                                   (string= s (substring string 0 l))))
                             process-environment)))
  (sychronize-environment)
  (do-something-without-x))

without needing a bogus call to getenv.

> In theory, we would need intimate knowledge.  In practice, I think we
> don't.  There are just a few parts of Emacs that do anything so
> complex it might fork a process without Emacs's knowledge.

I don't know that forking is really the issue.  More, it's the
behavior of libraries linked into Emacs.  Unless the Emacs developers
want to keep super-careful watch over any possible points when any of
these could look at the environment, for all possible versions of
these libraries, it will almost certainly create a problem.  And even
if the Emacs developers wanted to do this, it seems like it makes it
more difficult than it needs to be to link Emacs to another library.