From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Tue, 20 Dec 2011 07:53:24 -0800 Message-ID: <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> References: <87wr9uuvn3.fsf@gmx.de><1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com><87bor5eyz0.fsf@gmx.de><88D1EF1166814B70B0E2CD052362AA72@us.oracle.com><87ehw0e7u0.fsf@gmx.de><877h1sdzv0.fsf@gmx.de><9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> <87zkend2oe.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1324396455 1472 80.91.229.12 (20 Dec 2011 15:54:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 20 Dec 2011 15:54:15 +0000 (UTC) Cc: 10319@debbugs.gnu.org To: "'Michael Albinus'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 20 16:54:11 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd215-00087N-CN for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Dec 2011 16:54:11 +0100 Original-Received: from localhost ([::1]:48200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd215-0001m8-2c for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Dec 2011 10:54:11 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:46098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd20z-0001lt-A7 for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2011 10:54:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd20y-0008FR-0c for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2011 10:54:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd20x-0008FM-Ty for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2011 10:54:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Rd22s-0000IO-AY for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2011 10:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Dec 2011 15:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10319 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10319-submit@debbugs.gnu.org id=B10319.13243965341103 (code B ref 10319); Tue, 20 Dec 2011 15:56:02 +0000 Original-Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 15:55:34 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd22Q-0000Hk-I6 for submit@debbugs.gnu.org; Tue, 20 Dec 2011 10:55:34 -0500 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd22N-0000Hb-Iv for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 10:55:32 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBKFrUPk006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 15:53:31 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBKFrT00022246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 15:53:30 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBKFrTEe010678; Tue, 20 Dec 2011 09:53:29 -0600 Original-Received: from dradamslap1 (/10.159.57.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Dec 2011 07:53:29 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87zkend2oe.fsf@gmx.de> Thread-Index: Acy+9+9tRTEoZS15Q0GKGlQbSakwegAMxRNg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090201.4EF0AF7C.002C,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 20 Dec 2011 10:56:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.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:55084 Archived-At: > > So what are we trying to tell _users_ here? > > Is this what we are really trying to say? > > > > FILE must be an absolute file name. > > > > If so, what should we say happens if you nevertheless pass > > a relative file name? Return value is unspecified (could > > be nil or non-nil)? An error is raised? What should we > > tell users is the behavior? > > Any relative filename cannot expand to a different remote > connection, or a filename of your local filesystem. But you > are right, this information is irrelevant for the docstring > of `file-remote-p'. "relative file names do not work across remote connections" should be dropped, as it is not clear at all what we're trying to say by it. If we want to say something about relative file names, then it needs to be clear, whatever it is. We really should say what happens if a relative file name is passed as arg. It's still not clear to me, from your statement above. Are you saying that nil is always returned for a relative file name? If so, let's just say that: "Return nil if FILE is a relative file name". (No need to say that you must or should use an absolute name.) If that's not the case, please try again to explain, and I'll propose something else once I understand. (Simple tests seem to indicate that nil is returned.) > >> > We should also perhaps say what "the complete > >> > identification" is/means. IOW, when IDENTIFICATION is nil, > >> > what can we say about the return value? > >> > >> In that case, the returned string could make a local file > >> name remote. We could always offer to apply > >> (concat (file-remote-p "whatever") "local-file-name") > >> given that `concat' accepts nil as argument. > > > > Sorry, I just don't understand your reply to my question > > (what is the complete identification - what is returned if > > IDENTIFICATION is nil). Could you rephrase or elaborate? > > When IDENTIFICATION is nil, the returned string is everything > until the last ":" (with expanded default method, default user, > default host). > > (file-remote-p "/sudo::/") => "/sudo:root@localhost:" > (file-remote-p "/localhost:/") => "/scpc:localhost:" Fine. Let's say that (it's not obvious, IMHO). When IDENTIFICATION is nil, the returned string is a complete remote identifier: with components method, user, and host. The components are those present in FILE, with defaults filled in for any that are missing. > What I have tried to explain is a common technique for creation of new > remote filenames, derived from an existing one. Let's say you have a > variable `file' containing the remote filename "/sudo::/path/to/file", > and you want to create a new remote filename for the file > "/bin/sh". You apply then (concat (file-remote-p file) "/bin/sh") That's a useful tip about another way to _use_ the function, and also not so obvious. Let's say that too. Tip: You can use this expansion of remote identifier components to derive a new remote name from an existing one. For example, if FILE is "/sudo::/path/to/file" then (concat (file-remote-p FILE) "/bin/sh") returns a remote name for file "/bin/sh" that has the same remote identifier as FILE but expanded; a name such as "/sudo:myhost.org:/bin/sh". HTH.