Make call-process (and start-process?) filename handlers?

Make call-process (and start-process?) filename handlers?

[Kai Großjohann]

I think it would be good to change call-process to check for a
filename handler, based on the value of default-directory.

VC uses call-process (or start-process) for the external programs;
with this change it would automagically work for remote files.  (If
the corresponding filename handler implements call-process, of
course.)

Currently, shell-command chooses a filename handler based on
default-directory.  call-process is not currently a file operation.

Previously, Richard suggested to implement an operation
process-file.  One of the arguments would be the filename to use for
finding the right filename handler.

I think that process-file leads to unnecessary complications.  For
example, what happens if the file to process is /user@host:/file1 and
one of the other args is /user@host:/file2?  Should that be
interpreted as a filename and passed to the remote program as "/file2"
or "file2"?  Or should it be interpreted as a string and passed as
"/user@host:/file2"?  Clearly, it can be both, so the interface for
process-file needs to provide a way to specify which interpretation
to use.  Another complication is that the filename that determines
the handler can be at various positions in the arg list, which makes
the interface to process-file complicated.

With call-process, one can just make all filenames relative to
default-directory before invoking call-process.  Then it will just
work.

In the unlikely event that somebody successfully invoked call-process
where default-directory was pointing to a remote directory, this
invocation can easily be rectified by let-binding default-directory
to "/" (on Windows, maybe "c:/"?) arount that problematic
invocation.  I have not done investigations on how unlikely that
event is, though.

What do people think?
-- 
Ambibibentists unite!

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    I think it would be good to change call-process to check for a
    filename handler, based on the value of default-directory.

It doesn't make sense to run any particular handler for call-process
generally.  What you would want the handler to do, and whether it
makes sense to run one, is specific to a particular program.  So this
change is the wrong way to solve the problem.

Re: Make call-process (and start-process?) filename handlers?

[Kevin Rodgers]

Richard Stallman wrote:
[without attributing the following to its author]

>     I think it would be good to change call-process to check for a
>     filename handler, based on the value of default-directory.
> 
> It doesn't make sense to run any particular handler for call-process
> generally.  What you would want the handler to do, and whether it
> makes sense to run one, is specific to a particular program.  So this
> change is the wrong way to solve the problem.

M-}
M-x replace-string RET call-process RET find-file RET
M-{
M-x replace-string RET program RET file RET
C-c C-c

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    > It doesn't make sense to run any particular handler for call-process
    > generally.  What you would want the handler to do, and whether it
    > makes sense to run one, is specific to a particular program.  So this
    > change is the wrong way to solve the problem.

    M-}
    M-x replace-string RET call-process RET find-file RET
    M-{
    M-x replace-string RET program RET file RET
    C-c C-c

I think you're trying to make some sort of point, but you have not
stated it clearly.

Re: Make call-process (and start-process?) filename handlers?

[Stefan Monnier]

>     I think it would be good to change call-process to check for a
>     filename handler, based on the value of default-directory.
> 
> It doesn't make sense to run any particular handler for call-process
> generally.  What you would want the handler to do, and whether it
> makes sense to run one, is specific to a particular program.  So this
> change is the wrong way to solve the problem.

We've gone through that already.
The `shell-command' precedent as well as the `dired-call-process' precedent
show that there is something to say for `call-process' (and by extension
`start-process') to call a file-name-handler depending on default-directory.

That will make M-x compile, VC, M-x gdb, and much more behave correctly
on remote files.


	Stefan

Re: Make call-process (and start-process?) filename handlers?

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> That will make M-x compile, VC, M-x gdb, and much more behave correctly
> on remote files.

Richard, do you think it would be useful for me to go through the
Emacs sources to see where call-process is called and to figure out
whether that call breaks if done remotely?

I'm not as sure as Stefan that just changing call-process *will* make
all these commands grok remote files.  But there is a pretty good
chance that they do, and I guess it would be easy enough to fix them.

But in the end, it's not a big problem: just implement another
function that's just like call-process, except that it invokes a
filename handler based on default-directory.  And then, various
pieces of Lisp can be converted from the existing call-process to the
new function ;-)
-- 
Ambibibentists unite!

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    But in the end, it's not a big problem: just implement another
    function that's just like call-process, except that it invokes a
    filename handler based on default-directory.  And then, various
    pieces of Lisp can be converted from the existing call-process to the
    new function ;-)

That's a much better approach.  That way, various Lisp programs can
support this remote behavior when it does the right thing for them.

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    The `shell-command' precedent as well as the `dired-call-process' precedent
    show that there is something to say for `call-process' (and by extension
    `start-process') to call a file-name-handler depending on default-directory.

I'm not convinced.

dired-call-process is used for a few specific programs, to operate on
files in the default directory and its subdirectories.  In those limited
cases, it should do the right thing.

