Re: Environment variables for remote processes

[Michael Albinus]

Stefan Monnier <address@hidden> writes:

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

It's not so simple to decide what's appropriate settings. You do NOT
want to propagate all your local environment variables to the remote
process. Your local settings of DISPLAY or DBUS_SESSION_BUS_ADDRESS, to
give prominent examples, would confuse your remote process heavily.

And there might be application specific environment variables we've
never heard about, which could damage the remote process as well.

How to decide what's appropriate for the remote process? I don't know.

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

No. With a sufficient amount of environment variables, you would exceed
the maximum length of shell command lines. Tramp did it several times
already, and I had to work-around that. Then "env ..." construct is
applicable only, when you know in advance that there aren't too many settings.

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

Yes, but here we must speak about implementation. Tramp opens a
connection (a shell) on the remote host, and sends all its internal
commands via this shell. It sends also the command intended for
process-file to that shell. It does *not* open a new (sub)process, which
could inherit environment variables from Emacs, and alike. The
environment is the same as when that shell has been started. That's why
it is, at least as of today, "per connection".

>         Stefan

Best regards, Michael.