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 14:09:36 -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> <83ha8d1r1c.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391627405 15474 80.91.229.3 (5 Feb 2014 19:10:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 19:10:05 +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 20:10:13 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 1WB7rO-0003RO-JQ for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 20:10:10 +0100 Original-Received: from localhost ([::1]:32857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB7rO-0002AB-5J for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 14:10:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB7r5-0001oA-Dc for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:09:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB7qz-0007V6-7I for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:09:51 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB7qs-0007UG-1U; Wed, 05 Feb 2014 14:09:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDMEhkQoDiGGYaIMxgV6DFQ X-IPAS-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDMEhkQoDiGGYaIMxgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46859561" 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 14:09:36 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D4E7A603AE; Wed, 5 Feb 2014 14:09:36 -0500 (EST) In-Reply-To: <83ha8d1r1c.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Feb 2014 18:07:59 +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:169421 Archived-At: > (file-name-directory "http://foo.com/wherever/index.html") > => "http://foo.com/wherever/" > (file-name-absolute-p "http://foo.com/wherever/index.html") > => nil That look reasonable (and didn't involve any remote connection or any such problem). And faccess("http://foo.com/wherever/") should presumably tell you that dir doesn't exist. So it behaves just as well as the current code. > Moreover, no one said that any particular DOCUMENT that is passed to > this function will have an Emacs file handler. Indeed, I made no such assumption. >> 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. I can agree for expand-file-name. I was talking only about the file-name-directory and file-name-absolute-p calls. >> - 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. The connection between the core problem of detecting the case of (w32-shell-execute "dir/file") and the check of file-name-handlers is really non-obvious. >> - we only check (faccess dir) rather than (faccess file), and only if >> there's a "dir". > What is "dir" here? See my sample code: (file-name-directory file) >> - 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 think we only need to use w32's own notion of "absolute". But using file-name-absolute-p should work as well. Stefan