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 t
Running a command remotely is something like
ssh
whereas running a remote command locally is something like
scp /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 wi
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
Richard Stallman <[EMAIL PROTECTED]> 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.
>> 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
whereas running a remote command local
Stefan Monnier <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.cua.dk
_
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 w
Richard Stallman <[EMAIL PROTECTED]> 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
> 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 distin
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 sec
Stefan Monnier <[EMAIL PROTECTED]> 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 doe
> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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
>> > 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
> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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
>> 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
_
Stefan Monnier <[EMAIL PROTECTED]> 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
>> > 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 identi
> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <[EMAIL PROTECTED]>
> 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-exec
>> + (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-f
>
> + (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
20 matches
Mail list logo
