From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: how to find out methods for tramp? Date: Wed, 19 Jun 2002 14:28:29 +0000 (UTC) Sender: emacs-devel-admin@gnu.org Message-ID: References: Reply-To: bob@rattlesnake.com NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1024497040 9075 127.0.0.1 (19 Jun 2002 14:30:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2002 14:30:40 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17KgTo-0002MG-00 for ; Wed, 19 Jun 2002 16:30:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Kgv2-0000kW-00 for ; Wed, 19 Jun 2002 16:58:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17KgTN-0000zN-00; Wed, 19 Jun 2002 10:30:13 -0400 Original-Received: from megalith.rattlesnake.com ([140.186.114.245] helo=localhost) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17KgRo-0000tT-00 for ; Wed, 19 Jun 2002 10:28:36 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.114) Wed, 19 Jun 2002 14:28:29 +0000 (UTC) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4989 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4989 "Robert J. Chassell" writes: > The problem is, the only way I could choose one method instead of > another was to try a whole bunch of methods. That is the problem and > is inefficent. This is bad. I agree with Eli and Richard that this means that the manual needs to be fixed. Thanks a lot for finding this problem. Can you say which kind of explanation would have helped you to find the right method quickly? Ideally, Tramp should try additional methods if the method you use fails (with an option to turn off this feature by setting a variable). In any case, messages that go to the *Message* buffer should be more helpful in telling what happened. They should tell you `mimencode' not found on this machine; try a Tram method using `uuencode', which is found on this machine Tramp method `sm' confused by extra questions to SSH; try `smx' SSH fails; try a telnet method, such as `tm' [[Yes, there was a period, after their system administrator died unexpectely, when my ISP permit insecure telnet connections from anywhere, but prevented secure SSH connections -- just the opposite of what had been intended...]] Maybe the right way to explain it is to start from the user's situation. We should get the user to log in to the remote host from the command line. The command used there will tell us something about which methods are applicable. This is what I have been doing. That is how I know that one of the machines I connect to lacks `mimencode'. This method should be a last resort, since it is so inefficient. It is a way to track down bugs, not a way to get tramp working on 15 different machines, some running non-GNU operating systems, such as SunOS, as 16 different users. Then we could tell the user to issue commands like "type mimencode" and "type uuencode", as you have used. This will tell us more about the applicable methods. This kind of information should be in the `Recovery from Problems' section. It is useful for helping people to report bugs. If Tramp is able to connect, it should be able to run `type mimencode' automatically if need be. -- Robert J. Chassell bob@rattlesnake.com Rattlesnake Enterprises http://www.rattlesnake.com