From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jerry Asher Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <831t6nsyzy.fsf@gnu.org> <87a8lbpzbv.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114587da57f05b052f8619e4 X-Trace: ger.gmane.org 1459627944 10592 80.91.229.3 (2 Apr 2016 20:12:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2016 20:12:24 +0000 (UTC) Cc: 23186@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 02 22:12:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1amRu3-0008G4-Eo for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Apr 2016 22:12:15 +0200 Original-Received: from localhost ([::1]:50842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRty-0001wJ-S8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Apr 2016 16:12:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRtu-0001vv-3M for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 16:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amRtq-0008HE-Pd for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 16:12:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRtq-0008Gd-Jw for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 16:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1amRtq-0001mA-9G for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 16:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jerry Asher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Apr 2016 20:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23186 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23186-submit@debbugs.gnu.org id=B23186.14596278886785 (code B ref 23186); Sat, 02 Apr 2016 20:12:02 +0000 Original-Received: (at 23186) by debbugs.gnu.org; 2 Apr 2016 20:11:28 +0000 Original-Received: from localhost ([127.0.0.1]:49168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1amRtH-0001lN-R1 for submit@debbugs.gnu.org; Sat, 02 Apr 2016 16:11:28 -0400 Original-Received: from mail-vk0-f44.google.com ([209.85.213.44]:34875) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1amRtG-0001lA-8W for 23186@debbugs.gnu.org; Sat, 02 Apr 2016 16:11:26 -0400 Original-Received: by mail-vk0-f44.google.com with SMTP id e6so139746834vkh.2 for <23186@debbugs.gnu.org>; Sat, 02 Apr 2016 13:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nz9kMhIo+MvODbRSO/mCBI5Z7HToBYpsRyOqG3Y+DOM=; b=gbPBWIk08hAuYJogkey9HQXrDFrOvIwIOA2czVGwFWRcA7HUu80CRTCjJWBqxnV6ze /g3bQ2EmrUn9CI89G475ixp3bcpyiPEXGW4b2n7+ODq3g98fxtuD22PwSmK/7rhFl1wE ljKftNu37Dj15cZaBOnb3dV9+kl/7u+O7BBZGESIeJsxWvyg1u08X/eqEQtGIinqFsFO fRAs/mjsmDpOqBnPgJg4Zun+jR3j4bQa/oaBYUzp2pm55a1y9aj2Y708RcNKMEGq0Upm ZoYlbODzL6gQ6oeyYaDD4IkVNjrIiAsLnbQmxJU56rcYy6Wjsqfy4Ds4VyvlbXmC/pKJ oeGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nz9kMhIo+MvODbRSO/mCBI5Z7HToBYpsRyOqG3Y+DOM=; b=U4vXnPKipMpUcdoDBUFyblJEcPCd+qgBECcV4o4+fo3tSuozxQdO3KBvGTTC1+/YND fM7PHOySf8fUkyW+eCYXHfaBtN8rp9hvAsj5P8Ow52QbnE62iTZOjOvdh77finnAQTfM jBPSNk0th728zrp1TXD3Pr7f44Nm4Qxq1LlJMMiBYiKqcErsqLZrITIOZurUHz11H86g OSjGOtq/V1z7flIPuaPML4HwMqmF7bfZ9h0ZKJCQAih3O69A/OzSG7MLzBbgJA9HCzx0 8os/RaXDMnZXJS/Vt+QlMafEcR/oIeJt0o/8u6i7+PH25Fw+6E9wXZtmZgrrnDVb7A5G uREQ== X-Gm-Message-State: AD7BkJKqcZZFHadqCaelQe8wW5TKWI6dbIqvpPanQP6EHBS9OXAO3pT1la6aCE0FFhHWc5CPUwbqVd3RGjtY2Q== X-Received: by 10.31.131.14 with SMTP id f14mr4194852vkd.148.1459627880868; Sat, 02 Apr 2016 13:11:20 -0700 (PDT) Original-Received: by 10.103.45.74 with HTTP; Sat, 2 Apr 2016 13:11:01 -0700 (PDT) In-Reply-To: <87a8lbpzbv.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115894 Archived-At: --001a114587da57f05b052f8619e4 Content-Type: text/plain; charset=UTF-8 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 wrote: > Jerry Asher 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. > --001a114587da57f05b052f8619e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the response Michael.

Clearl= y 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 propo= sed 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 mor= e fragile
+ Being given a vague demand to produce more evidence a= nd no instructions on what was needed or how to supply it
What is the full contents of the enviro= nment of the Emacs process when
you run that zapped binary?
=

And then to have a defamatory slur placed in the bug repo= rt.

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

>=C2=A0Your first proposal, trusting C:\Windows\system32\cmd.exe, hasn't b= een
accepted, by reasons Eli h= as given. And indeed, it looks too me like too
much heuristic, so I'm with E= li.

I don't even know what that means.=C2=A0

As I said:

+ &= quot;C:\Windows\system32\cmd= .exe"=C2=A0 THIS WAS LITERALLY NOT WHAT I PROPOSED
+ Regardless, when COMSPEC is not defined, assigning NIL to tramp-encodin= g-shell CERTAINLY IS WRONG.
+ Other people are seeing this proble= m too, google it as I showed you.

Since you are th= e maintainer, I would never deign to claim I know more than you do about TR= AMP

So please Michael,=C2=A0

<= div>+ bug reporters are often NOT the best person to analyse or propose a s= olution.
+ When COMSPEC is not defined, assigning NIL to tramp-en= coding-shell CERTAINLY IS WRONG.
+ Other people see this prob= lem too.,

WHAT DO YOU THE MAINTAINER PROPOSE as a = solution?

Since I am not a windows developer, I th= ink 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 supp= osed 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 set= ting it to NIL.

Once more, I am not a windows deve= loper, you are the maintainer, I have reported a bug, a bug felt not just b= y 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 wou= ld 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:
=

AS THE TRAM= P MAINTAINER, WHAT DO YOU SUGGEST TO FIX THIS BUG?

Thank you for your attention,

Jerry


On Sat, Apr 2, 2016 at 12:4= 7 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 thin= k it
>> would be unreasonable for anyone to expect the Tramp maintainers t= o
>> 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 ther= e
>> 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. Mak= e
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<= br> 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.

--001a114587da57f05b052f8619e4--