[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Environment variables for remote processes
From: |
Stefan Monnier |
Subject: |
Re: Environment variables for remote processes |
Date: |
Tue, 18 Nov 2014 16:24:11 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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
- Environment variables for remote processes (was: bug#18940: 24.4; vc-hg does not disable pager, leading to hangs (at least with tramp)), Michael Albinus, 2014/11/17
- Re: Environment variables for remote processes, Stefan Monnier, 2014/11/17
- Re: Environment variables for remote processes, Michael Albinus, 2014/11/18
- Re: Environment variables for remote processes, Michael Albinus, 2014/11/19
- Re: Environment variables for remote processes, Michael Albinus, 2014/11/19
- Re: Environment variables for remote processes, Stefan Monnier, 2014/11/19
- Re: Environment variables for remote processes, Michael Albinus, 2014/11/20
- Re: Environment variables for remote processes, Stefan Monnier, 2014/11/20
- Re: Environment variables for remote processes, Michael Albinus, 2014/11/22