GNU bug report logs -
#23186
25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match
Previous Next
Reported by: Jerry Asher <ja2038 <at> gmail.com>
Date: Sat, 2 Apr 2016 16:08:02 UTC
Severity: normal
Found in version 25.0.92
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 <at> gmx.de>
wrote:
> Jerry Asher <ja2038 <at> 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.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 9 years and 134 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.