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 <ja2038@gmail.com>]

[-- 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 --]