emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: executable-find in files.el


From: Stefan Monnier
Subject: Re: executable-find in files.el
Date: Wed, 11 May 2005 19:16:46 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> > Passing 1 as last arg of locate-file is subtly different from passing
>> > file-executable-p.  I think the latter does a better job, so I think
>> > executable-find should use file-executable-p.
>> 
>> Have you read the comment you quoted?

> Yes.  But since you obviously didn't read my identical comment posted
> in response to your suggestion to do what you just did in this version
> of executable-find (or perhaps you read it, but disregarded it), I
> posted the same comment again.

Hmm... I replied to it in
http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00381.html but
haven't seen any answer.

>> Do you think it's more important to "do a subtly better job" or to "match
>> the behavior of call-process"?

> I think they should do the same.  But the original executable-find
> used file-executable-p, so your change is subtly incompatible, unless
> you change openp to use the same method as file-executable-p.

>> In my view, the point of executable-find is to figure out whether there is
>> a command that we can run.  If it tells us "I found /ssh:foo/bar/baz", but
>> then call-process fails because it doesn't work through Tramp, I think it's
>> a problem.

> I agree.  But the solution should be to make all 3 of these do exactly
> the same job in exactly the same way.

Fine, but as long as noone changes call-process to do something meaningful
when requested to execute a file which is only available via
a file-name-handler, I think we should stick to 1 because I think it's more
important to match the behavior of call-process (as I wrote in the comment).

But, really, this is all academic anyway since I don't know of anyone who
has funny file-name-handled directories on her exec-path.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]