From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.emacs.devel Subject: Re: SCPC Detection Program Date: Tue, 13 Apr 2010 15:56:41 -0400 Message-ID: References: <8739z26jxo.fsf@gmx.de> <87iq7weaz4.fsf@gmx.de> <8739z0wim6.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1271193837 15713 80.91.229.12 (13 Apr 2010 21:23:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 21:23:57 +0000 (UTC) Cc: tramp-devel@gnu.org, emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 23:23:55 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O1naN-000875-3T for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 23:23:55 +0200 Original-Received: from localhost ([127.0.0.1]:42945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1naM-0006Br-GI for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 17:23:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1mE4-0000pt-EK for emacs-devel@gnu.org; Tue, 13 Apr 2010 15:56:48 -0400 Original-Received: from [140.186.70.92] (port=50305 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1mE1-0000pG-UR for emacs-devel@gnu.org; Tue, 13 Apr 2010 15:56:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1mE0-0003bM-K6 for emacs-devel@gnu.org; Tue, 13 Apr 2010 15:56:45 -0400 Original-Received: from mail-iw0-f176.google.com ([209.85.223.176]:53689) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1mDz-0003ax-5Z; Tue, 13 Apr 2010 15:56:44 -0400 Original-Received: by iwn6 with SMTP id 6so5392050iwn.26 for ; Tue, 13 Apr 2010 12:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=lLjNc51E0ZlEFK5AUxCv+cXogzQv5MKOmcfJw5E0liY=; b=eigWtVJHS9fn2VV80nJW8wzzGxa5gK8qh5fkVshpP9sgH20UVLDEkN6cYr6EII4OUr +7EEVIk3FBQlIVGwTRmWv2WI1aumprQirvU9XEOrrk7Mk5y8bdjS7aUYqSXSsdsyxuHZ hsUbs2jqjT9ouaXMVNqSowvn6pM4BgoWQAXa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iEQztiVZ+ZEElXKEiY2jMv8leXZHDEkYb045rmBkMNE8znYe1rpCHrn73ZqvIlGMpy inb6hIfw7ebEIqlONg0Jg4s6F9VvdPUgGIoSbiD4/jHMTPIlDm1Yqz+B3FkQ0kyFDBiE WsPibgvqOx0zDBDq2gcNcPe+cc6dcAhAg/Pzk= Original-Received: by 10.231.37.2 with HTTP; Tue, 13 Apr 2010 12:56:41 -0700 (PDT) In-Reply-To: <8739z0wim6.fsf@gmx.de> Original-Received: by 10.231.156.205 with SMTP id y13mr2851775ibw.27.1271188601824; Tue, 13 Apr 2010 12:56:41 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Tue, 13 Apr 2010 17:23:47 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123600 Archived-At: Hi Michael, I was thinking about it, and the help string idea does seem better than version numbers, especially if it turns out that several different SSH implementations use similarly-formatted help strings. I think I will check the formatting of a few different version and help strings before coding more. However, I thought of an alternate possibility. What if tramp first saves the version string of ssh, then tries a connection with ControlMaster to see if it works, and then remembers whether this worked or not? Then it would choose a method for future connections based on the results of the test until the version string changed, at which point it would experiment again. That way it would have to run a test connection only when the user updated their ssh installation, which seems infrequent enough to be reasonable, and it would have the advantage that we wouldn't have to keep any sort of whitelist of ssh programs or help string formats. Noah On Mon, Apr 12, 2010 at 3:55 PM, Michael Albinus wrote: > Noah Lavine writes: > >> Hi Michael, > > Hi Noah, > >> I checked with my version of ssh, and we would indeed be able to >> detect this from its help version string. However, it seems like this >> could have similar fragility issues as the version number idea, if the >> help string changed format some time. You could solve this by only >> trying scpc on help strings that are known to be good, but you could >> also have a version number whitelist that would serve the same >> purpose. It seems like both of these would work and would be quite >> similar - is there a reason to think that one would be better than the >> other? > > I have no bullet-proof reason. But your version test depends on > underlying OpenSSH, and its version numbering scheme. What if other ssh > implementations will support this option as well? Therefore, the version > check seems to be more fragile to me than the "-M" option. Again, it is > just a feeling. > > Another test could be the following: > > $ ssh -o ControlMaster=auto wrong-host > ssh: Could not resolve hostname wrong-host: Name or service not known > > This would indicate, that the option is supported. Unsupported options > return the following error message: > > $ ssh -o ControlMasterr=auto wrong-host > command-line: line 0: Bad configuration option: ControlMasterr > >> As for the test connection, maybe a change would help. It's probably >> not good to try connecting to a known-good host, but what about trying >> it with the host that Tramp needs to connect to anyway? You could try >> it first with the -ControlMaster option, and if ssh gave an error, >> then try again without it and fall back on the other method. This >> wouldn't create more ssh connections than necessary. The problem I see >> is that it might require a more substantial change to the Tramp >> codebase than the other methods, but I don't know, because I haven't >> looked around enough to see. Do you think this method would be useful >> enough to make it worth looking through the Tramp code more and maybe >> making bigger changes? > > Yes, this would require deeper changes in Tramp's workflow, which I > would like to avoid. And it might discriminate users for whom the test > fails, because they would *always* need to spend the time for that > failed test. > >> Noah > > Best regards, Michael. >