[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tramp with shots
Re: Tramp with shots
Thu, 19 Aug 2010 05:27:53 +0300
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
>>>>> "Michael" == Michael Albinus <address@hidden> writes on
>>>>> Wed, 18 Aug 2010 21:13:56 +0200:
>> That's exactly what I did the last weekend.
>> I crafted a toy tramp method that I called `ext', because litter
>> My feeling is, that method is much faster then scp or other tramp
>> method that I tried.
Michael> Sounds promising. Have you profiled your settings, in order
Michael> to have numbers for comparision? Lets say "ssh" vs
Michael> "sftp(gvfs)" vs "ext(sshfs)".
No scientific comparison, only feelings. I had always a feeling of
slowness toward Tramp. My feeling on fastness is based on browsing,
opening and saving remote files but not on copying big files
There is a little story behind my toy `ext' method, a little bit sad
one but with happy ending:
The previous week I had to get some work done on whatever remote
FreeBSD system, of course I used Tramp to connect remotely and edit
my files. I could browse the remote system, I could open the remote
files, but for don't know what reason I could not save some files.
I could save smaller files but not ones bigger then
`tramp-copy-size-limit'. Trying to save resulted into Emacs being
stuck, and after interrupting Emacs I had the remote file truncated
to 0 bytes.
At first I blamed my own customizations, I used to use (another)
customized method based on expect to login to remote hosts.
So I started `emacs -q' and used fresh Tramp, and tried the methods
ssh, scp, sftp, some '...x' method (I forget which one), and even
FISH. To my frustrations I could not save those files by any mean.
I tried unsuccessfully to debug the stuff, analyzed tramps logs, and
to make a long story short, no success. Don't know until now what
was wrong with that system, or maybe with Tramp, or with me, or who
My frustration eventually get so big that I decided to give up
Tramp. I used sshfs to mount the remote FreeBSD, and saving worked
like a breeze.
So at the culmination of my irritation I said myself, I regretfully confess,
that I will never use Tramp again. Never ever. That the sad part of
The happy ending is that immediately after I definitively and
irremediably divorced Tramp, I started to miss it. File edition
worked fine now; but I missed the fine integration with remote
processes, like find-grep on remote directories, remote compilation,
opening shell remotely, compilation shell mode highlighting to jump
to the right file, and so on.
So I promised myself I will give Tramp a new chance and I to try to
implement a method which relies on external system mount mechanism
for file edition, but that will offer usual integration with remote
processes. So Tramp and me together again, since the last weekend.
>> My implementation mounts sillently a directory "/tmp/address@hidden" to
>> remote path "/ext:address@hidden:/". That mapping is hardcoded right
>> but it's trivial to change it.
Sorry I meant 'maps silently' but I wrote 'mounts silently'. It's
the responsibility of the user to mount the remote file system.
*I was looking for a minimal Tramp method which gives to Tramp only
one responsibility: integration with remote processes. Minimum
involvement in file manipulations (to be delegated to system level
mounts), and minimum involvement in the logging process (to be
delegated totally to some user script).*
Michael> I see the trick. However, you assume, that the user is
Michael> capable to mount at "/". Many users might miss such rights.
That's right. For me was pretty useful as it is. I will look into
Michael> And, secondly, it won't work for XEmacs. There is another
Michael> file name syntax for remote files; you would need to mount
Michael> at "/[ext/address@hidden/" - that's really ugly.
I used 2 simple functions, which make the translation
remote->to->local name and viceversa. Changing them would make the
trick, I find not difficult this.
Michael> A more general approach is what tramp-gvfs.el uses. It lets
Michael> GVFS mount the remote directory at "~/.gvfs/WebDAV on
Michael> remote.host" (example), and uses functions to map between
Michael> this internal names, and Tramp's file names.
Michael> Something like this could be used for sshfs as well.
I will look at tramp-gvfs.el. On my Ubuntu 10.4 I have installed
tramp-gvfs.elc but not the source tramp-gvfs.el.gz, the `emacs-el'
Ubuntu package does not have it. So I have to check out the sources
from CVS and look into.
>> The only problem that I found after a few days of using it is the
>> expansion of "~" in remote paths like "/ext:address@hidden:~/". That
>> not too be to difficult to fix too, but requires to think about how to
>> map home directories to '/ext:' paths, which I was to lazy to. For now
>> using a '~' will map to your local home directory.
Michael> There are also more problems. What do you do with symlinks?
The relative symlinks do work. The absolute one, don't (yet). Thanks
for pointing me to this (looks like I encountered only relative
symlinks during these days).
Michael> tried, but does your implementation of start-file-process
Michael> works on remote hosts?
That was the whole point for trying to write my own method. It
worked pretty well with my expect script.
Michael> You also map the arguments of process calls - this might be
Michael> dangerous. Tramp avoids this for good reasons, and let the
Michael> caller do the right thing (the best guess is to use
Michael> relative file names as argument).
I do not totally understand the dangers you are talking about. For
me was important to get remote compilation & grep & shell mode
working; don't think launching those kind of processes are
dangerous. Maybe you could explain me.
>> Find bellow the 'tramp-ext.el' method.
>> If you want to try that stuff, don't forget to modify mine
>> `tramp-login-program'. (I use to use an expect script to launch
>> external processes)
Michael> This might be a problem as well. It expects from the user
Michael> an own login script - in my experience, users appreciate a
Michael> complete solution. This part shall be offered in your
Michael> package as well.
I could supply some sample script of course.
About expecting from the user its own script: see, that was exactly
what I wanted, to have control over the logging process myself. I
personally found hard to understand the inner workings of tramp
while logging, and whenever it didn't work I had hard time to debug
it. That's I suppose entirely my fault, I don't bash Tramp here.
I'm particularly happy instead with the job done by `expect' for
automation of remote log-ins. In fact I see the way Tramp deals with
remote logins is exactly an elisp kind of `expect'.
That's just me of course, but maybe other feel the same and would
find such method useful.
Maybe that's not what most user want. Maybe I could reuse entirely
existing tramp mechanism for handling remote process (with ssh
connections). I will see.
>> I'm interested in your feedback. If there is interest I could
>> volunteer to maintain it.
Michael> I'm happy for every volunteer. But please keep in mind,
Michael> that Tramp is copyrighted by the FSF. This requires for
Michael> every contributor of non-trivial changes to sign the legal
Michael> papers of the FSF. Would you be willing to do so?
But of course.
I apologize for this too long post,