unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Eli Zaretskii" <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: executable-find in files.el
Date: Thu, 12 May 2005 01:56:43 +0300	[thread overview]
Message-ID: <01c5567c$Blat.v2.4$d8bc9c20@zahav.net.il> (raw)
In-Reply-To: <87fywt6128.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Wed, 11 May 2005 15:07:36 -0400)

> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 11 May 2005 15:07:36 -0400
> 
> > 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.

> What do you reply to that?

Did you read my message?  That's my answer to it.

> 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.

  reply	other threads:[~2005-05-11 22:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1DVuFh-0001h1-GE@monty-python.gnu.org>
2005-05-11 18:29 ` executable-find in files.el Eli Zaretskii
2005-05-11 19:07   ` Stefan Monnier
2005-05-11 22:56     ` Eli Zaretskii [this message]
2005-05-11 23:16       ` Stefan Monnier
2005-05-11 23:50         ` David Kastrup
2005-05-12  1:31           ` Stefan Monnier
2005-05-12  6:34         ` Eli Zaretskii
2005-05-12 12:42           ` Stefan Monnier
2005-05-12 13:14             ` Eli Zaretskii
2005-05-14 14:58     ` Michael Albinus
2005-05-15  0:21       ` Richard Stallman
2005-05-16 19:27         ` Michael Albinus
2005-05-16 22:38           ` Stefan Monnier
2005-05-17 22:03             ` Kim F. Storm
2005-05-17 22:23               ` Stefan Monnier
2005-05-18 13:08                 ` Richard Stallman
2005-05-17  4:36           ` Richard Stallman
2005-05-17 16:32             ` Michael Albinus
2005-05-18  5:19               ` Richard Stallman
2005-05-18 13:08           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01c5567c$Blat.v2.4$d8bc9c20@zahav.net.il' \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).