tramp-devel
[Top][All Lists]
Advanced

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

Re: local execution of commands on remote files


From: Adrian Lanz
Subject: Re: local execution of commands on remote files
Date: Thu, 15 Jan 2004 16:54:54 +0100
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (usg-unix-v)

On 15 Jan 2004, address@hidden wrote:

> On Thu, 15 Jan 2004, Michael Albinus wrote:
>
>> Adrian Lanz <address@hidden> writes:
>>
>>> My question: is there some tramp built-in functionality to
>>> "execute" remote files on the local machine? After step 2 (tramp
>>> and dired have brought up the remote directry listing) I would
>>> like to do something like dired-do-shell-command (pressing "!"),
>>> which in this context would mean: download the remote file to some
>>> (configurable) temporary place on the local file system and then
>>> use the local application I provide in the mini-buffer on that
>>> temporary file. What is sent back to the remote system after the
>>> local command has been run would be configurable. After latex'ing
>>> a remote file on the local machine, I probably would like tramp to
>>> save the dvi file on the remote system; after xpdf'ing a remote
>>> file on the local machine, nothing at all would have to be sent
>>> back to the remote machine.
>
> The suggestion here doesn't really make sense (to me). If you have a
> remote latex file, and you want to operate on that, then either
> operate on it remotely, or copy it locally, operate on it locally,
> and store the source file and all intermediate and final results
> locally. (I can see one case where the described action could be
> useful - where the local node is faster than the remote node, and so
> you want to process locally. But this still doesn't make sense - why
> invoke the remote node at *all*?)
>
> The problem is how do you tell tramp what files are needed from the
> remote machine in order to be able to operate on it locally? In the
> LaTeX example you give - when I am writing, I typically have 5
> separate files which are `included'. How to tell tramp you have to
> copy them all over locally before latex can possibly be run? There
> already on the remote system, why not just run latex there?

I agree, that things get complicated when compiling the downloaded
file depends on further remotely stored files. Let's start with simple
cases ;-)

Concerning the remote system. In my case these systems are Windows NT
or whatever Windows machines, whereas my local machine is a Unix
Desktop (Solaris) or notebook (Linux). My collegues store thier
contribution in one of MS-Office formats or hopefully in some
generally readable output format (pdf, html, ...). I would like to
quickly read (and possibly change) these files with my locally
installed OpenOffice or xpdf or whatever (I can't get a Windows
display on my X window system, do I?), and put my contributions -
fully documented - as source (tex) and in some output formats (pdf,
ps, dvi, ...) on that repository. By downloading and uploading the
files I can do both now (thanks to tramp!), and I just wondered if I
could do that without the intermediate downloading/uploading step.

>> No, it isn't implemented (yet). But it is at least on my private
>> TODO list. I even would like to have the opportunity to execute
>> commands on the remote host, which is a little bit different to
>> your scenario. By this, commands like find-grep-dired could be
>> extended to work on remote hosts, too.
>
> However, *this* kind of functionality would be very nice. The common
> scenario is that I am editing source files remotely, and want them
> compiled remotely. Press f4 to invoke make, and it is made. But
> unfortunately, tramp doesn't yet have this functionality :)
>
> If it can hook into the debugging mode or whatever, then doubly
> nice.

Well, this functionality is not on *my* wish list (yet), and what I
would like to see implemented should be much easier to write, isn't
it? Just a simple dired-mode hook? ;-)

Thanks, Adrian.





reply via email to

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