I'm concerned about shell-command, because it looks like this will
make all shell commands execute remotely when you are visiting a
remote file.  That is not natural, and not necessarily correct; it
could cause a painful surprise.  It might be ok as a special exception
feature, if it were documented as one.  Currently it isn't.

If we did something like this for call-process, I expect it would
break programs that run call-process for specific commands that do not
use the default-directory.  They expect the command to do the same
thing regardless of whether default-directory is remote.

Re: Make call-process (and start-process?) filename handlers?

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> I'm concerned about shell-command, because it looks like this will
> make all shell commands execute remotely when you are visiting a
> remote file.  That is not natural, and not necessarily correct; it
> could cause a painful surprise.  It might be ok as a special exception
> feature, if it were documented as one.  Currently it isn't.

Stefan and me have precisely the opposite opinion: we find it natural
to execute the program on the remote host, and unnatural to do it
locally.  I guess the rest of the disagreement follows from this.

So what do we do now?
-- 
Ambibibentists unite!

Re: Make call-process (and start-process?) filename handlers?

[Andreas Schwab]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

|> Richard Stallman <rms@gnu.org> writes:
|> 
|> > I'm concerned about shell-command, because it looks like this will
|> > make all shell commands execute remotely when you are visiting a
|> > remote file.  That is not natural, and not necessarily correct; it
|> > could cause a painful surprise.  It might be ok as a special exception
|> > feature, if it were documented as one.  Currently it isn't.
|> 
|> Stefan and me have precisely the opposite opinion: we find it natural
|> to execute the program on the remote host, and unnatural to do it
|> locally.

It depends, I'd say.  If you just want to do a quick shell command, you
probably want to execute it locally.  But if you run the shell command on
the file associated with the buffer it is surely natural to run it on the
same host where the file resides.  IMHO in most cases you want to run it
locally, and running remotely should be a special case.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Make call-process (and start-process?) filename handlers?

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 13 Jan 2003 11:21:58 +0100, Andreas Schwab <schwab@suse.de> wrote:
> 
> |> > I'm concerned about shell-command, because it looks like this will
> |> > make all shell commands execute remotely when you are visiting a
> |> > remote file.  That is not natural, and not necessarily correct; it
> |> > could cause a painful surprise.  It might be ok as a special exception
> |> > feature, if it were documented as one.  Currently it isn't.
> |> 
> |> Stefan and me have precisely the opposite opinion: we find it natural
> |> to execute the program on the remote host, and unnatural to do it
> |> locally.
> 
> It depends, I'd say.  If you just want to do a quick shell command, you
> probably want to execute it locally.  But if you run the shell command on
> the file associated with the buffer it is surely natural to run it on the
> same host where the file resides.  IMHO in most cases you want to run it
> locally, and running remotely should be a special case.

I had this problem with my enhancement to compilations (calling
`compile-internal'). I solved it by letting the user use the prefix
argument (\C-u) to specify a remote compilation.

Ehud.


- -- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE+IqYBLFvTvpjqOY0RAvqRAJ9kBEfpdRwbtpWtRzlP7VldCGy4NwCeI9/u
hHoquRhjVQZL25SBAO5Y+zE=
=Hn61
-----END PGP SIGNATURE-----

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    I had this problem with my enhancement to compilations (calling
    `compile-internal'). I solved it by letting the user use the prefix
    argument (\C-u) to specify a remote compilation.

That could be a good approach, since both options are useful.
Unfortunately, shell-command already takes a prefix argument.

Re: Make call-process (and start-process?) filename handlers?

[Luc Teirlinck]

Richard Stallman wrote:

   That could be a good approach, since both options are useful.
   Unfortunately, shell-command already takes a prefix argument.

If I understand the problem correctly, that makes four possibilities:
output at point or in a separate buffer, local or remote.  That is not
a new situation: C-x C-s has a similar four way problem.  It would
seem consistent to solve the present problem in a way similar to the
way the C-x C-s problem was solved:

No argument: local, output treated as usual.

Prefix argument: local, output at point, just like now, except:

2 C-u's : remote, output as usual

3 C-u's: remote, output at point.

This would actually be less complicated than the C-x C-s situation,
because C-x C-s also treats an argument of 0 specially.

It also has the advantage over, say, treating C-u specially, of not
forcing anybody who only uses the local version to change their
current habits.

Sincerely,

Luc.

Re: Make call-process (and start-process?) filename handlers?

[Richard Stallman]

    No argument: local, output treated as usual.

    Prefix argument: local, output at point, just like now, except:

    2 C-u's : remote, output as usual

    3 C-u's: remote, output at point.

I see nothing unacceptable about this.  If people are happy with it,
we could do it.