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

[Eli Zaretskii]

> From: Jerry Asher <ja2038@gmail.com>
> Date: Sat, 2 Apr 2016 09:06:57 -0700
> 
> The problem is that Windows can sometimes (see caveat below) start emacs such 
> that COMSPEC is not defined.

(The caveat being that the OP poked the PE headers of the Emacs binary
to change its subsystem from 'console' to 'windows'.)

FWIW, I cannot reproduce this problem.  I've compiled a simple Windows
GUI program that calls 'getenv', and it can access the COMSPEC
variable without any trouble.  I also used 'objcopy' to change the
subsystem of the Emacs executable to 'windows' (which should have the
same effect as what the OP did with a Python script), and the
resulting executable does have COMSPEC in the environment when it
starts.

So I'm quite sure some other factor is at work here, most probably
something in the user customizations.  Looking at the value of
process-environment after starting "emacs -Q" should be the first step
for investigating the reasons for this behavior.  If COMSPEC is not
there in "emacs -Q", the next step is to describe the local
configuration with system shells; if it is, look at your
customizations in ~/.emacs and elsewhere.

> Once more, I am not a windows developer, you are the maintainer, I have 
> reported a bug, a bug felt not just by me but by many others, the current 
> code, which sets it to NIL is 10,000% guaranteed to be wrong, since you 
> REJECTED my proposed suggestion which would seem to work in most cases and be 
> a great place to start,
> 
> Here are a list of many other people who see this bug:
> https://www.google.com/search?q=emacs+cmd.exe+tramp-encoding-shell+string-match

The relevant hits of this Google search seems to point to just 2
reports, both of them look like they are related to magit.  (Another
report, where it turns out the user tried to use PowerShell as the
system shell, can be disregarded as a situation that will never work
on Windows without a lot of tinkering.)  I didn't find any such issue
in the magit issue tracker, so I'm not sure what's going on there.  I
suspect something related to the local setup with shells, perhaps, or
maybe something related to Python mode.

In any case, these reports don't seem to provide any useful
information about the reason for the problem, as they all end in the
user using the Tramp customizations to set tramp-encoding-shell
directly, which btw is an okay solution, it just cannot be used in the
default value of the defcustom, for the reasons explained up-thread.

Last, but not least: COMSPEC is used in Emacs by more than just Tramp.
For example, using M-! etc. to run commands that require a shell will
not work without COMSPEC in the environment, because cmdproxy.exe uses
the same method to find cmd.exe that Tramp does, and will fail if it
cannot find it.  So the Tramp problem is just the tip of a rather
large iceberg.

To summarize:

  . making Emacs a GUI app doesn't in itself interfere with COMSPEC
  . without COMSPEC in the environment many other Emacs features will fail
  . more information about the OP's setup is required to understand
    the reason(s) for the problem