[Top][All Lists]

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

bug#10980: GNU bugs information: logs for bug#10980

From: Noam Postavsky
Subject: bug#10980: GNU bugs information: logs for bug#10980
Date: Wed, 29 Jun 2016 19:02:25 -0400

On Wed, Jun 29, 2016 at 11:34 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Noam Postavsky <address@hidden>
>> Date: Wed, 29 Jun 2016 11:26:04 -0400
>> Cc: address@hidden, address@hidden
>> >> But it seems we would then need 2 sets of functions: getenv/setenv and
>> >> get-subproc-env/set-subproc-env (the latter working on
>> >> Vprocess_environment only). This feels like a complication with not
>> >> much benefit.
>> >
>> > We already have that: there's 'getenv' and 'egetenv' on the C level.
>> > And the Lisp 'setenv' is already documented to modify
>> > process-environment.  So I'm not sure I see the problem
>> What about a lisp program that expects (expand-file-name "~") and
>> (getenv "HOME") to give the same results after running (setenv "HOME"
>> <whatever>)
> The changes in getenv_internal_1 (or, rather, in getenv_internal) that
> I mentioned will have to make that happen.  It already does something
> similar.

Ah, I think I missed the idea that changing Vprocess_environment would
still affect Emacs' environment (technically, what Emacs thinks its
environment is, which has the same effect). Patch attached.

Attachment: v2-0001-Keep-w32-environment-settings-internal-only.patch
Description: Binary data

reply via email to

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