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: executable-find in files.el Date: Thu, 12 May 2005 16:14:11 +0300 Message-ID: <01c556f4$Blat.v2.4$a2333100@zahav.net.il> References: <01c55657$Blat.v2.4$7979dc20@zahav.net.il> <87fywt6128.fsf-monnier+emacs@gnu.org> <01c5567c$Blat.v2.4$d8bc9c20@zahav.net.il> <87zmv12wig.fsf-monnier+emacs@gnu.org> <01c556bc$Blat.v2.4$cc9849e0@zahav.net.il> <8764xo39nx.fsf-monnier+emacs@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1115904722 14322 80.91.229.2 (12 May 2005 13:32:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 May 2005 13:32:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 12 15:31:58 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DWDmE-0006yM-1m for ged-emacs-devel@m.gmane.org; Thu, 12 May 2005 15:30:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DWDvA-00006M-QG for ged-emacs-devel@m.gmane.org; Thu, 12 May 2005 09:40:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DWDrD-0005e7-ED for emacs-devel@gnu.org; Thu, 12 May 2005 09:36:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DWDrC-0005dU-L4 for emacs-devel@gnu.org; Thu, 12 May 2005 09:36:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DWDop-00048w-Bd for emacs-devel@gnu.org; Thu, 12 May 2005 09:33:39 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DWDg9-000367-Nh for emacs-devel@gnu.org; Thu, 12 May 2005 09:24:41 -0400 Original-Received: from zaretski (IGLD-83-130-254-105.inter.net.il [83.130.254.105]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BEX24072 (AUTH halo1); Thu, 12 May 2005 16:17:42 +0300 (IDT) Original-To: Stefan Monnier X-Mailer: emacs 22.0.50 (via feedmail 8 I) and Blat ver 2.4 In-reply-to: <8764xo39nx.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Thu, 12 May 2005 08:42:32 -0400) 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:37033 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37033 > Cc: emacs-devel@gnu.org > From: Stefan Monnier > Date: Thu, 12 May 2005 08:42:32 -0400 > > > . on Windows, check_executable uses stat to verify executability > > . on Posix systems, check_executable uses euidaccess if it's available > > . by contrast, openp always uses access > > > These are subtle differences, but they are real. > > These are too subtle for me, indeed. Are you saying that: > 1- call-process on w32 doesn't use check_executable but should > 2- are you saying that call-process on w32 does use check_executable whereas > a "1" arg to locate-file doesn't, and thus that a `file-executable-p' arg > to locate-file better mimicks call-process on w32. > > If (1), it's beyond the scope of my patch. I don't think the Windows port does something special inside `call-process', I think it uses `openp' as every other platform, and thus does _not_ use `check_executable' and what's in it. What I'm saying is that `stat' and `access' on Windows might yield different results (someone with more knowledge about Windows internals than I have should give a definitive answer to that). More importantly, Posix platforms which have `euidaccess' will behave differently in these two cases, because AFAIK, `euidaccess' and `access' might yield different results. I don't know enough about intricacies of `access' and `euidaccess' to tell which one is TRT for us, but I do think that both `openp' and `check_executable' should use the same code, whichever we think is the right one. (That is, unless someone explains why using `access' in some cases and `euidaccess' in others _is_ TRT.) As long as `file-executable-p' and `call-process' use these different methods, your change to `executable-find' is an incompatible one, albeit only in some rare situations.