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

[Eli Zaretskii <eliz@gnu.org>]

> From: Jerry Asher <ja2038@gmail.com>
> Date: Sat, 2 Apr 2016 09:06:57 -0700
> 
> So here's the caveat, I have poked the emacs.exe image so that it does not start as a console app, but so
> that it starts as a windows app. Now, I am not a windows developer, I do not know that this is why COMSPEC
> has not been set, but boy, it's got to be, right? ?
> 
> For more on how to poke the emacs.exe image to start as a windows app, see here
> https://github.com/jerryasher/consoleAppToWin basically, doing so seems to make both ntemacs and cygwin
> emacs run a bit nicer, and so far, this is the only issue I've seen crop up.
> 
> Now, you might reasonably claim that since I am starting up emacs in a very non-standard unsupported
> manner, the issue is totally mine and no fix is necessary. And there is some logic to that.
> 
> Regardless, I would say the assumption that COMSPEC is always set and so therefore if it fails it is okay to
> assign nil to tramp-encoding-shell knowing that later on it will be in a string-match is problematic in and of
> itself. 

Tramp is designed to work with Emacs as released by the Emacs
development team.  That Emacs doesn't have this problem.  I think it
would be unreasonable for anyone to expect the Tramp maintainers to
cater to arbitrary changes in the Emacs code or in how it is
configured on Windows, let alone if you poke some addresses in the PE
headers of the produced binary.

> I don't know that my fix would fix those issues as well, but those issues point to a basic problem where
> tramp-encoding-shell is set to nil and then later compared in string-match.

Your fix is AFAIK incorrect because the directory where cmd.exe lives
is not necessarily C:\Windows\system32.  It just happens to be there
on the particular system where you tried that.

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