Feature request: new function start-remote-process

Feature request: new function start-remote-process

[Michael Albinus]

Hi,

with Emacs 22.1, the function process-file has been introduced. It is an
extension for call-process, which let programs execute a remote host
when default-directory is remote. It is implemented via a file handler.

start-remote-process shall behave similar: if default-directory points
to a remote host, the corresponding program shall be executed there.

By this, packages like compile.el or vc.el could extend their
functionality to remote hosts.

Note that Tramp 2.1 offers a simulation of this behaviour already, which
works so far. Because this simulation is based on a defadvice of
start-process, this cannot go into Emacs trunk (and it has also further
undesired side effects which must be avoided).

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Sean O'Rourke]

Michael Albinus <michael.albinus@gmx.de> writes:
> start-remote-process shall behave similar: if default-directory points
> to a remote host, the corresponding program shall be executed there.

This would be great for compiling programs, but from what I have
seen, it has to be done carefully to avoid breaking things.  For
example, Tramp 2.1's current emulation interacts badly with
`ediff-buffers', which will sometimes write temporary files
locally, then try to diff them on the remote system.  So it seems
like it may be necessary to explicitly allow or prevent
individual calls to start-process from being handled remotely.

/s

Re: Feature request: new function start-remote-process

[Michael Albinus]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>> start-remote-process shall behave similar: if default-directory points
>> to a remote host, the corresponding program shall be executed there.
>
> This would be great for compiling programs, but from what I have
> seen, it has to be done carefully to avoid breaking things.  For
> example, Tramp 2.1's current emulation interacts badly with
> `ediff-buffers', which will sometimes write temporary files
> locally, then try to diff them on the remote system.  So it seems
> like it may be necessary to explicitly allow or prevent
> individual calls to start-process from being handled remotely.

That's exactly the reason of my proposal. The proof of concept in Tramp
2.1 did show this deficiency. With the new function, every package could
decide whether to apply start-process or start-remote-process.

A package like gnus shall always use start-process; it is unlikely to
use mail programs on a remote host. In contrary, compile shall use
start-remote-process - when default-directory is local, there is no
difference to the current behaviour.

> /s

Best regards, Michael.

PS: The problem with ediff has been worked around in Tramp's CVS version
already, because it disturbs me as well. But it is still a kludge.

Re: Feature request: new function start-remote-process

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi,

> with Emacs 22.1, the function process-file has been introduced. It is an
> extension for call-process, which let programs execute a remote host
> when default-directory is remote. It is implemented via a file handler.
>
> start-remote-process shall behave similar: if default-directory points
> to a remote host, the corresponding program shall be executed there.

Looks like nobody objects. I'll install it next days in the trunk,
unless there is a veto.

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Richard Stallman]

    > start-remote-process shall behave similar: if default-directory points
    > to a remote host, the corresponding program shall be executed there.

    Looks like nobody objects. I'll install it next days in the trunk,
    unless there is a veto.

But...how is it possible to do run a program on a remote host?
In general, there is no way, right?

Re: Feature request: new function start-remote-process

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > start-remote-process shall behave similar: if
>     > default-directory points to a remote host, the corresponding
>     > program shall be executed there.
>
>     Looks like nobody objects. I'll install it next days in the trunk,
>     unless there is a veto.
>
> But...how is it possible to do run a program on a remote host?
> In general, there is no way, right?

Uh, the whole point of tramp is that it communicates using a shell
connection.

And actually, even when the current directory is set using ange-ftp,
execution of shell commands tries to go through rsh IIRC, of course
mostly failing nowadays.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Feature request: new function start-remote-process

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     > start-remote-process shall behave similar: if default-directory points
>     > to a remote host, the corresponding program shall be executed there.
>
>     Looks like nobody objects. I'll install it next days in the trunk,
>     unless there is a veto.
>
> But...how is it possible to do run a program on a remote host?
> In general, there is no way, right?

Why not? Tramp must call programs on a remote host permanently. It opens
a new buffer by

(start-process "name" tramp-buffer "ssh" host "-l" user)

Then it sends the program to that process, and reads the result in the
buffer.

A program can be regarded as the "basename" of an absolute file name.

(let ((default-directory "/ssh:user@host:"))
  (start-remote-process "example" "*scratch*" "hostname"))

does work in my implementation. It must be specified how the program
"hostname" is found. We've discussed shortly two years ago, how to
use `executable-find' and `exec-path' for that, with no result.

