Re: Environment variables for remote processes

[Stefan Monnier]

> But then you change the definition of process-environment.  The docstring
> says "let-binding `process-environment' is an easy way to temporarily
> change the value of an environment variable".  It does not say it should
> be the only way to do that, especially for process-file.

What other way do you have in mind?

If you just use straight `setq' this will affect all subsequent
executions of subprocesses, so it only makes sense for env settings
which are not specific for one particular subprocess.

Of course, you could use

     (setq process-environment <foo1>)
     ...
     (setq process-environment <revert>)

but that's quite less convenient and efficient than using `let', so I'm
not worried if we don't handle that case.

> And you still have the distinction between processes on the local host,
> and processes on the remote host.  The former ones can expect all
> settings from process-environment, the latter ones can expect only the
> environment vatriables which are different to the toplevel value.

That's right.

> Up to now, nobody had to care about processes running locally or
> remote; process-file did arrange it magically.

That's not true: vc-hg.el now even has to test file-remote-p to decide
which command to run, specifically because process-file does not arrange
it magically.
Currently, process-file simply ignores process-environment, which works
OK in some cases but is clearly not quite right.

> Nitpicking: there is no clean way to remove an environment variable,
> which might have been set remotely and which you do not want to have
> set while executing process-file.

Actually, C-h v process-environment says:

   irrespective of where it comes from.  To use `process-environment' to
   remove an environment variable, include only its name in the list,
   without "=VALUE".


-- Stefan