Re: Environment variables for remote processes

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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

Check again: these will not be present in "the difference between
process-environment and (default-toplevel-value 'process-environment)".

>> 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 whichever other scheme we end up using, removing env-vars shouldn't
be any harder than adding some.

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

I know that.  That's why I suggested to send "env <ENV> <CMD>".
Another option might be:

    (export VAR1=VAL1
     unset VAR2
     export VAR3=VAL3
     ...
     <CMD>)


-- Stefan