Subject: bug#23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match)

From: Jerry Asher <[email-masked]>
Date: Sat, 2 Apr 2016 13:19:01 -0700

> If the OP answers the question, we might be on a more constructive
path.

You asked for:

> What is the full contents of the environment of the Emacs process when
you run that zapped binary?

My full environment contains a lot of internal information with private
data with security implications

+ current directories
+ current projects
+ complete pathnames to various executables
+ firefox plugins
+ firefox plugin directory paths
+ windows directory paths
+ paths to ssh keys
+ complete specification of the windows image I am running

You do not need my full environment, nor would more than a few people give
it.

And my full environment is not sufficient either.  You need a knowledge of
windows programming.
I cannot supply that. If you cannot, say so.

Jerry

On Sat, Apr 2, 2016 at 1:02 PM, Eli Zaretskii <[email-masked]> wrote:

> > From: Michael Albinus <[email-masked]>
> > Date: Sat, 02 Apr 2016 21:47:48 +0200
> > Cc: [email-masked]
> >
> > If you are interested in changing Tramp according to your needs, pls be
> > cooperative. Make a proposal about a config option which could be used
> > instead of the COMSPEC env which doesn't exist in your environment. Make
> > a proposal how to avoid calling cmd.exe at all, it seems not be
> > mandatory, I believe. Propose something else what is possible.
> >
> > Your first proposal, trusting C:\Windows\system32\cmd.exe, hasn't been
> > accepted, by reasons Eli has given. And indeed, it looks too me like too
> > much heuristic, so I'm with Eli.
>
> I asked a question which might suggest a solution.  The idea is that
> if we cannot trust COMSPEC, then we had better made sure what can we
> trust in the environment, because Emacs uses the environment variable
> for many other important needs, and one way of finding cmd.exe is
> through other environment variables.
>
> If the OP answers the question, we might be on a more constructive
> path.
>