Re: Is set-environment-variable needed after all? Lassi Kortela 09 Dec 2019 19:45 UTC
> Capture the value of $EDITOR (actually you are supposed to look at > $VISUAL first, and if it is undefined then look at $EDITOR) in a > variable of the (ed) library. Then just use that variable henceforth. > You can expose a set-editor! procedure to change it. Then (get-environment-variable "EDITOR") and (get-editor) would needlessly produce different results if the editor has been changed. And any subprocess would get the old EDITOR again unless you use a :environment alist as a third mechanism for changing the same thing. > The above ideas avoid this. If your program doesn't change any > environment variables, use get-environment-variable freely. If it does, > capture the whole environment early in a global variable as an alist, > search it with assoc, push things on the alist as you will, and pass it > to all calls to spawn-process. There are pros and cons to that approach. > (I have updated ProcessesCowan to make it > clear that if the same key appears more than once, the first value is > put into the environment by spawn-process.) This is good to specify. > Not just that, but because putenv() can be used for dynamic binding > without leaks, as I explained. I wonder how many people understand that. That API is not for the faint of heart. > We could also write a separate SRFI as a follow-up to SFI 98 with just > set-environment-variable! and delete-environment-variable! :) As was > done with the timespec SRFI. > > They are Posix but not C, so if they belong anywhere at all (and I think > they don't), it's in the Posix SRFI. WinAPI also has procedures to get and set them, as do most other OSes probably.