bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setenv


From: Thomas F. Burdick
Subject: Re: setenv
Date: Thu, 20 Sep 2001 13:28:13 -0700

Andreas Schwab writes:
 > tfb@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
 > 
 > |> In Emacs 20 (and 21), setenv modifies process-environment.  But it's
 > |> named after a C function that affects the current process, not just
 > |> child processes.  While it's documented as such, I think it's a
 > |> misfeature because its name implies other behavior (that it acts like
 > |> the C function of the same name).  This also means there's no way to
 > |> affect the environment of the currently running Emacs from Elisp.
 > |> 
 > |> My solution: getenv should be renamed to get-environment, setenv
 > |> renamed to set-environment, and getenv and setenv changed to behave as
 > |> their C namesakes.
 > 
 > In which way would get/setenv be different from get/set-environment from
 > the Lisp programmer's point of view?  AFAIK there is no way to directly
 > access the environment of the Emacs process.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]