Re: Environment variables for remote processes

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> The problem is, that not all settings of process-environment might be
>> desired on remote hosts. process-environment keeps *local* variables.
>
> I'm not so sure.  We're talking here about the settings which are in 
> process-environment but not in (default-toplevel-value
> 'process-environment), so these are all settings added via let-binding
> process-environment, and in all the cases I can think of, these seem to
> be either useful or harmless to propagate.

That sounds terrible: two classes of citizens in
process-environment. Some of them being there before Tramp connection
happened, and some of them added later, via let-bind or permanently.

How do you want to explain the difference to a user? It would make a
difference, whether an entry has been added to process-environment
before a Tramp connection, or afterwards.

And how would you deal with deleted entries of process-environment?
Something like

(let ((process-environment process-environment))
  (setenv "DISPLAY")
  (process-file ...))
  
>> Furthermore, some remote settings might be requested which are not in
>> process-environment by default.
>
> Not sure what you're referring to here, but it seems like a different
> issue than the one at hand (which is to propagate let-bound
> process-environment values).

I'm speaking about tramp-remote-process-environment, which uses another
mechanism. But if we have an accepted mechanism for environment
variables on remote hosts, there shall be only The One Way to set them.

>         Stefan

Best regards, Michael.