From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names. Date: Wed, 05 Feb 2014 18:07:59 +0200 Message-ID: <83ha8d1r1c.fsf@gnu.org> References: <83ob2q4nbv.fsf@gnu.org> <83k3de41sc.fsf@gnu.org> <83iosx4iid.fsf@gnu.org> <83txcg3fle.fsf@gnu.org> <83lhxs2mru.fsf@gnu.org> <837g9a3kmb.fsf@gnu.org> <83vbwu1tk2.fsf@gnu.org> <83r47i1acs.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1391616500 1973 80.91.229.3 (5 Feb 2014 16:08:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 16:08:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 17:08:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WB51Q-00076R-Fh for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 17:08:20 +0100 Original-Received: from localhost ([::1]:59932 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB51Q-000171-15 for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 11:08:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB51I-00016S-4C for emacs-devel@gnu.org; Wed, 05 Feb 2014 11:08:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB51C-0002OC-Hs for emacs-devel@gnu.org; Wed, 05 Feb 2014 11:08:11 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:52911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB51C-0002O7-4I for emacs-devel@gnu.org; Wed, 05 Feb 2014 11:08:06 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N0J00G005VJ9800@mtaout27.012.net.il> for emacs-devel@gnu.org; Wed, 05 Feb 2014 18:06:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0J0089D63J9LA0@mtaout27.012.net.il>; Wed, 05 Feb 2014 18:06:56 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169413 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Wed, 05 Feb 2014 09:10:46 -0500 > > >> (if (file-name-absolute-p file) > >> (let ((dir (file-name-directory file))) > >> (if (null dir) > >> (if (faccess dir) > >> )))) > > Yes, except that the primitives you use here only work on file names, > > and might go bananas when presented with something else, e.g. a URL. > > AFAIK all magic file-name handlers will do something reasonable with > the above (file-name-absolute-p file) and (file-name-directory file). Not really: (file-name-directory "http://foo.com/wherever/index.html") => "http://foo.com/wherever/" (file-name-absolute-p "http://foo.com/wherever/index.html") => nil Moreover, no one said that any particular DOCUMENT that is passed to this function will have an Emacs file handler. > But we could also let-bind file-name-handlers-alist to nil around those > calls (or use lower level code which does something similar). We do the latter. I don't think the former is a good idea, because I think at least expand-file-name should allow its handler to run, e.g. for use cases like cygwin-mount. > We don't need to call the Elisp primitives since we really only care > about the system-level's notion of absolute file name and file name > separator. Right; and we don't. > - we don't check file-name-handlers Why is that a good idea? If a file name has a handler, any success in faccess etc. can only be a (rare) coincidence. > - we only check (faccess dir) rather than (faccess file), and only if > there's a "dir". What is "dir" here? > - we don't bother with any of it if the file is already absolute. See above: deciding whether it is absolute is not easy. I'm afraid we will need most of expand-file-name's code for that anyway.