help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igrep on remote files with tramp?


From: Michael Albinus
Subject: Re: igrep on remote files with tramp?
Date: Wed, 03 Aug 2005 10:10:16 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (hpux)

Kevin Rodgers <address@hidden> writes:

>  > Can't a local igrep be run on the local tmp files that get used for so
>  > many other purposes?
>
> I don't know how tramp works, but ange-ftp evidently does not leave the
> local tmp files on disk once their contents have been inserted into the
> buffer.

So does Tramp.

>  > In any case, being able to run remote processes with tramp would be
> great.
>
> It turns out that ange-ftp provides file name handlers for
> shell-command, which uses remote-shell-program (e.g.  /bin/remsh) to
> execute the command on the other host when visiting a remote file or
> directory.  So I would be suprised if tramp does not provide the same
> functionality when you use e.g. `! grep foo *.java'.

So does Tramp.

> But igrep and grep are based on compile, which uses start-process
> instead of shell-command.  But since tramp provides commands for
> compilation of files on remote hosts (see
> http://www.gnu.org/software/tramp/#Compilation), perhaps tramp-util.el
> just needs something like this (cribbed from tramp-compile):

[...]

It could go this way. But as I wrote already, it would be an endless
task to provide such Tramp pendants for all usefull
commands. Therefore it won't be done inside main Tramp development
(except the integration of `compile', which already exists).

Instead of I hope to convince the emacs-devel list to extend
`call-process' and `start-process' supporting something like file
handlers. There was already a step into that direction with
`process-file', which should act like `call-process' on remote
hosts. But this approach is not sufficient I fear.

>  > I've frequently wished I could do this with gdb within emacs, for
> instance.
>
> You are not alone.

That will be the proof of concept (prototype implementation). If it
doesn't work for gdb out of the box, the concept is not worth to be
applied.

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]