[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thomas F. Burdick
02 Oct 2001 13:28:25 -0700
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.105
address@hidden (Miles Bader) writes:
> "Stefan Monnier" <monnier+gnu.emacs.bug/news/@RUM.cs.yale.edu> writes:
> > but changing the behavior of `setenv' would be 100% backward
> > compatible so there really doesn't seem to be any good reason not to
> > do it.
> The point is to avoid people thinking that setenv is somehow special,
> and `better' than modifying process-environment, since it's often worse
> from a programming point of view.
In that case, I have a bug to report in the Elisp manual. The node
"System environment" says:
- Command: setenv VARIABLE VALUE
This command sets the value of the environment variable named
VARIABLE to VALUE. Both arguments should be strings. This
function works by modifying `process-environment'; binding that
variable with `let' is also reasonable practice.
- Variable: process-environment
This variable is a list of strings, each describing one environment
variable. The functions `getenv' and `setenv' work by means of
One thing it doesn't specify is what happens if I do:
ELISP> (let ((process-environment (cons
;; what's the value of HOSTNAME here?
The intuitive behavior is for process-environment to work like an
alist; this is confirmed by checking with `getenv'. However, when the
behind-the-scenes syncing happens, does it do
(mapc #'fix-in-C-env process-environment)
(mapc #'fix-in-C-env (remove-duplicates process-environment ...))
That entries earlier in the list supersede the later entries should be