* Re: executable-find in files.el [not found] <E1DVuFh-0001h1-GE@monty-python.gnu.org> @ 2005-05-11 18:29 ` Eli Zaretskii 2005-05-11 19:07 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2005-05-11 18:29 UTC (permalink / raw) Cc: emacs-devel > > + (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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 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 2005-05-14 14:58 ` Michael Albinus 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2005-05-11 19:07 UTC (permalink / raw) Cc: emacs-devel >> + (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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-11 19:07 ` Stefan Monnier @ 2005-05-11 22:56 ` Eli Zaretskii 2005-05-11 23:16 ` Stefan Monnier 2005-05-14 14:58 ` Michael Albinus 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2005-05-11 22:56 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-11 22:56 ` Eli Zaretskii @ 2005-05-11 23:16 ` Stefan Monnier 2005-05-11 23:50 ` David Kastrup 2005-05-12 6:34 ` Eli Zaretskii 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2005-05-11 23:16 UTC (permalink / raw) Cc: emacs-devel >> > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 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 1 sibling, 1 reply; 20+ messages in thread From: David Kastrup @ 2005-05-11 23:50 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-11 23:50 ` David Kastrup @ 2005-05-12 1:31 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2005-05-12 1:31 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-11 23:16 ` Stefan Monnier 2005-05-11 23:50 ` David Kastrup @ 2005-05-12 6:34 ` Eli Zaretskii 2005-05-12 12:42 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2005-05-12 6:34 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-12 6:34 ` Eli Zaretskii @ 2005-05-12 12:42 ` Stefan Monnier 2005-05-12 13:14 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2005-05-12 12:42 UTC (permalink / raw) Cc: emacs-devel >> > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-12 12:42 ` Stefan Monnier @ 2005-05-12 13:14 ` Eli Zaretskii 0 siblings, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2005-05-12 13:14 UTC (permalink / raw) Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-11 19:07 ` Stefan Monnier 2005-05-11 22:56 ` Eli Zaretskii @ 2005-05-14 14:58 ` Michael Albinus 2005-05-15 0:21 ` Richard Stallman 1 sibling, 1 reply; 20+ messages in thread From: Michael Albinus @ 2005-05-14 14:58 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-14 14:58 ` Michael Albinus @ 2005-05-15 0:21 ` Richard Stallman 2005-05-16 19:27 ` Michael Albinus 0 siblings, 1 reply; 20+ messages in thread From: Richard Stallman @ 2005-05-15 0:21 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-15 0:21 ` Richard Stallman @ 2005-05-16 19:27 ` Michael Albinus 2005-05-16 22:38 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Michael Albinus @ 2005-05-16 19:27 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 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 4:36 ` Richard Stallman 2005-05-18 13:08 ` Richard Stallman 2 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2005-05-16 22:38 UTC (permalink / raw) Cc: eliz, rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-16 22:38 ` Stefan Monnier @ 2005-05-17 22:03 ` Kim F. Storm 2005-05-17 22:23 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Kim F. Storm @ 2005-05-17 22:03 UTC (permalink / raw) Cc: eliz, Michael Albinus, rms, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-17 22:03 ` Kim F. Storm @ 2005-05-17 22:23 ` Stefan Monnier 2005-05-18 13:08 ` Richard Stallman 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2005-05-17 22:23 UTC (permalink / raw) Cc: eliz, Michael Albinus, rms, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-17 22:23 ` Stefan Monnier @ 2005-05-18 13:08 ` Richard Stallman 0 siblings, 0 replies; 20+ messages in thread From: Richard Stallman @ 2005-05-18 13:08 UTC (permalink / raw) Cc: eliz, emacs-devel, michael.albinus, storm 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-16 19:27 ` Michael Albinus 2005-05-16 22:38 ` Stefan Monnier @ 2005-05-17 4:36 ` Richard Stallman 2005-05-17 16:32 ` Michael Albinus 2005-05-18 13:08 ` Richard Stallman 2 siblings, 1 reply; 20+ messages in thread From: Richard Stallman @ 2005-05-17 4:36 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-17 4:36 ` Richard Stallman @ 2005-05-17 16:32 ` Michael Albinus 2005-05-18 5:19 ` Richard Stallman 0 siblings, 1 reply; 20+ messages in thread From: Michael Albinus @ 2005-05-17 16:32 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-17 16:32 ` Michael Albinus @ 2005-05-18 5:19 ` Richard Stallman 0 siblings, 0 replies; 20+ messages in thread From: Richard Stallman @ 2005-05-18 5:19 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: executable-find in files.el 2005-05-16 19:27 ` Michael Albinus 2005-05-16 22:38 ` Stefan Monnier 2005-05-17 4:36 ` Richard Stallman @ 2005-05-18 13:08 ` Richard Stallman 2 siblings, 0 replies; 20+ messages in thread From: Richard Stallman @ 2005-05-18 13:08 UTC (permalink / raw) Cc: eliz, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-05-18 13:08 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.