From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 09:10:46 -0500 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391609468 8244 80.91.229.3 (5 Feb 2014 14:11:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 14:11:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 15:11:14 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 1WB3C5-0005Aj-40 for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 15:11:13 +0100 Original-Received: from localhost ([::1]:59446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB3C4-0005n5-Kf for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 09:11:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB3Bv-0005de-0K for emacs-devel@gnu.org; Wed, 05 Feb 2014 09:11:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB3Bn-000351-Mm for emacs-devel@gnu.org; Wed, 05 Feb 2014 09:11:02 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB3Bf-00033v-VR; Wed, 05 Feb 2014 09:10:48 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46827576" Original-Received: from 69-165-144-70.dsl.teksavvy.com (HELO pastel.home) ([69.165.144.70]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2014 09:10:47 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E8C76606BB; Wed, 5 Feb 2014 09:10:46 -0500 (EST) In-Reply-To: <83r47i1acs.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Feb 2014 05:56:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169411 Archived-At: >> (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). 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 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. > So using the above does not solve the basic problem, which is: do we > have a file name on our hands or something else? The faccess test is > the only thing that provides us with some assurance. The difference I suggest is: - we don't check file-name-handlers - we only check (faccess dir) rather than (faccess file), and only if there's a "dir". - we don't bother with any of it if the file is already absolute. Stefan