From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: testing for a remote file to include file on a Windows mappeddrive Date: Sat, 26 Jan 2008 23:15:08 +0100 Message-ID: <87bq781bf7.fsf@gmx.de> References: <871w844yff.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1201385484 12716 80.91.229.12 (26 Jan 2008 22:11:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2008 22:11:24 +0000 (UTC) Cc: Jason Rumney , Drew Adams , Emacs-Devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 23:11:42 2008 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.50) id 1JItFV-0006Ws-Ry for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 23:11:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JItF5-0001eZ-Ar for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 17:11:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JItEt-0001Vm-NY for emacs-devel@gnu.org; Sat, 26 Jan 2008 17:11:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JItEr-0001TZ-P1 for emacs-devel@gnu.org; Sat, 26 Jan 2008 17:11:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JItEr-0001T6-Gh for emacs-devel@gnu.org; Sat, 26 Jan 2008 17:11:01 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JItEq-0000TB-Vc for emacs-devel@gnu.org; Sat, 26 Jan 2008 17:11:01 -0500 Original-Received: (qmail invoked by alias); 26 Jan 2008 22:10:59 -0000 Original-Received: from p57A23F24.dip0.t-ipconnect.de (EHLO arthur.local) [87.162.63.36] by mail.gmx.net (mp026) with SMTP; 26 Jan 2008 23:10:59 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX1/1VoFdrgL1BlQJ/f1bqIjwupEVincGhnF9eiM2Ji 6yKC9an7qwTF4/ In-Reply-To: (Stefan Monnier's message of "Sat, 26 Jan 2008 14:24:10 -0500") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:87606 Archived-At: Stefan Monnier writes: >> file-remote-p returns information about the *file name*, and not >> necessarily about the file: "Can the file name be used literally on the >> local host?" I believe this meaning shall be kept, for example, it is >> needed to determine whether a file name must be trimmed when used as >> argument of process-file and alike. > >> The new function you are looking for is file-mounted-p or so. > > I believe you're wrong and I'm right ;-) For sure. At least it has been the case almost ever when we did discuss. > What you consider as the meaning of `file-remote-p' is pretty close to > the info returned by (let ((file-name-handlers-alist nil)) (not > (file-readable-p ))), whereas what you want to call > `file-mounted-p' is much closer to what `file-remote-p' currently does. > > E.g. (file-remote-p "/:/") will return nil, even though passing "/:/" as > an argument to a subprocess will likely fail to do what was intended. > > After all, whether the filename can be passed to a subprocess has > nothing to do with whether or not it's "remote". Hmm. I haven't said that the result of `file-remote-p' is the only check how to pass a file name as argument to a subprocess. But when `file-remote-p' returns non-nil, it means that you can't take the related file literally as part of ARGS in 'process-file' and friends. > I suggest we clarify the meaning of file-remote-p to explain that it > returns info that relates to the time and reliability of the access to > this file. And we introduce a new one `unhandled-file-name' which > returns either "an equivalent name that can passed to subprocesses" > (e.g. for the "/:/" file-name-handler, it just strips the leading "/:" > and similarly for the "file://" one) or nil if the file cannot be > directly accessed by a subprocess (either because it's only accessible > via ssh/ftp/tar/younameit it by a file-name-handler). At least for remote files I've introduced it silently ... (file-remote-p "/sudo::/etc" 'localname) returns "/etc". But you are right, `unhandled-file-name' would be more general but just for Tramp. But we shall come back to the original request of Drew: he wants to know whether a given file is "remote", independant of the syntax. Such information cannot be provided by 'file-remote-p', because that function has an important promise: "`file-remote-p' will never open a connection on its own." (from the doc-string). It also doesn't touch a local file; it works completely over the file name syntax. This promise is important because of performance. Rough idea: maybe one could use the device number, returned as last attribute of `file-attributes', for a check whether a file has been "mounted". I haven't seen code evaluating the device number. And I don't know whether it is set to a useful value on W32, for example. Just for the records, ange-ftp sets it to -1, and Tramp returns (-1 x) with x being a unique number for different remote connections. > Stefan Best regards, Michael.