Re: Environment variables for remote processes

[Stefan Monnier]

> 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.

Not sure what you mean by "before Tramp connection".  The issue is what
environment to give to the command run via `process-file'.
Whether there's a pre-existing Tramp connection or not is an
implementation detail of Tramp.  But the semantics of `process-file' is
clearly that it should receive in its environment the things that are in
`process-environment', and currently Tramp fails to obey this part of
the semantics of `process-file'.

Of course, it wouldn't be correct to inherit the whole of
`process-environment' either.  And of course, I understand that
implementing this environment handling might take more than a quick
half-hour hack.

> 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.

No, the particular time at which the Tramp connection was made shouldn't
make any appreciable difference.

> (let ((process-environment process-environment))
>   (setenv "DISPLAY")
>   (process-file ...))

In my naive mental model, Tramp's implementation of `process-file' will
run "env <ENVVARS> <COMMAND>" on the remote host, so we could use "-u"
to remove elements from the environment.

But let's start by handling additions, and then we'll see if/when we need to
handle removals.

>>> 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.

So it does seem like a completely different issue.  What I'm concerned
here is about the environment that is "per subprocess" rather than "per
connection".


        Stefan