Re: executable-find in files.el

Re: executable-find in files.el

[Eli Zaretskii]

> 
> + (defun executable-find (command)
> +   "Search for COMMAND in `exec-path' and return the absolute file name.
> + Return nil if COMMAND is not found anywhere in `exec-path'."
> +   ;; Use 1 rather than file-executable-p to better match the behavior of
> +   ;; call-process.
> +   (locate-file command exec-path exec-suffixes 1))

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.

Re: executable-find in files.el

[Stefan Monnier]

>> + (defun executable-find (command)
>> +   "Search for COMMAND in `exec-path' and return the absolute file name.
>> + Return nil if COMMAND is not found anywhere in `exec-path'."
>> +   ;; Use 1 rather than file-executable-p to better match the behavior of
>> +   ;; call-process.
>> +   (locate-file command exec-path exec-suffixes 1))

> 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?  What do you reply to that?
Do you think it's more important to "do a subtly better job" or to "match
the behavior of call-process"?
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.


        Stefan

Re: executable-find in files.el

[Eli Zaretskii]

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

Re: executable-find in files.el

[Stefan Monnier]

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

Re: executable-find in files.el

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

M-x eshell RET

Welcome to the Emacs shell

/tmp $ cd /fencepost.gnu.org:
/ssh:fencepost.gnu.org:/home/d/dak $ echo "\input story \bye" >junk.tex
/ssh:fencepost.gnu.org:/home/d/dak $ tex junk

/ssh:fencepost.gnu.org:/home/d/dak $ cat junk.log
This is TeX, Version 3.14159 (Web2C 7.4.5) (format=tex 2005.4.18)  11 MAY 2005 19:44
**junk
(./junk.tex (/usr/share/texmf/tex/plain/base/story.tex [1]) )
Output written on junk.dvi (1 page, 668 bytes).
/ssh:fencepost.gnu.org:/home/d/dak $ 

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: executable-find in files.el

[Stefan Monnier]

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

> M-x eshell RET
[...]

I don't see any funny file-name-handled directories in the exec-path in
your example.  The key here is *exec-path*.


        Stefan

Re: executable-find in files.el

[Eli Zaretskii]

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

That's not the comment I meant.  I meant what I said here:

  http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00379.html

which got no responses.

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

I think we don't know what is more important.  Software is funny: it
can use the infrastructure in ways that are unimaginable when the
infrastructure was written.  That is why infrastructure needs to be
consistent.  I'm sure I'm not saying anything you didn't already know.

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

That's not the only difference between openp and file-executable-p.
Please compare check_executable and openp, and you will see that:

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

Re: executable-find in files.el

[Stefan Monnier]

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

> That's not the comment I meant.  I meant what I said here:

>   http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00379.html

> which got no responses.

I don't see any difference in actual content.  Both messages basically say
"subtle differences, thus file-executable-p", so msg00379 is also the answer
I'd have given.

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

> I think we don't know what is more important.  Software is funny: it
> can use the infrastructure in ways that are unimaginable when the
> infrastructure was written.  That is why infrastructure needs to be
> consistent.  I'm sure I'm not saying anything you didn't already know.

Of course, I don't know, but I grepped for uses and they seem to corroborate
my intuition.

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

> That's not the only difference between openp and file-executable-p.
> Please compare check_executable and openp, and you will see that:

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


        Stefan

Re: executable-find in files.el

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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.

Re: executable-find in files.el

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Tramp does not consider `exec-path' (it uses `tramp-remote-path'
instead of). The reason is that `exec-path' would be ambiguous for
Tramp - it is needed to find local executables (say "ssh") and remote
ones.

I agree with Stefan that, as long as `file-executable-p' returns
meaningful values for remote files, there must be a meaning for
`exec-path', `executable-find' and `start-process' as well in the
remote case.

For `call-process' this has been done already, although I don't
understand why a new function (`process-file') was needed. Otherwise
the problem mentioned by Stefan wouldn't exist.