For the time being, I would propose that the search path for a program
on a remote host shall be the result of `getconf PATH` on the remote
host (that's what Tramp 2.1 does by default). If a program is not found
in that path, it could be called by its absolute file name:

(let ((default-directory "/ssh:user@host:"))
  (start-remote-process "example" "*scratch*" "/bin/hostname"))

However, there must be a better mechanism to define exec-path for remote
hosts. Tramp has an own, proprietary mechanism (see tramp-remote-path);
this needs to be generalized.

Best regards, Michael.magdalene

Re: Feature request: new function start-remote-process

[Richard Stallman]

    > But...how is it possible to do run a program on a remote host?
    > In general, there is no way, right?

    Why not? Tramp must call programs on a remote host permanently.

But often ftp is the only way to access the other host.

Re: Feature request: new function start-remote-process

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     > But...how is it possible to do run a program on a remote host?
>     > In general, there is no way, right?
>
>     Why not? Tramp must call programs on a remote host permanently.
>
> But often ftp is the only way to access the other host.

For ftp, this approach won't work, of course. But this is no degradation
to the current situation.

And according to my experience, ftp availability decreases. Because of
security considerations, ftp is disabled on server machines, and ssh/scp
are the preferred access methods. (I'm working in the Network Management
area for a telecom supplier)

start-remote-process would gain a clientele.

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     > But...how is it possible to do run a program on a remote host?
>>     > In general, there is no way, right?
>>
>>     Why not? Tramp must call programs on a remote host permanently.
>>
>> But often ftp is the only way to access the other host.
>
> For ftp, this approach won't work, of course. But this is no degradation
> to the current situation.

I forgot the other scenario. "The other host" could be your local host,
but with another user.

Suppose compile.el uses already start-remote-process and
process-file. Then you could apply

(let ((default-directory "/sudo::/etc"))
  (grep-find (concat grep-find-command "xxx")))

searching as root on your local host.

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Stefan Monnier]

>> with Emacs 22.1, the function process-file has been introduced. It is an
>> extension for call-process, which let programs execute a remote host
>> when default-directory is remote. It is implemented via a file handler.
>> 
>> start-remote-process shall behave similar: if default-directory points
>> to a remote host, the corresponding program shall be executed there.

> Looks like nobody objects. I'll install it next days in the trunk,
> unless there is a veto.

In order not to derogate(?) to the custom of objecting late, I'll add an
objection right now: the name is wrong because it indicates for what you use
the feature rather than what it does.  I think that the name should include
"file" somewhere rather than (or at least additionally to) "remote", since
the key aspect compared to start-process is that it's a file-name operation.
So I'd call it "start-file-process".  Other than that, I fully support this
feature, of course.


        Stefan

Re: Feature request: new function start-remote-process

[Michael Albinus]

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

> In order not to derogate(?) to the custom of objecting late, I'll add an
> objection right now: the name is wrong because it indicates for what you use
> the feature rather than what it does.  I think that the name should include
> "file" somewhere rather than (or at least additionally to) "remote", since
> the key aspect compared to start-process is that it's a file-name operation.
> So I'd call it "start-file-process".  Other than that, I fully support this
> feature, of course.

"start-remote-process" was proposed by Richard 2 years ago, see
<http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00769.html>.
He did also propose a new parameter, but I believe the file name
handler check based on default-directory is sufficient.

But I don't believe that the key aspect of "start-remote-process" is a
file-name operation. That is true for process-file only. There one
could have a remote file name specified in INFILE or BUFFER, and
PROGRAM would use a local copy of the file(s) if default-directory is
located on another host. PROGRAM could also run on a remote host if
default-directory is a remote file name.

In start-process as well as in "start-remote-process", you cannot pass
a file name as argument to PROGRAM. Consequently, "start-remote-process"
is not a file-name operation as process-file. Only the possibility to
run PROGRAM on another host is similar to what process-file offers.

Anyway, it is not important to me which name is chosen.

>         Stefan

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Michael Albinus]

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

Hi Stefan,

> In order not to derogate(?) to the custom of objecting late, I'll add an
> objection right now: the name is wrong because it indicates for what you use
> the feature rather than what it does.  I think that the name should include
> "file" somewhere rather than (or at least additionally to) "remote", since
> the key aspect compared to start-process is that it's a file-name operation.
> So I'd call it "start-file-process".  Other than that, I fully support this
> feature, of course.

Do you still object the name? Otherwise, I'ld like to commit the change
into the trunk.

>         Stefan

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Stefan Monnier]

>> In order not to derogate(?) to the custom of objecting late, I'll add an
>> objection right now: the name is wrong because it indicates for what you use
>> the feature rather than what it does.  I think that the name should include
>> "file" somewhere rather than (or at least additionally to) "remote", since
>> the key aspect compared to start-process is that it's a file-name operation.
>> So I'd call it "start-file-process".  Other than that, I fully support this
>> feature, of course.

> Do you still object the name?

Yes, and for the same reasons: the definition of the function makes no
reference to "remote" processes, only to a file-name-handler (which may use
remote processes, of course, but that's not relevant).


        Stefan

Re: Feature request: new function start-remote-process

[Michael Albinus]

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

>> Do you still object the name?
>
> Yes, and for the same reasons: the definition of the function makes no
> reference to "remote" processes, only to a file-name-handler (which may use
> remote processes, of course, but that's not relevant).

As I said already, I don't care too much the name (although I still
see it different).

Does anybody objects "start-file-process", as Stefan proposed?

>         Stefan

Best regards, Michael.

Re: Feature request: new function start-remote-process

[Stefan Monnier]

> Looks like nobody objects. I'll install it next days in the trunk,
> unless there is a veto.

BTW, could someone change dired&ange-ftp to use process-file instead of
dired-call-process?


        Stefan

Re: Feature request: new function start-remote-process

[Michael Albinus]

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

> BTW, could someone change dired&ange-ftp to use process-file instead of
> dired-call-process?

I'll check tonight.

>         Stefan

Best regards, Michael.