From: Jerry Asher <ja2038@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 23186@debbugs.gnu.org
Subject: bug#23186: closed (Re: bug#23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match)
Date: Sat, 2 Apr 2016 13:11:01 -0700 [thread overview]
Message-ID: <CACTc7ZkZspUC=v_Tzx2mnXKfMB2xQ52Ojd-PXTgkOq36YgXPbw@mail.gmail.com> (raw)
In-Reply-To: <87a8lbpzbv.fsf@gmx.de>
[-- 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 --]
next prev parent reply other threads:[~2016-04-02 20:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-02 16:06 bug#23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match Jerry Asher
2016-04-02 16:44 ` Eli Zaretskii
2016-04-02 17:26 ` Eli Zaretskii
2016-04-02 19:37 ` Michael Albinus
2016-04-02 20:03 ` Eli Zaretskii
2016-04-02 20:21 ` Jerry Asher
2016-04-02 20:29 ` Eli Zaretskii
2016-04-03 7:05 ` Michael Albinus
[not found] ` <handler.23186.D23186.145961804117806.notifdone@debbugs.gnu.org>
2016-04-02 17:32 ` 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
2016-04-02 17:37 ` Jerry Asher
2016-04-02 17:50 ` Jerry Asher
2016-04-02 19:47 ` Michael Albinus
2016-04-02 20:02 ` Eli Zaretskii
2016-04-02 20:19 ` Jerry Asher
2016-04-02 20:33 ` Eli Zaretskii
2016-04-02 20:11 ` Jerry Asher [this message]
2016-04-02 20:28 ` bug#23186: closed (Re: " Eli Zaretskii
2016-04-03 7:15 ` Michael Albinus
2016-04-02 21:35 ` John Wiegley
2016-04-03 14:54 ` Eli Zaretskii
2016-04-03 15:55 ` Michael Albinus
2016-04-03 16:17 ` Eli Zaretskii
2016-04-03 16:49 ` Michael Albinus
2016-04-03 14:51 ` bug#23186: 25.0.92; Tramp: Windows does not always set COMSPEC, tramp blows up in a string-match Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACTc7ZkZspUC=v_Tzx2mnXKfMB2xQ52Ojd-PXTgkOq36YgXPbw@mail.gmail.com' \
--to=ja2038@gmail.com \
--cc=23186@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).