>         Stefan

Best regards, Michael.

Re: executable-find in files.el

[Richard Stallman]

I am having trouble understanding your message.

    I agree with Stefan that, as long as `file-executable-p' returns
    meaningful values for remote files, there must be a meaning for
    `exec-path', `executable-find' and `start-process' as well in the
    remote case.

I can't translate the second half of that sentence into a concrete
meaning.  What concrete cases are you talking about?

    For `call-process' this has been done already,

What is "this"?

						   although I don't
    understand why a new function (`process-file') was needed.

process-file looks for a file handler.  It would be incorrect
for call-process to do that; it is NOT meant as an operation
on a file.

Re: executable-find in files.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> I am having trouble understanding your message.
>
>     I agree with Stefan that, as long as `file-executable-p' returns
>     meaningful values for remote files, there must be a meaning for
>     `exec-path', `executable-find' and `start-process' as well in the
>     remote case.
>
> I can't translate the second half of that sentence into a concrete
> meaning.  What concrete cases are you talking about?

Sorry for being too short. I wanted to say that there should be a
general concept for running commands on remote hosts. Given that a
command is an executable file, I believe the same mechanism used for
remote files via file name handler could be used.

For `file-executable-p' that is implemented already (but this is a
simple file name operation). For `start-process' and `call-process' I
would prefer to have such a mechanism as well. Determining the file to
be executed as command IS a file name operation, so it would make sense
to extend both commands for that case (running on remote hosts).

`exec-path' and `executable-find' could be extended in the same way:
`exec-path' could provide a list of directories to be searched on a
remote host (yes, I see the problem of ambiguity), and
`executable-find' would return the path name on remote hosts. That's
what Stefan has said: `executable-find' returns already remote path
names, but the result is not useful for `call-process'.

>     For `call-process' this has been done already,
>
> What is "this"?

Oh, I was too short, again. "This" means "provide the possibility to
run a command on a remote host ...". It does not mean yet "... via
`call-process'".

> 						   although I don't
>     understand why a new function (`process-file') was needed.
>
> process-file looks for a file handler.  It would be incorrect
> for call-process to do that; it is NOT meant as an operation
> on a file.

I'm really happy to have `process-file' as mean for running remote
commands. But during migrating existing packages, the drawback has
been obvious: Everywhere there is the need of checking a command for
being remote or not, and then to call `process-file' or
`call-process'. If `call-process' would be able to handle remote
commands, most of the cases nothing would be needed to be changed -
the existing code would simply work. And the same for `start-process'.

An example is `compile': Internally, it uses `start-process'. Tramp
provides a dingy redefinition using `shell-command' (I can say it
offending because I've written it partly by myself). See tramp-util.el.

Best regards, Michael.

PS: Unfortunately for this discussion, I'll start a trip on Wednesday
being mostly offline next 4 weeks. Please be patient when I don't
respond immediately.

Re: executable-find in files.el

[Stefan Monnier]

> Sorry for being too short. I wanted to say that there should be a
> general concept for running commands on remote hosts. Given that a
> command is an executable file, I believe the same mechanism used for
> remote files via file name handler could be used.

Just for the record, we have to distinguish the idea of running a command
remotely and running locally a remote command.


        Stefan

Re: executable-find in files.el

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Just for the record, we have to distinguish the idea of running a command
> remotely and running locally a remote command.

You lost me there ...  Can you give examples to show the difference?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: executable-find in files.el

[Stefan Monnier]

>> Just for the record, we have to distinguish the idea of running a command
>> remotely and running locally a remote command.

> You lost me there ...  Can you give examples to show the difference?

Running a command remotely is something like

        ssh <remotehost> <command>

whereas running a remote command locally is something like

        scp <remotecommand> /tmp/foo; /tmp/foo

This latter one is rarely used via SSH, but very commonly via NFS.


        Stefan

Re: executable-find in files.el

[Richard Stallman]

    Running a command remotely is something like

	    ssh <remotehost> <command>

    whereas running a remote command locally is something like

	    scp <remotecommand> /tmp/foo; /tmp/foo

If instead of "command" you say "executable", the distinction will be
clearer.  I'd say the second example does not make sense with
commands, only with executables.

Re: executable-find in files.el

[Richard Stallman]

    Sorry for being too short. I wanted to say that there should be a
    general concept for running commands on remote hosts.

I would not say that it is a priority for Emacs to have such a thing.
I think it would be a difficult thing to do.  However, if you design
one and the design is good, I would be glad to accept it.

Not now, however.  It should wait for after the release.

    Everywhere there is the need of checking a command for
    being remote or not, and then to call `process-file' or
    `call-process'.

I don't understand "checking a command for being remote or not".
I have no idea what this is talking about.

    If `call-process' would be able to handle remote
    commands,

I cannot envision any way in which that could make sense.  I have no
idea what it would mean for `call-process' to "handle" remote
commands.

Re: executable-find in files.el

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     Sorry for being too short. I wanted to say that there should be a
>     general concept for running commands on remote hosts.
>
> I would not say that it is a priority for Emacs to have such a thing.
> I think it would be a difficult thing to do.  However, if you design
> one and the design is good, I would be glad to accept it.
>
> Not now, however.  It should wait for after the release.

OK, I'll come back to this later on.

>     Everywhere there is the need of checking a command for
>     being remote or not, and then to call `process-file' or
>     `call-process'.
>
> I don't understand "checking a command for being remote or not".
> I have no idea what this is talking about.

"checking whether a command will be executed on a local or a remote
host". Stefan pointed already to this inaccuracy of mine.

One could argue that just calling `process-file' should be
sufficient. But it isn't for packages which still want to support
Emacs 21. Supporting `call-process´ for commands on remote hosts would
result in no change for such packages in the best case. 

>     If `call-process' would be able to handle remote
>     commands,
>
> I cannot envision any way in which that could make sense.  I have no
> idea what it would mean for `call-process' to "handle" remote
> commands.

"handle commands to be executed on a remote host".

Best regards, Michael.

Re: executable-find in files.el

[Richard Stallman]

    One could argue that just calling `process-file' should be
    sufficient. But it isn't for packages which still want to support
    Emacs 21.

Backwards-compatibility is nice, but it is not the most important
thing.

    >     If `call-process' would be able to handle remote
    >     commands,
    >
    > I cannot envision any way in which that could make sense.  I have no
    > idea what it would mean for `call-process' to "handle" remote
    > commands.

    "handle commands to be executed on a remote host".

What call-process does is run a program with given arguments.
How would it run this program on a remote host?

Perhaps using ssh.  But if you want to use ssh, you can do that now.
You can invoke ssh to run a command on a remote host.

So what really is the new feature that you want?
I don't follow the idea.

WHat would that mean?  How in the world can call-process
run the pro

Re: executable-find in files.el

[Richard Stallman]

    But during migrating existing packages, the drawback has
    been obvious: Everywhere there is the need of checking a command for
    being remote or not, and then to call `process-file' or
    `call-process'.

I can't see why you did that.  If in a certain call you want
the file name handler to be used, you can unconditionally call
process-file.  Why didn't you do that?

    If `call-process' would be able to handle remote
    commands, most of the cases nothing would be needed to be changed -
    the existing code would simply work. And the same for `start-process'.

This would be an incompatible change, and I am not convinced it is
correct or meaningful.  The definition of call-process is that it runs
the command you specified.  I does not seem right for the mere choice
of default-directory should have such a major effect on call-process.

Conceptually, process-file is different.

    And the same for `start-process'.

Likewise the mere default-directory should not have such a drastic
effect on start-process.  If we have a facility to start a process
on a possibly-remote machine, we should specify it differently.
Perhaps with a new function start-remote-process that has a new arg
that says which machine.  When that arg is nil, it would be equivalent
to start-process.