From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: tramp Date: 23 Aug 2002 10:26:52 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-14 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1030066122 18770 127.0.0.1 (23 Aug 2002 01:28:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 23 Aug 2002 01:28:42 +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.35 #1 (Debian)) id 17i3Ff-0004sb-00 for ; Fri, 23 Aug 2002 03:28:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17i3in-0003a9-00 for ; Fri, 23 Aug 2002 03:58:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17i3Gc-0000Df-00; Thu, 22 Aug 2002 21:29:38 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17i3EB-000077-00 for emacs-devel@gnu.org; Thu, 22 Aug 2002 21:27:07 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17i3E8-00006s-00 for emacs-devel@gnu.org; Thu, 22 Aug 2002 21:27:07 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17i3E8-00006V-00; Thu, 22 Aug 2002 21:27:04 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g7N1QvG26527; Fri, 23 Aug 2002 10:26:57 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g7N1Qtg28021; Fri, 23 Aug 2002 10:26:56 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g7N1QrG21382; Fri, 23 Aug 2002 10:26:54 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g7N1Qrs14458; Fri, 23 Aug 2002 10:26:53 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id EE7CB36F2; Fri, 23 Aug 2002 10:26:52 +0900 (JST) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-15?q?Gro=DFjohann?=) System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: Original-Lines: 91 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6775 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6775 Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro=DFjohann) writes: > Tramp now has its own variable, tramp-shell-prompt-pattern, that users > can set. The default value is the same as the default value for > shell-prompt-pattern, so it should match the prompts that your examples > showed. I just tried tramp /su:localhost:/etc again today, and it works! Startup's a bit slow though; it'd be nice if all the file-downloading &c could be omitted on a local connection (presumably that couldn't be the default, but it could be configurable). Actually it would be nice to be able to say, for _any_ specific host/user/method combo `I've already installed tools x&y, here's where you can find them. Yet another job for the whizzy per-method/machine/user configuration alist. [I guess there are probably variables for this; I've not checked.] > shell-mode just assumes that everything on the last line is a prompt, > right? Hm. But I think it's not possible for Tramp to assume something > similar. Probably not. > It is vital for Tramp to wait until it sees a shell prompt before > sending something to the remote shell. If you send input to the > remote shell too early, things go wrong in a quite horrible way > (depending on the remote login program that you are using). >=20 > But maybe waiting for the shell prompt is not the right thing to do. > What could Tramp do instead? I don't know; is simply waiting for _some_ output too optimistic? > > (2) In many cases, a shell started by tramp will be in a `different > > context' than a normal user-shell, and so will have a different > > prompt anyway. > > > > Probably it ought to be possible to modify this on a > > per-connection-type and per-machine basis (but presumably that will be > > handled by the whizzy config mechanism that will added to address > > other problems, right?). >=20 > Is it really necessary to modify the regexp like this? Isn't it > enough for the user to set one value which covers all alternatives? Perhaps, but I think for me, it's more natural to think in little bits, for concrete cases, rather than trying to cover all cases with one mondo regexp. It's also possible that there will in fact be conflicts, though I haven't any personal experience of any (e.g., host X uses a shell prompt that actually matches some other non-shell prompt login output on host Y). > If possible, I would like to avoid having too many parameters that > are based on method or machine. >=20 > But I'm having similar arguments about tramp-remote-path. It's also > just one variable, and people are requesting me to make it configurable > on a per-host basis. But I think it is sufficient to have one global > value which contains all the directories on all the hosts. I think this is a much more dangerous assumption than in the prompt case, since what is a trusted directory on one host may not be on another. Since there definitely are parameters which will have to be host/method specific, and that you're better off simply making a general mechanism by which _all_ parameters can be set on a host/method specific manner. E.g., just an alist containing machine/method/user specs, and variables and values, which tramp will run down and do (set (make-local-variable VAR) val) inside the tramp work buffer. Then the code can use simple variables, but the user still gets max flexibility where needed. An example format might be: ((SPEC (VAR . VAL) ...) ...) where SPEC is either a regexp matching the hostname, or a tuple like (HOST USER METHOD) where the components are regexps or nil (meaning match anything). That's what I want. [I haven't looked at tramp's code though, so perhaps the above is not a workable solution.] Thanks, -Miles --=20 Suburbia: where they tear out the trees and then name streets after them.