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

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 7160 bytes --]

--text follows this line--

I started the 64 bit version of windows emacs from a shortcut on my
taskbar. I
created the shortcut a few minutes ago by running emacs from the command
line, then pinning the shortcut. (There is a big caveat and I'll discuss
that at the end.)

Starting emacs up in restoring my desktop it loaded a python file. That
python file triggered python mode. Somewhere in there, ...

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("cmd\\.exe" nil)
  (if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c")
  eval((if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
  custom-initialize-reset(tramp-encoding-command-switch (if (string-match
"cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
  custom-declare-variable(tramp-encoding-command-switch (if (string-match
"cmd\\.exe" tramp-encoding-shell) "/c" "-c") "Use this switch together with
`tramp-encoding-shell' for local commands.\nSee the variable
`tramp-encoding-shell' for more information." :group tramp :type string)
  byte-code("\300\301!\210\302\303\304\305\306\307\306\310\311\312\313\314&
\210\315\316\317\320\306\303\321\322& \210\315\323\324\325\306\303\321\326&
\210\327\330!\203:

I believe the problem is in tramp.el which assumes that COMSPEC has been
set.

(defcustom tramp-encoding-shell
  (if (memq system-type '(windows-nt))
      (getenv "COMSPEC")
    "/bin/sh")

The problem is that Windows can sometimes (see caveat below) start emacs
such that COMSPEC is not defined.

I think perhaps a fix would be something along the lines of:

(defcustom tramp-encoding-shell
  (if (memq system-type '(windows-nt))
      (or (getenv "COMSPEC")
          (concat (getenv "systemroot") "\\system32\\cmd.exe"))
    "/bin/sh")

I'm not a windows developer, but it seems that modulo the systemroot, the
system32\cmd.exe path is always (?) the right path.

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.

But I've seen other users report the basic cmd.exe tramp-encoding-shell
string match problem, see:

https://www.google.com/search?q=string-match%28
"cmd%5C%5C.exe"+nil%29+tramp-encoding-shell

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.

So why not assign tramp-encoding-shell a default that will probably work
instead?

Thanks,

Jerry Asher

In GNU Emacs 25.0.92.1 (x86_64-w64-mingw32)
 of 2016-03-03 built on KAEL
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
 -fomit-frame-pointer -g0''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Emacs-Lisp

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Mark saved where search started
Mark set
nil
Auto-saving...
Unable to load color "peach"
Mark set [3 times]
Quit
Mark saved where search started [2 times]
Auto-saving...done
Unable to load color "peach" [2 times]

Load-path shadows:
c:/Users/Jerry/.emacs.d/user-library/loaddefs hides
c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/loaddefs
c:/Users/Jerry/Dropbox/elpa/seq-2.15/seq hides
c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/seq
c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/cl-generic
hides c:/Users/Jerry/Dropbox/elpa/cl-generic-0.2/cl-generic

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils thingatpt find-or-tag
find-func dired-aux dired misearch multi-isearch vc vc-dispatcher vc-git
diff-mode easy-mmode warnings tramp-compat auth-source gnus-util mm-util
help-fns mail-prsvr password-cache tramp-loaddefs trampver ucs-normalize
shell pcomplete format-spec advice json map ido seq seq-25 grep compile
files-x etags xref project eieio byte-opt bytecomp byte-compile cl-extra
help-mode cconv eieio-core cus-edit wid-edit projectile-init
paredit-init package-sync-init nssh-mode-init neotree-init
multiple-cursor-init modeline-tweaks markdown-init magit-init
javascript-init find-or-tag-init expand-region-init edmacro kmacro
eldoc-init dired-init dev-requires desktop-init cygwin-init cygwin-mount
ange-ftp comint ansi-color ring basic-defuns.el cl-seq cl-macs gv
cl-loaddefs pcase cl-lib amazon-tweaks update-auto-loads utf-coding
required-libraries print-list key-bindings finder-inf slime-autoloads
info package easymenu epg-config time cus-start cus-load time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify dbusbind w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 369391 18287)
 (symbols 56 30368 0)
 (miscs 48 160 430)
 (strings 32 54134 10687)
 (string-bytes 1 1555262)
 (vectors 16 45846)
 (vector-slots 8 806255 5532)
 (floats 8 306 365)
 (intervals 56 11467 2656)
 (buffers 976 28))

[-- Attachment #2: Type: text/html, Size: 8954 bytes --]

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

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

[Eli Zaretskii]

> Date: Sat, 02 Apr 2016 19:44:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23186@debbugs.gnu.org
> 
> What is the full contents of the environment of the Emacs process when
> you run that zapped binary?

Since the OP refused to answer even the above simplest question, and
instead sent off-list a hostile email with personal attacks on me, I'm
closing this bug report.

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 9500 bytes --]

Heh, a bug report is a bug report REGARDLESS of how you felt you were
treated.

Since you started off your response to me

+ disparaging my bug report
+ misrepresenting what I said
+ summarizing it inaccurately
+ dismissing the evidence

You received in kind a report filled with frustration.

I can just see other people closing bug reports that discuss a clearly
documented and widely reported bug as seen by google searches with
responses like "I felt reporter was mean to me so I closed this bug report."

Jerry

On Sat, Apr 2, 2016 at 10:28 AM, GNU bug Tracking System <
help-debbugs@gnu.org> wrote:

> Your bug report
>
> #23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows
> up in a string-match
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 23186@debbugs.gnu.org.
>
> --
> 23186: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23186
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Eli Zaretskii <eliz@gnu.org>
> To: 23186-done@debbugs.gnu.org
> Cc:
> Date: Sat, 02 Apr 2016 20:26:41 +0300
> Subject: Re: bug#23186: 25.0.92; Tramp: Windows does not always set
> COMSPEC, tramp blows up in a string-match
> > Date: Sat, 02 Apr 2016 19:44:18 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 23186@debbugs.gnu.org
> >
> > What is the full contents of the environment of the Emacs process when
> > you run that zapped binary?
>
> Since the OP refused to answer even the above simplest question, and
> instead sent off-list a hostile email with personal attacks on me, I'm
> closing this bug report.
>
>
>
> ---------- Forwarded message ----------
> From: Jerry Asher <ja2038@gmail.com>
> To: bug-gnu-emacs@gnu.org
> Cc:
> Date: Sat, 2 Apr 2016 09:06:57 -0700
> Subject: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows
> up in a string-match
>
> --text follows this line--
>
> I started the 64 bit version of windows emacs from a shortcut on my
> taskbar. I
> created the shortcut a few minutes ago by running emacs from the command
> line, then pinning the shortcut. (There is a big caveat and I'll discuss
> that at the end.)
>
> Starting emacs up in restoring my desktop it loaded a python file. That
> python file triggered python mode. Somewhere in there, ...
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   string-match("cmd\\.exe" nil)
>   (if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c")
>   eval((if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>   custom-initialize-reset(tramp-encoding-command-switch (if (string-match
> "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>   custom-declare-variable(tramp-encoding-command-switch (if (string-match
> "cmd\\.exe" tramp-encoding-shell) "/c" "-c") "Use this switch together with
> `tramp-encoding-shell' for local commands.\nSee the variable
> `tramp-encoding-shell' for more information." :group tramp :type string)
>
> byte-code("\300\301!\210\302\303\304\305\306\307\306\310\311\312\313\314&
> \210\315\316\317\320\306\303\321\322& \210\315\323\324\325\306\303\321\326&
> \210\327\330!\203:
>
> I believe the problem is in tramp.el which assumes that COMSPEC has been
> set.
>
> (defcustom tramp-encoding-shell
>   (if (memq system-type '(windows-nt))
>       (getenv "COMSPEC")
>     "/bin/sh")
>
> The problem is that Windows can sometimes (see caveat below) start emacs
> such that COMSPEC is not defined.
>
> I think perhaps a fix would be something along the lines of:
>
> (defcustom tramp-encoding-shell
>   (if (memq system-type '(windows-nt))
>       (or (getenv "COMSPEC")
>           (concat (getenv "systemroot") "\\system32\\cmd.exe"))
>     "/bin/sh")
>
> I'm not a windows developer, but it seems that modulo the systemroot, the
> system32\cmd.exe path is always (?) the right path.
>
> 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.
>
> But I've seen other users report the basic cmd.exe tramp-encoding-shell
> string match problem, see:
>
> https://www.google.com/search?q=string-match%28
> "cmd%5C%5C.exe"+nil%29+tramp-encoding-shell
>
> 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.
>
> So why not assign tramp-encoding-shell a default that will probably work
> instead?
>
> Thanks,
>
> Jerry Asher
>
> In GNU Emacs 25.0.92.1 (x86_64-w64-mingw32)
>  of 2016-03-03 built on KAEL
> Windowing system distributor 'Microsoft Corp.', version 6.1.7601
> Configured using:
>  'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
>  -fomit-frame-pointer -g0''
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
> TOOLKIT_SCROLL_BARS
>
> Important settings:
>   value of $LANG: ENU
>   locale-coding-system: cp1252
>
> Major mode: Emacs-Lisp
>
> Minor modes in effect:
>   diff-auto-refine-mode: t
>   shell-dirtrack-mode: t
>   display-time-mode: t
>   tooltip-mode: t
>   global-eldoc-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   column-number-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>
> Recent messages:
> Mark saved where search started
> Mark set
> nil
> Auto-saving...
> Unable to load color "peach"
> Mark set [3 times]
> Quit
> Mark saved where search started [2 times]
> Auto-saving...done
> Unable to load color "peach" [2 times]
>
> Load-path shadows:
> c:/Users/Jerry/.emacs.d/user-library/loaddefs hides
> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/loaddefs
> c:/Users/Jerry/Dropbox/elpa/seq-2.15/seq hides
> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/seq
> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/cl-generic
> hides c:/Users/Jerry/Dropbox/elpa/cl-generic-0.2/cl-generic
>
> Features:
> (shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
> sendmail rfc2047 rfc2045 ietf-drums mail-utils thingatpt find-or-tag
> find-func dired-aux dired misearch multi-isearch vc vc-dispatcher vc-git
> diff-mode easy-mmode warnings tramp-compat auth-source gnus-util mm-util
> help-fns mail-prsvr password-cache tramp-loaddefs trampver ucs-normalize
> shell pcomplete format-spec advice json map ido seq seq-25 grep compile
> files-x etags xref project eieio byte-opt bytecomp byte-compile cl-extra
> help-mode cconv eieio-core cus-edit wid-edit projectile-init
> paredit-init package-sync-init nssh-mode-init neotree-init
> multiple-cursor-init modeline-tweaks markdown-init magit-init
> javascript-init find-or-tag-init expand-region-init edmacro kmacro
> eldoc-init dired-init dev-requires desktop-init cygwin-init cygwin-mount
> ange-ftp comint ansi-color ring basic-defuns.el cl-seq cl-macs gv
> cl-loaddefs pcase cl-lib amazon-tweaks update-auto-loads utf-coding
> required-libraries print-list key-bindings finder-inf slime-autoloads
> info package easymenu epg-config time cus-start cus-load time-date
> mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
> term/common-win tool-bar dnd fontset image regexp-opt fringe
> tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
> syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
> cp51932 hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
> simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
> cus-face macroexp files text-properties overlay sha1 md5 base64 format
> env code-pages mule custom widget hashtable-print-readable backquote
> w32notify dbusbind w32 multi-tty make-network-process emacs)
>
> Memory information:
> ((conses 16 369391 18287)
>  (symbols 56 30368 0)
>  (miscs 48 160 430)
>  (strings 32 54134 10687)
>  (string-bytes 1 1555262)
>  (vectors 16 45846)
>  (vector-slots 8 806255 5532)
>  (floats 8 306 365)
>  (intervals 56 11467 2656)
>  (buffers 976 28))
>
>

[-- Attachment #2: Type: text/html, Size: 12068 bytes --]

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 10238 bytes --]

Your bug closing excuse is defamatory, there were no personal attacks on
you.

There was criticism of your behavior and how you examine and respond to bug
reports. None of that constitutes a personal attack on you.

Your closing a bug report that describes a valid bug because you dislike
how the conversation you initiated went, is support for my criticism of how
you respond to bug reports.







On Sat, Apr 2, 2016 at 10:32 AM, Jerry Asher <ja2038@gmail.com> wrote:

> Heh, a bug report is a bug report REGARDLESS of how you felt you were
> treated.
>
> Since you started off your response to me
>
> + disparaging my bug report
> + misrepresenting what I said
> + summarizing it inaccurately
> + dismissing the evidence
>
> You received in kind a report filled with frustration.
>
> I can just see other people closing bug reports that discuss a clearly
> documented and widely reported bug as seen by google searches with
> responses like "I felt reporter was mean to me so I closed this bug report."
>
> Jerry
>
> On Sat, Apr 2, 2016 at 10:28 AM, GNU bug Tracking System <
> help-debbugs@gnu.org> wrote:
>
>> Your bug report
>>
>> #23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows
>> up in a string-match
>>
>> which was filed against the emacs package, has been closed.
>>
>> The explanation is attached below, along with your original report.
>> If you require more details, please reply to 23186@debbugs.gnu.org.
>>
>> --
>> 23186: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23186
>> GNU Bug Tracking System
>> Contact help-debbugs@gnu.org with problems
>>
>>
>> ---------- Forwarded message ----------
>> From: Eli Zaretskii <eliz@gnu.org>
>> To: 23186-done@debbugs.gnu.org
>> Cc:
>> Date: Sat, 02 Apr 2016 20:26:41 +0300
>> Subject: Re: bug#23186: 25.0.92; Tramp: Windows does not always set
>> COMSPEC, tramp blows up in a string-match
>> > Date: Sat, 02 Apr 2016 19:44:18 +0300
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > Cc: 23186@debbugs.gnu.org
>> >
>> > What is the full contents of the environment of the Emacs process when
>> > you run that zapped binary?
>>
>> Since the OP refused to answer even the above simplest question, and
>> instead sent off-list a hostile email with personal attacks on me, I'm
>> closing this bug report.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Jerry Asher <ja2038@gmail.com>
>> To: bug-gnu-emacs@gnu.org
>> Cc:
>> Date: Sat, 2 Apr 2016 09:06:57 -0700
>> Subject: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows
>> up in a string-match
>>
>> --text follows this line--
>>
>> I started the 64 bit version of windows emacs from a shortcut on my
>> taskbar. I
>> created the shortcut a few minutes ago by running emacs from the command
>> line, then pinning the shortcut. (There is a big caveat and I'll discuss
>> that at the end.)
>>
>> Starting emacs up in restoring my desktop it loaded a python file. That
>> python file triggered python mode. Somewhere in there, ...
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   string-match("cmd\\.exe" nil)
>>   (if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c")
>>   eval((if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>>   custom-initialize-reset(tramp-encoding-command-switch (if (string-match
>> "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>>   custom-declare-variable(tramp-encoding-command-switch (if (string-match
>> "cmd\\.exe" tramp-encoding-shell) "/c" "-c") "Use this switch together with
>> `tramp-encoding-shell' for local commands.\nSee the variable
>> `tramp-encoding-shell' for more information." :group tramp :type string)
>>
>> byte-code("\300\301!\210\302\303\304\305\306\307\306\310\311\312\313\314&
>> \210\315\316\317\320\306\303\321\322& \210\315\323\324\325\306\303\321\326&
>> \210\327\330!\203:
>>
>> I believe the problem is in tramp.el which assumes that COMSPEC has been
>> set.
>>
>> (defcustom tramp-encoding-shell
>>   (if (memq system-type '(windows-nt))
>>       (getenv "COMSPEC")
>>     "/bin/sh")
>>
>> The problem is that Windows can sometimes (see caveat below) start emacs
>> such that COMSPEC is not defined.
>>
>> I think perhaps a fix would be something along the lines of:
>>
>> (defcustom tramp-encoding-shell
>>   (if (memq system-type '(windows-nt))
>>       (or (getenv "COMSPEC")
>>           (concat (getenv "systemroot") "\\system32\\cmd.exe"))
>>     "/bin/sh")
>>
>> I'm not a windows developer, but it seems that modulo the systemroot, the
>> system32\cmd.exe path is always (?) the right path.
>>
>> 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.
>>
>> But I've seen other users report the basic cmd.exe tramp-encoding-shell
>> string match problem, see:
>>
>> https://www.google.com/search?q=string-match%28
>> "cmd%5C%5C.exe"+nil%29+tramp-encoding-shell
>>
>> 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.
>>
>> So why not assign tramp-encoding-shell a default that will probably work
>> instead?
>>
>> Thanks,
>>
>> Jerry Asher
>>
>> In GNU Emacs 25.0.92.1 (x86_64-w64-mingw32)
>>  of 2016-03-03 built on KAEL
>> Windowing system distributor 'Microsoft Corp.', version 6.1.7601
>> Configured using:
>>  'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
>>  -fomit-frame-pointer -g0''
>>
>> Configured features:
>> XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
>> TOOLKIT_SCROLL_BARS
>>
>> Important settings:
>>   value of $LANG: ENU
>>   locale-coding-system: cp1252
>>
>> Major mode: Emacs-Lisp
>>
>> Minor modes in effect:
>>   diff-auto-refine-mode: t
>>   shell-dirtrack-mode: t
>>   display-time-mode: t
>>   tooltip-mode: t
>>   global-eldoc-mode: t
>>   electric-indent-mode: t
>>   mouse-wheel-mode: t
>>   menu-bar-mode: t
>>   file-name-shadow-mode: t
>>   global-font-lock-mode: t
>>   font-lock-mode: t
>>   auto-composition-mode: t
>>   auto-encryption-mode: t
>>   auto-compression-mode: t
>>   column-number-mode: t
>>   line-number-mode: t
>>   transient-mark-mode: t
>>
>> Recent messages:
>> Mark saved where search started
>> Mark set
>> nil
>> Auto-saving...
>> Unable to load color "peach"
>> Mark set [3 times]
>> Quit
>> Mark saved where search started [2 times]
>> Auto-saving...done
>> Unable to load color "peach" [2 times]
>>
>> Load-path shadows:
>> c:/Users/Jerry/.emacs.d/user-library/loaddefs hides
>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/loaddefs
>> c:/Users/Jerry/Dropbox/elpa/seq-2.15/seq hides
>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/seq
>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/cl-generic
>> hides c:/Users/Jerry/Dropbox/elpa/cl-generic-0.2/cl-generic
>>
>> Features:
>> (shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
>> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
>> sendmail rfc2047 rfc2045 ietf-drums mail-utils thingatpt find-or-tag
>> find-func dired-aux dired misearch multi-isearch vc vc-dispatcher vc-git
>> diff-mode easy-mmode warnings tramp-compat auth-source gnus-util mm-util
>> help-fns mail-prsvr password-cache tramp-loaddefs trampver ucs-normalize
>> shell pcomplete format-spec advice json map ido seq seq-25 grep compile
>> files-x etags xref project eieio byte-opt bytecomp byte-compile cl-extra
>> help-mode cconv eieio-core cus-edit wid-edit projectile-init
>> paredit-init package-sync-init nssh-mode-init neotree-init
>> multiple-cursor-init modeline-tweaks markdown-init magit-init
>> javascript-init find-or-tag-init expand-region-init edmacro kmacro
>> eldoc-init dired-init dev-requires desktop-init cygwin-init cygwin-mount
>> ange-ftp comint ansi-color ring basic-defuns.el cl-seq cl-macs gv
>> cl-loaddefs pcase cl-lib amazon-tweaks update-auto-loads utf-coding
>> required-libraries print-list key-bindings finder-inf slime-autoloads
>> info package easymenu epg-config time cus-start cus-load time-date
>> mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
>> lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
>> term/common-win tool-bar dnd fontset image regexp-opt fringe
>> tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
>> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
>> syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
>> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
>> cp51932 hebrew greek romanian slovak czech european ethiopic indian
>> cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
>> simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
>> cus-face macroexp files text-properties overlay sha1 md5 base64 format
>> env code-pages mule custom widget hashtable-print-readable backquote
>> w32notify dbusbind w32 multi-tty make-network-process emacs)
>>
>> Memory information:
>> ((conses 16 369391 18287)
>>  (symbols 56 30368 0)
>>  (miscs 48 160 430)
>>  (strings 32 54134 10687)
>>  (string-bytes 1 1555262)
>>  (vectors 16 45846)
>>  (vector-slots 8 806255 5532)
>>  (floats 8 306 365)
>>  (intervals 56 11467 2656)
>>  (buffers 976 28))
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 13155 bytes --]

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 11529 bytes --]

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

We are ALREADY talking about a very specific setting IN emacs FOR Windows.
God forbid we should ask the maintainers to discuss how emacs is configured
on Windows in that context.

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

And I agree, setting the variable to nil where it is guaranteed to blow up,
and is reported to do so as my search shows is FAR FAR better than finding
a reasonable default that will work most of the time.

On Sat, Apr 2, 2016 at 10:37 AM, Jerry Asher <ja2038@gmail.com> wrote:

> Your bug closing excuse is defamatory, there were no personal attacks on
> you.
>
> There was criticism of your behavior and how you examine and respond to
> bug reports. None of that constitutes a personal attack on you.
>
> Your closing a bug report that describes a valid bug because you dislike
> how the conversation you initiated went, is support for my criticism of how
> you respond to bug reports.
>
>
>
>
>
>
>
> On Sat, Apr 2, 2016 at 10:32 AM, Jerry Asher <ja2038@gmail.com> wrote:
>
>> Heh, a bug report is a bug report REGARDLESS of how you felt you were
>> treated.
>>
>> Since you started off your response to me
>>
>> + disparaging my bug report
>> + misrepresenting what I said
>> + summarizing it inaccurately
>> + dismissing the evidence
>>
>> You received in kind a report filled with frustration.
>>
>> I can just see other people closing bug reports that discuss a clearly
>> documented and widely reported bug as seen by google searches with
>> responses like "I felt reporter was mean to me so I closed this bug report."
>>
>> Jerry
>>
>> On Sat, Apr 2, 2016 at 10:28 AM, GNU bug Tracking System <
>> help-debbugs@gnu.org> wrote:
>>
>>> Your bug report
>>>
>>> #23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows
>>> up in a string-match
>>>
>>> which was filed against the emacs package, has been closed.
>>>
>>> The explanation is attached below, along with your original report.
>>> If you require more details, please reply to 23186@debbugs.gnu.org.
>>>
>>> --
>>> 23186: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23186
>>> GNU Bug Tracking System
>>> Contact help-debbugs@gnu.org with problems
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> To: 23186-done@debbugs.gnu.org
>>> Cc:
>>> Date: Sat, 02 Apr 2016 20:26:41 +0300
>>> Subject: Re: bug#23186: 25.0.92; Tramp: Windows does not always set
>>> COMSPEC, tramp blows up in a string-match
>>> > Date: Sat, 02 Apr 2016 19:44:18 +0300
>>> > From: Eli Zaretskii <eliz@gnu.org>
>>> > Cc: 23186@debbugs.gnu.org
>>> >
>>> > What is the full contents of the environment of the Emacs process when
>>> > you run that zapped binary?
>>>
>>> Since the OP refused to answer even the above simplest question, and
>>> instead sent off-list a hostile email with personal attacks on me, I'm
>>> closing this bug report.
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Jerry Asher <ja2038@gmail.com>
>>> To: bug-gnu-emacs@gnu.org
>>> Cc:
>>> Date: Sat, 2 Apr 2016 09:06:57 -0700
>>> Subject: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp
>>> blows up in a string-match
>>>
>>> --text follows this line--
>>>
>>> I started the 64 bit version of windows emacs from a shortcut on my
>>> taskbar. I
>>> created the shortcut a few minutes ago by running emacs from the command
>>> line, then pinning the shortcut. (There is a big caveat and I'll discuss
>>> that at the end.)
>>>
>>> Starting emacs up in restoring my desktop it loaded a python file. That
>>> python file triggered python mode. Somewhere in there, ...
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   string-match("cmd\\.exe" nil)
>>>   (if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c")
>>>   eval((if (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>>>   custom-initialize-reset(tramp-encoding-command-switch (if
>>> (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c"))
>>>   custom-declare-variable(tramp-encoding-command-switch (if
>>> (string-match "cmd\\.exe" tramp-encoding-shell) "/c" "-c") "Use this switch
>>> together with `tramp-encoding-shell' for local commands.\nSee the variable
>>> `tramp-encoding-shell' for more information." :group tramp :type string)
>>>
>>> byte-code("\300\301!\210\302\303\304\305\306\307\306\310\311\312\313\314&
>>> \210\315\316\317\320\306\303\321\322& \210\315\323\324\325\306\303\321\326&
>>> \210\327\330!\203:
>>>
>>> I believe the problem is in tramp.el which assumes that COMSPEC has been
>>> set.
>>>
>>> (defcustom tramp-encoding-shell
>>>   (if (memq system-type '(windows-nt))
>>>       (getenv "COMSPEC")
>>>     "/bin/sh")
>>>
>>> The problem is that Windows can sometimes (see caveat below) start emacs
>>> such that COMSPEC is not defined.
>>>
>>> I think perhaps a fix would be something along the lines of:
>>>
>>> (defcustom tramp-encoding-shell
>>>   (if (memq system-type '(windows-nt))
>>>       (or (getenv "COMSPEC")
>>>           (concat (getenv "systemroot") "\\system32\\cmd.exe"))
>>>     "/bin/sh")
>>>
>>> I'm not a windows developer, but it seems that modulo the systemroot,
>>> the system32\cmd.exe path is always (?) the right path.
>>>
>>> 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.
>>>
>>> But I've seen other users report the basic cmd.exe tramp-encoding-shell
>>> string match problem, see:
>>>
>>> https://www.google.com/search?q=string-match%28
>>> "cmd%5C%5C.exe"+nil%29+tramp-encoding-shell
>>>
>>> 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.
>>>
>>> So why not assign tramp-encoding-shell a default that will probably work
>>> instead?
>>>
>>> Thanks,
>>>
>>> Jerry Asher
>>>
>>> In GNU Emacs 25.0.92.1 (x86_64-w64-mingw32)
>>>  of 2016-03-03 built on KAEL
>>> Windowing system distributor 'Microsoft Corp.', version 6.1.7601
>>> Configured using:
>>>  'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
>>>  -fomit-frame-pointer -g0''
>>>
>>> Configured features:
>>> XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
>>> TOOLKIT_SCROLL_BARS
>>>
>>> Important settings:
>>>   value of $LANG: ENU
>>>   locale-coding-system: cp1252
>>>
>>> Major mode: Emacs-Lisp
>>>
>>> Minor modes in effect:
>>>   diff-auto-refine-mode: t
>>>   shell-dirtrack-mode: t
>>>   display-time-mode: t
>>>   tooltip-mode: t
>>>   global-eldoc-mode: t
>>>   electric-indent-mode: t
>>>   mouse-wheel-mode: t
>>>   menu-bar-mode: t
>>>   file-name-shadow-mode: t
>>>   global-font-lock-mode: t
>>>   font-lock-mode: t
>>>   auto-composition-mode: t
>>>   auto-encryption-mode: t
>>>   auto-compression-mode: t
>>>   column-number-mode: t
>>>   line-number-mode: t
>>>   transient-mark-mode: t
>>>
>>> Recent messages:
>>> Mark saved where search started
>>> Mark set
>>> nil
>>> Auto-saving...
>>> Unable to load color "peach"
>>> Mark set [3 times]
>>> Quit
>>> Mark saved where search started [2 times]
>>> Auto-saving...done
>>> Unable to load color "peach" [2 times]
>>>
>>> Load-path shadows:
>>> c:/Users/Jerry/.emacs.d/user-library/loaddefs hides
>>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/loaddefs
>>> c:/Users/Jerry/Dropbox/elpa/seq-2.15/seq hides
>>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/seq
>>> c:/gnu/emacs-bin-w64-25.0.92-O2/emacs/share/emacs/25.0.92/lisp/emacs-lisp/cl-generic
>>> hides c:/Users/Jerry/Dropbox/elpa/cl-generic-0.2/cl-generic
>>>
>>> Features:
>>> (shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
>>> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
>>> sendmail rfc2047 rfc2045 ietf-drums mail-utils thingatpt find-or-tag
>>> find-func dired-aux dired misearch multi-isearch vc vc-dispatcher vc-git
>>> diff-mode easy-mmode warnings tramp-compat auth-source gnus-util mm-util
>>> help-fns mail-prsvr password-cache tramp-loaddefs trampver ucs-normalize
>>> shell pcomplete format-spec advice json map ido seq seq-25 grep compile
>>> files-x etags xref project eieio byte-opt bytecomp byte-compile cl-extra
>>> help-mode cconv eieio-core cus-edit wid-edit projectile-init
>>> paredit-init package-sync-init nssh-mode-init neotree-init
>>> multiple-cursor-init modeline-tweaks markdown-init magit-init
>>> javascript-init find-or-tag-init expand-region-init edmacro kmacro
>>> eldoc-init dired-init dev-requires desktop-init cygwin-init cygwin-mount
>>> ange-ftp comint ansi-color ring basic-defuns.el cl-seq cl-macs gv
>>> cl-loaddefs pcase cl-lib amazon-tweaks update-auto-loads utf-coding
>>> required-libraries print-list key-bindings finder-inf slime-autoloads
>>> info package easymenu epg-config time cus-start cus-load time-date
>>> mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
>>> lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
>>> term/common-win tool-bar dnd fontset image regexp-opt fringe
>>> tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
>>> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
>>> syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
>>> misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
>>> cp51932 hebrew greek romanian slovak czech european ethiopic indian
>>> cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
>>> simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
>>> cus-face macroexp files text-properties overlay sha1 md5 base64 format
>>> env code-pages mule custom widget hashtable-print-readable backquote
>>> w32notify dbusbind w32 multi-tty make-network-process emacs)
>>>
>>> Memory information:
>>> ((conses 16 369391 18287)
>>>  (symbols 56 30368 0)
>>>  (miscs 48 160 430)
>>>  (strings 32 54134 10687)
>>>  (string-bytes 1 1555262)
>>>  (vectors 16 45846)
>>>  (vector-slots 8 806255 5532)
>>>  (floats 8 306 365)
>>>  (intervals 56 11467 2656)
>>>  (buffers 976 28))
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 15429 bytes --]

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

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

The Tramp maintainers could check, whether COMSPEC is set, and raise a
verbose warning in case it isn't. Refusing further work.

Shall I commit this to the emacs-25 branch, or to master?

Best regards, Michael.

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

[Michael Albinus]

Jerry Asher <ja2038@gmail.com> writes:

Hi Jerry,

>> 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.
>
> We are ALREADY talking about a very specific setting IN emacs FOR
> Windows. God forbid we should ask the maintainers to discuss how emacs
> is configured on Windows in that context.
>
>> 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.
>
> And I agree, setting the variable to nil where it is guaranteed to
> blow up, and is reported to do so as my search shows is FAR FAR better
> than finding a reasonable default that will work most of the time.

I'm not interested in any flamewar. Pls stop.

I haven't too much knowledge about MS Windows, and many years of
experience let me trust Eli.

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.

Best regards, Michael.

PS: I am the Tramp maintainer.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 02 Apr 2016 21:47:48 +0200
> Cc: 23186@debbugs.gnu.org
> 
> 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.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Jerry Asher <ja2038@gmail.com>,  23186@debbugs.gnu.org
> Date: Sat, 02 Apr 2016 21:37:51 +0200
> 
> The Tramp maintainers could check, whether COMSPEC is set, and raise a
> verbose warning in case it isn't. Refusing further work.

That'd be fine with me.

> Shall I commit this to the emacs-25 branch, or to master?

emacs-25, I guess.

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 4842 bytes --]

Thanks for the response Michael.

Clearly I wasn't interested in a flamewar either.

+ I submitted a relatively complete bug report
+ I explained how I got there
+ I explained its relative importance
+ I provided evidence that others were seeing this issue in different areas
+ I explained I was not a windows developer
+ I proposed an initial suggested fix

None of these are activities someone looking for a flamewar would do

Imagine my horror to be met on the very first response from Gnu

+ What I wanted the maintainers to do was unreasonable
+ My particular configuration invalidated the need to look at the bug
entirely
+ A misrepresentation of my fix making it look much more fragile
+ Being given a vague demand to produce more evidence and no instructions
on what was needed or how to supply it

*What is the full contents of the environment of the Emacs process whenyou
run that zapped binary?*

And then to have a defamatory slur placed in the bug report.

Michael, I am not interested in a flamewar, regardless, your trust in him
aside, I was abused by Eli this morning.

> 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 don't even know what that means.

As I said:

+ *"**C:\Windows\system32\cmd.exe"*  THIS WAS LITERALLY NOT WHAT I PROPOSED
+ Regardless, when COMSPEC is not defined, assigning NIL to
tramp-encoding-shell CERTAINLY IS WRONG.
+ Other people are seeing this problem too, google it as I showed you.

Since you are the maintainer, I would never deign to claim I know more than
you do about TRAMP

So please Michael,

+ bug reporters are often NOT the best person to analyse or propose a
solution.
+ When COMSPEC is not defined, assigning NIL to tramp-encoding-shell
CERTAINLY IS WRONG.
+ Other people see this problem too.,

WHAT DO YOU THE MAINTAINER PROPOSE as a solution?

Since I am not a windows developer, I think my actual proposal setting the
value to "%SYSTEMROOT%\system32\cmd.exe" is a reasonable first start.

I note it seems to work up to and including Windows 10 64.

I don't know where cmd.exe is supposed to live, or how it's supposed to be
found, but I do know the path I suggested, which misrepresented as you and
Eli have done, actually works and would work FAR better than setting it to
NIL.

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

AS THE TRAMP MAINTAINER, WHAT DO YOU SUGGEST TO FIX THIS BUG?

Thank you for your attention,

Jerry


On Sat, Apr 2, 2016 at 12:47 PM, Michael Albinus <michael.albinus@gmx.de>
wrote:

> Jerry Asher <ja2038@gmail.com> writes:
>
> Hi Jerry,
>
> >> 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.
> >
> > We are ALREADY talking about a very specific setting IN emacs FOR
> > Windows. God forbid we should ask the maintainers to discuss how emacs
> > is configured on Windows in that context.
> >
> >> 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.
> >
> > And I agree, setting the variable to nil where it is guaranteed to
> > blow up, and is reported to do so as my search shows is FAR FAR better
> > than finding a reasonable default that will work most of the time.
>
> I'm not interested in any flamewar. Pls stop.
>
> I haven't too much knowledge about MS Windows, and many years of
> experience let me trust Eli.
>
> 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.
>
> Best regards, Michael.
>
> PS: I am the Tramp maintainer.
>

[-- Attachment #2: Type: text/html, Size: 7143 bytes --]

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

> 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 <eliz@gnu.org> wrote:

> > From: Michael Albinus <michael.albinus@gmx.de>
> > Date: Sat, 02 Apr 2016 21:47:48 +0200
> > Cc: 23186@debbugs.gnu.org
> >
> > 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.
>

[-- Attachment #2: Type: text/html, Size: 3697 bytes --]

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

[Jerry Asher]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Since the two of you have decided that a verbose warning is all that is
required to satisfy the problems THESE people are reporting and have
reported for years, since you have decided that assigning a guaranteed bad
value is better than setting a mostly correct value,

https://www.google.com/search?q=emacs+cmd.exe+tramp-encoding-shell+string-match

Then I gather I was correct in my earliest decision that working with you
was an exercise in futility and frustration.



On Sat, Apr 2, 2016 at 1:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: Jerry Asher <ja2038@gmail.com>,  23186@debbugs.gnu.org
> > Date: Sat, 02 Apr 2016 21:37:51 +0200
> >
> > The Tramp maintainers could check, whether COMSPEC is set, and raise a
> > verbose warning in case it isn't. Refusing further work.
>
> That'd be fine with me.
>
> > Shall I commit this to the emacs-25 branch, or to master?
>
> emacs-25, I guess.
>

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]

bug#23186: closed (Re: 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 13:11:01 -0700
> Cc: 23186@debbugs.gnu.org
> 
> What is the full contents of the environment of the Emacs process when
> you run that zapped binary?

I'm still waiting for the answer to that question.  It's important,
for the reasons explained below.

> WHAT DO YOU THE MAINTAINER PROPOSE as a solution?

We don't yet understand the problem to have a proposal.  I asked a
question that might lead to a proposal.  If you are interested in
solving the problem, please answer it.

> Since I am not a windows developer, I think my actual proposal setting the value to
> "%SYSTEMROOT%\system32\cmd.exe" is a reasonable first start.

How do we know that we can trust %SYSTEMROOT% to be in the
environment, if %COMSPEC% is not there?  How can we trust _any_
environment variable, for that matter?  That's why I asked that
question: to know what exactly is and isn't in the environment.  I
don't see how we can advance without knowing that, and I certainly
don't see how that question could be taken as a slur.

> I don't know where cmd.exe is supposed to live, or how it's supposed to be found, but I do know the path I
> suggested, which misrepresented as you and Eli have done, actually works and would work FAR better than
> setting it to NIL.

You are, of course, free to change your copy of Emacs as you see fit.
That is what Free Software is for.  But when you ask us to incorporate
the solution in upstream code, the solution must be correct for
everyone, not just for you.  And it must be well understood, because
any solution will have to be maintained from this point onward.

As a matter of fact, I still don't see how COMSPEC could disappear
from the environment just because you made Emacs a GUI program.  I
just tried that on my system, and couldn't reproduce the problem.
Maybe it's something specific to Windows 10.

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 13:21:30 -0700
> Cc: Michael Albinus <michael.albinus@gmx.de>, 23186@debbugs.gnu.org
> 
> Since the two of you have decided that a verbose warning is all that is required to satisfy the problems THESE
> people are reporting and have reported for years, since you have decided that assigning a guaranteed bad
> value is better than setting a mostly correct value,
> 
> https://www.google.com/search?q=emacs+cmd.exe+tramp-encoding-shell+string-match
> 
> 
> Then I gather I was correct in my earliest decision that working with you was an exercise in futility and
> frustration.

Only if you have decided that in advance.  Because you are talking to
people who accept, analyze, and solve bugs all the time, you can see
that in the Emacs commit log.

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 13:19:01 -0700
> Cc: Michael Albinus <michael.albinus@gmx.de>, 23186@debbugs.gnu.org
> 
> > 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

Your private data cannot help solving this problem, so you can just
elide 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.

You may wish looking at the number of Windows-related commits I made
in the Emacs repository.  Maybe that will convince you to reconsider
your views on my abilities.

Once again, if you decide to be constructive, it's possible that we
will eventually understand the nature of this problem and solve it.

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

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

>>>>> Jerry Asher <ja2038@gmail.com> writes:

> Michael, I am not interested in a flamewar, regardless, your trust in him
> aside, I was abused by Eli this morning.

Jerry, I have read all the messages in this report, and you were not "abused
by Eli". Your stance in this dialog has been both accusatory and inflammatory,
and I cannot blame any volunteer for deciding not to work with you on this
issue.

If any other of the other people you claim this bug is important to wishes to
step forward and champion the matter, I would be happy to reopen, and continue
discussing it with them. But it is fairly clear no progress will be made here
right now, and I do not wish our contributors to waste any further time.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

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

[Michael Albinus]

Jerry Asher <ja2038@gmail.com> writes:

Hi Jerry,

[sorry for the slow response, I'm fighting with bronchitis these days]

> Since the two of you have decided that a verbose warning is all that
> is required to satisfy the problems THESE people are reporting and
> have reported for years, since you have decided that assigning a
> guaranteed bad value is better than setting a mostly correct value,

It would be helpful if you don't take any statement from us as personal
attack. We don't attack you, we are just slightly demotivated by your
sound. I don't know what's the style somewhere else, but here in Emacs
development we behave respectful. This does not mean that everything is
accepted when you propose something, and it could happen that a proposal
is rejected, but it is *your* responsibility then to convince us. Not
all of us are idiots.

Coming back to the proposal: Emacs 25.1 is frozen, I won't apply serious
changes there. That's why both Eli and me have agreed to detect the
problem and report, and nothing else.

But this wouldn't prevent us from finding a better solution for further
Emacs version, if possible.

Best regards, Michael.

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Jerry,

>> What is the full contents of the environment of the Emacs process when
>> you run that zapped binary?
>
> I'm still waiting for the answer to that question.  It's important,
> for the reasons explained below.

I second Eli. First of all we must understand why COMSPEC isn't set in
your case. Just applying a workaround doesn't suffice at first glance,
it could be that there is amuch more serious problem behind. Tramp could
be just the first victim entering this problem. Who knows.

>> WHAT DO YOU THE MAINTAINER PROPOSE as a solution?

Investigate. As Eli proposed. And for the upcoming Emacs 25.1, we just
report the error. We cannot do anything else so late in the pretest.

Best regards, Michael.

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

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 02 Apr 2016 21:47:48 +0200
> Cc: 23186@debbugs.gnu.org
> 
> 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.

Let me try ;-)

Can you (Michael) explain why does Tramp need this variable, and also
why it needs the companion tramp-encoding-command-switch?  Why not
just use shell-file-name and shell-command-switch?  Or, if you must
look deeper, why not call w32-shell-name or w32-shell-dos-semantics?
I think these already do what you need tramp-encoding-shell for, but
maybe I'm missing something.

If I'm right, and Tramp doesn't really need to calculate the shell's
name separately from the rest of Emacs, then this problem will cease
to be a "Tramp problem".  That won't solve the larger problems the OP
would have in Emacs, but at least Tramp will no longer be accused ;-)

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> 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.
>
> Let me try ;-)
>
> Can you (Michael) explain why does Tramp need this variable, and also
> why it needs the companion tramp-encoding-command-switch?  Why not
> just use shell-file-name and shell-command-switch?  Or, if you must
> look deeper, why not call w32-shell-name or w32-shell-dos-semantics?
> I think these already do what you need tramp-encoding-shell for, but
> maybe I'm missing something.

Well, this is set this way for decades. I don't remember the datails;
likely it was used also for other cases than just local encoding/
decoding. And don't forget, Tramp has carried a lot of compat code, back
to Emacs 21 and XEmacs. Maybe it was not possible to trust on `w32-shell-name'.

This compat code has been removed recently. So it is applicable indeed,
to use `w32-shell-name'. I've committed a patch to master, doing this. I
don't know, whether the setting for `tramp-encoding-command-switch' is
OK, 'tho.

As usual, I cannot test it for w32. Let's see, whether we get reports :-)

> If I'm right, and Tramp doesn't really need to calculate the shell's
> name separately from the rest of Emacs, then this problem will cease
> to be a "Tramp problem".  That won't solve the larger problems the OP
> would have in Emacs, but at least Tramp will no longer be accused ;-)

Agreed. This fits perfectly to the Tramp cleanup, I have applied back in
January.

Best regards, Michael.

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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: ja2038@gmail.com,  23186@debbugs.gnu.org
> Date: Sun, 03 Apr 2016 17:55:29 +0200
> 
> > Can you (Michael) explain why does Tramp need this variable, and also
> > why it needs the companion tramp-encoding-command-switch?  Why not
> > just use shell-file-name and shell-command-switch?  Or, if you must
> > look deeper, why not call w32-shell-name or w32-shell-dos-semantics?
> > I think these already do what you need tramp-encoding-shell for, but
> > maybe I'm missing something.
> 
> Well, this is set this way for decades. I don't remember the datails;
> likely it was used also for other cases than just local encoding/
> decoding. And don't forget, Tramp has carried a lot of compat code, back
> to Emacs 21 and XEmacs. Maybe it was not possible to trust on `w32-shell-name'.

I figured it was something like that.

> This compat code has been removed recently. So it is applicable indeed,
> to use `w32-shell-name'. I've committed a patch to master, doing this. I
> don't know, whether the setting for `tramp-encoding-command-switch' is
> OK, 'tho.

The beauty of w32-shell-name is that you don't need to worry about the
switch: cmdproxy supports both -c and /c (and even -C and /C).  So you
can now safely use just "-c" for tramp-encoding-command-switch.

Or, if you want to be extra-cautious, and protect Tramp from people
who point shell-file-name or $SHELL at something weird, you can use
w32-shell-dos-semantics: if it returns non-nil, use /c, otherwise -c.

> As usual, I cannot test it for w32. Let's see, whether we get reports :-)

Yep.

Thanks.

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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> The beauty of w32-shell-name is that you don't need to worry about the
> switch: cmdproxy supports both -c and /c (and even -C and /C).  So you
> can now safely use just "-c" for tramp-encoding-command-switch.
>
> Or, if you want to be extra-cautious, and protect Tramp from people
> who point shell-file-name or $SHELL at something weird, you can use
> w32-shell-dos-semantics: if it returns non-nil, use /c, otherwise -c.

I check (boundp 'w32-shell-name). This looks safe. If somebody uses
weird settings, she will loose.

> Thanks.