This file documents TRAMP version 2.0.39, a remote file editing package for Emacs.
TRAMP stands for `Transparent Remote (file) Access, Multiple Protocol'. This package provides remote file editing, similar to Ange-FTP.
The difference is that Ange-FTP uses FTP to transfer
files between the local and the remote host, whereas TRAMP uses a
combination of rsh and rcp or other work-alike
programs, such as ssh/scp.
You can find the latest version of this document on the web at http://www.freesoftware.fsf.org/tramp/.
The manual has been generated for Emacs. If you're using the other Emacs flavour, you should read the XEmacs pages.
The latest release of TRAMP is available for download, or you may see Obtaining TRAMP for more details, including the CVS server details.
TRAMP also has a Savannah Project Page.
There is a mailing list for TRAMP, available at
tramp-devel@mail.freesoftware.fsf.org, and archived at
Savannah Mail Archive.
Older archives are located at
SourceForge Mail Archive and
The Mail Archive.
Copyright © 1999, 2000, 2001, 2002, 2003, 2004 Free Software
Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being "A GNU Manual", and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled "GNU Free Documentation License" in the Emacs manual.(a) The FSF's Back-Cover Text is: "You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development."
This document is part of a collection distributed under the GNU Free Documentation License. If you want to distribute this document separately from the collection, you can do so by adding a copy of the license to the document, as described in section 6 of the license.
After the installation of TRAMP into your Emacs, you
will be able to access files on remote machines as though they were
local. Access to the remote file system for editing files, version
control, and dired are transparently enabled.
Your access to the remote machine can be with the rsh,
rlogin, telnet programs or with any similar
connection method. This connection must pass ASCII
successfully to be usable but need not be 8-bit clean.
The package provides support for ssh connections out of the
box, one of the more common uses of the package. This allows
relatively secure access to machines, especially if ftp
access is disabled.
The majority of activity carried out by TRAMP requires only that the remote login is possible and is carried out at the terminal. In order to access remote files TRAMP needs to transfer their content to the local machine temporarily.
TRAMP can transfer files between the machines in a variety of ways. The details are easy to select, depending on your needs and the machines in question.
The fastest transfer methods (for large files) rely on a remote file
transfer package such as rcp, scp or
rsync. The use of these methods is only possible if the
file copy command does not ask for a password for the remote machine.
If the remote copy methods are not suitable for you, TRAMP also
supports the use of encoded transfers directly through the shell.
This requires that the mimencode or uuencode tools
are available on the remote machine. These methods are generally
faster for small files.
Within these limitations, TRAMP is quite powerful. It is worth noting that, as of the time of writing, it is far from a polished end-user product. For a while yet you should expect to run into rough edges and problems with the code now and then.
It is finished enough that the developers use it for day to day work but the installation and setup can be a little difficult to master, as can the terminology.
TRAMP is still under active development and any problems you encounter, trivial or major, should be reported to the TRAMP developers. Voir Bug Reports.
This section tries to explain what goes on behind the scenes when you access a remote file through TRAMP.
Suppose you type C-x C-f and enter part of an TRAMP file name, then hit <TAB> for completion. Suppose further that this is the first time that TRAMP is invoked for the host in question. Here's what happens:
telnet hostrsh host -l
usertelnet). The
login name is given in the file name, so TRAMP sends the login name and
a newline.
rsh or for telnet after sending the login name).
TRAMP displays the prompt in the minibuffer, asking you for the
password or pass phrase.
You enter the password or pass phrase. TRAMP sends it to the remote host, followed by a newline.
If TRAMP sees neither of them after a certain period of time (a minute, say), then it issues an error message saying that it couldn't find the remote shell prompt and shows you what the remote host has sent.
If TRAMP sees a login failed message, it tells you so,
aborts the login attempt and allows you to try again.
/bin/sh because
Bourne shells and C shells have different command
syntaxes.1
After the Bourne shell has come up, TRAMP sends a few commands to ensure a good working environment. It turns off echoing, it sets the shell prompt, and a few other things.
So, TRAMP basically issues cd and ls commands and
also sometimes echo with globbing. Another command that is
often used is test to find out whether a file is writable or a
directory or the like. The output of each command is parsed for the
necessary operation.
See above for an explanation of how TRAMP transfers the file contents.
For inline transfers, TRAMP issues a command like mimencode -b
/path/to/remote/file, waits until the output has accumulated in the
buffer that's used for communication, then decodes that output to
produce the file contents.
For out-of-band transfers, TRAMP issues a command like the following:
rcp user@host:/path/to/remote/file /tmp/tramp.4711
It then reads the local temporary file /tmp/tramp.4711 into a
buffer and deletes the temporary file.
I hope this has provided you with a basic overview of what happens behind the scenes when you open a file with TRAMP.
TRAMP is freely available on the Internet and the latest release may be downloaded from http://savannah.nongnu.org/download/tramp/. This release includes the full documentation and code for TRAMP, suitable for installation. But Emacs (21.4 or later) includes TRAMP already, and there is a TRAMP package for XEmacs, as well. So maybe it is easier to just use those. But if you want the bleeding edge, read on......
For the especially brave, TRAMP is available from CVS. The CVS version is the latest version of the code and may contain incomplete features or new issues. Use these versions at your own risk.
Instructions for obtaining the latest development version of TRAMP from CVS can be found by going to the Savannah project page at the following URL and then clicking on the CVS link in the navigation bar at the top. http://savannah.nongnu.org/projects/tramp/
Or follow the example session below:
] cd ~/emacs
] export CVS_RSH="ssh"
] cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/tramp co tramp
You should now have a directory ~/emacs/tramp
containing the latest version of TRAMP. You can fetch the latest
updates from the repository by issuing the command:
] cd ~/emacs/tramp
] export CVS_RSH="ssh"
] cvs update -d
Once you've got updated files from the CVS repository, you need to run
autoconf in order to get an up-to-date configure
script:
] cd ~/emacs/tramp
] autoconf
Development was started end of November 1998. The package was called
rssh.el, back then. It only provided one method to access a
file, using ssh to log in to a remote host and using
scp to transfer the file contents. After a while, the name
was changed to rcp.el, and now it's TRAMP. Along the way,
many more methods for getting a remote shell and for transferring the
file contents were added. Support for VC was added.
The most recent addition of major features were the multi-hop methods added in April 2000 and the unification of TRAMP and Ange-FTP filenames in July 2002.
If you use the version that comes with your Emacs, the following information is not necessary. Installing TRAMP into your Emacs is a relatively easy process, at least compared to rebuilding your machine from scratch. ;)
Seriously though, the installation should be a fairly simple matter. The easiest way to proceed is as follows:
~/emacs/. Change into that
directory and unpack the tarball. This will give you a directory
~/emacs/tramp-2.0.39/ which contains
subdirectories lisp for the Lisp code and texi for the
documentation. Make a symbolic link:
ln -s tramp-2.0.39 tramp
cd to ~/emacs/tramp/ and type
./configure to configure Tramp for your system.
Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for.
make to build the byte-compiled Lisp files as well as
the Info manual.
make install to install the Tramp Lisp files and Info
manual.
make clean. To also remove
the files that configure created, type make
distclean.
make
command, don't despair. You can still byte compile the *.el
files by opening Emacs in dired (C-x
d) mode, at ~/emacs/tramp/lisp. Mark the lisp files with
m, then press B to byte compile your selections.
Something similar can be done to create the info manual. Just change
to directory ~/emacs/tramp/texi and load the
tramp.texi file in Emacs. Then press M-x
texinfo-format-buffer <RET> to generate
~/emacs/tramp/info/tramp.
By default, make install will install TRAMP's files in
/usr/local/share/emacs/site-lisp and /usr/local/info. You can specify an
installation prefix other than /usr/local by giving
configure the option --prefix=PATH.
If your installed copy of Emacs is named something other than
emacs, you will need to tell `make' where to find it so
that it can correctly byte-compile the TRAMP sources.
For example, to force the use of XEmacs you might do this:
./configure --with-xemacs
make
make install
or this:
./configure
make EMACS=/usr/bin/xemacs-21.4
make install
The syntax of TRAMP file names is different for Emacs
and XEmacs. The Info manual will be generated for
the Emacs flavor choosen in the configure phase. If you want
the Info manual for the other version, you need to set the variable
EMACS_INFO to make:
./configure --with-emacs
make EMACS_INFO=xemacs
Also, the --prefix=PATH option to configure may
not be general enough to set the paths you want. If not, you can pass
variables to the make command to control the installation.
For a complete list of tweakable variables, look in the makefile.
For example, to put the Lisp files in ~/elisp and the Info file
in ~/info, you would type:
./configure
make
make lispdir=~/elisp infodir=~/info install
TRAMP has some packages in its contrib directory which are
missing in older Emacsen. If you want to use them, you must use the
USE_CONTRIB environment variable:
make USE_CONTRIB=1
make USE_CONTRIB=1 install
If you don't install TRAMP into the intended directories, but prefer
to use from the source directory, you need to add the following lines
into your .emacs:
(add-to-list 'load-path "~/emacs/tramp/lisp/")
(add-to-list 'load-path "~/emacs/tramp/contrib/")
(require 'tramp)
The second load-path must be used only if you've applied the
USE_CONTRIB parameter.
To be able to read the Info documentation, create a file
~/emacs/tramp/info/dir using the
install-info command, and add the directory to the search
path for Info.
NOTE:
On systems using the gnu version of install-info, the
install-info syntax is very direct and simple. One can
change to directory ~/emacs/tramp/info and type:
install-info tramp dir
and a dir file will be created with the TRAMP
entry. The info reader will know how to interpret it, but must
be told where to find it (see below). If you want anything fancier
you'll need to look through man install-info.
Debian GNU/Linux doesn't default to gnu install-info
but uses its own version. This version does not create a dir
file for you from scratch. You must provide a skeleton dir
file it recognizes. One can be found in a default installation of
Emacs at /usr/info/dir. Copy the top of this file
down to the first occurrence of * Menu including that line plus
one more blank line, to your working directory
~/emacs/tramp/info, or use the sample
~/emacs/tramp/texi/dir_sample.
Once a dir file is in place, this command will make the entry:
install-info --infodir=. tramp
If you want it in a specific category see man install-info for further details.
If the environment variable INFOPATH is set, add the directory
~/emacs/tramp/info/ to it. Else, add the directory to
Info-default-directory-list, as follows:
(add-to-list 'Info-default-directory-list "~/emacs/tramp/info/")
Thanks to Yoichi Nakayama yoichi@geiin.org, there exists a
japanese translation of the TRAMP manual. You can generate it
applying the --with-japanese-manual option:
./configure --with-japanese-manual
This will result in an Info manual
tramp_ja.
TRAMP is (normally) fully functional when it is initially installed.
It is initially configured to use the ssh program to connect
to the remote host and to use base64 or uu encoding to transfer the
files through that shell connection. So in the easiest case, you just
type C-x C-f and then enter the filename
/user@machine:/path/to.file.
On some hosts, there are problems with opening a connection. These are related to the behavior of the remote shell. See Voir Remote shell setup, for details on this.
If you do not wish to use these commands to connect to the remote host, you should change the default connection and transfer method that TRAMP uses. There are several different methods that TRAMP can use to connect to remote machines and transfer files (voir Connection types).
If you don't know which method is right for you, see Voir Default Method.
There are two basic types of transfer methods, each with its own
advantages and limitations. Both types of connection make use of a
remote shell access program such as rsh, ssh or
telnet to connect to the remote machine.
This connection is used to perform many of the operations that TRAMP requires to make the remote file system transparently accessible from the local machine. It is only when visiting files that the methods differ.
Loading or saving a remote file requires that the content of the file
be transfered between the two machines. The content of the file can be
transfered over the same connection used to log in to the remote
machine or the file can be transfered through another connection using
a remote copy program such as rcp, scp or
rsync. The former are called inline methods, the
latter are called out-of-band methods or external transfer
methods (external methods for short).
The performance of the external transfer methods is generally better than that of the inline methods, at least for large files. This is caused by the need to encode and decode the data when transferring inline.
The one exception to this rule are the scp based transfer
methods. While these methods do see better performance when actually
transferring files, the overhead of the cryptographic negotiation at
startup may drown out the improvement in file transfer times.
External transfer methods do require that the remote copy command is not interactive -- that is, the command does not prompt you for a password. If you cannot perform remote copies without a password, you will need to use an inline transfer method to work with TRAMP.
A variant of the inline methods are the multi-hop methods. These methods allow you to connect a remote host using a number `hops', each of which connects to a different host. This is useful if you are in a secured network where you need to go through a bastion host to connect to the outside world.
The inline methods in TRAMP are quite powerful and can work in situations where you cannot use an external transfer program to connect. Inline methods are the only methods that work when connecting to the remote machine via telnet. (There are also strange inline methods which allow you to transfer files between user identities rather than hosts, see below.)
These methods depend on the existence of a suitable encoding and decoding command on remote machine. Locally, TRAMP may be able to use features of Emacs to decode and encode the files or it may require access to external commands to perform that task.
TRAMP checks the availability and usability of commands like
mimencode (part of the metamail package) or
uuencode on the remote host. The first reliable command
will be used. The search path can be customized, see Remote Programs.
If both commands aren't available on the remote host, TRAMP transfers a small piece of Perl code to the remote host, and tries to apply it for encoding and decoding.
rsh
Connect to the remote host with rsh. Due to the unsecure
connection it is recommended for very local host topology only.
On operating systems which provide the command remsh instead
of rsh, you can use the method remsh. This is true
for HP-UX or Cray UNICOS, for example.
ssh
Connect to the remote host with ssh. This is identical to
the previous option except that the ssh package is used,
making the connection more secure.
There are also two variants, ssh1 and ssh2, that
call ssh -1 and ssh -2, respectively. This way, you can
explicitly select whether you want to use the SSH protocol version 1
or 2 to connect to the remote host. (You can also specify in
~/.ssh/config, the SSH configuration file, which protocol
should be used, and use the regular ssh method.)
Two other variants, ssh1_old and ssh2_old, use the
ssh1 and ssh2 commands explicitly. If you don't
know what these are, you do not need these options.
All the methods based on ssh have an additional kludgy
feature: you can specify a host name which looks like host#42
(the real host name, then a hash sign, then a port number). This
means to connect to the given host but to also pass -p 42 as
arguments to the ssh command.
telnet
Connect to the remote host with telnet. This is as unsecure
as the rsh method.
su
This method does not connect to a remote host at all, rather it uses
the su program to allow you to edit files as another user.
sudo
This is similar to the su method, but it uses sudo
rather than su to become a different user.
Note that sudo must be configured to allow you to start a
shell as the user. It would be nice if it was sufficient if
ls and mimencode were allowed, but that is not
easy to implement, so I haven't got around to it, yet.
sshx
As you would expect, this is similar to ssh, only a little
different. Whereas ssh opens a normal interactive shell on
the remote host, this option uses ssh -t -t host -l
user /bin/sh to open a connection. This is useful for users
where the normal login shell is set up to ask them a number of
questions when logging in. This procedure avoids these questions, and
just gives TRAMP a more-or-less `standard' login shell to work
with.
Note that this procedure does not eliminate questions asked by
ssh itself. For example, ssh might ask "Are you
sure you want to continue connecting?" if the host key of the remote
host is not known. TRAMP does not know how to deal with such a
question (yet), therefore you will need to make sure that you can log
in without such questions.
This is also useful for Windows users where ssh, when
invoked from an Emacs buffer, tells them that it is not
allocating a pseudo tty. When this happens, the login shell is wont
to not print any shell prompt, which confuses TRAMP mightily. For
reasons unknown, some Windows ports for ssh (maybe the
Cygwin one) require the doubled -t option.
This supports the -p kludge.
krlogin
This method is also similar to ssh. It only uses the
krlogin -x command to log in to the remote host.
plink
This method is mostly interesting for Windows users using the PuTTY
implementation of SSH. It uses plink -ssh to log in to the
remote host.
Additionally, the method plink1 is provided, which calls
plink -1 -ssh in order to use SSH protocol version 1
explicitely.
CCC: Do we have to connect to the remote host once from the command line to accept the SSH key? Maybe this can be made automatic?
CCC: Does plink support the -p option? TRAMP will
support that, anyway.
The external transfer methods operate through multiple channels, using the remote shell connection for many actions while delegating file transfers to an external transfer utility.
This saves the overhead of encoding and decoding that multiplexing the transfer through the one connection has with the inline methods.
If you want to use an external transfer method you must be able to execute the transfer utility to copy files to and from the remote machine without any interaction.
This means that you will need to use ssh-agent if you use the
scp program for transfers, or maybe your version of
scp accepts a password on the command line.2
If you use rsync via ssh then the same rule must
apply to that connection.
If you cannot get scp to run without asking for a password but
would still like to use ssh to secure your connection, have a
look at the ssh based inline methods.
rcp -- rsh and rcp
This method uses the rsh and rcp commands to connect
to the remote machine and transfer files. This is probably the fastest
connection method available.
The alternative method remcp uses the remsh and
rcp commands. It should be applied on machines where
remsh is used instead of rsh.
scp -- ssh and scp
Using ssh to connect to the remote host and scp to
transfer files between the machines is the best method for securely
connecting to a remote machine and accessing files.
The performance of this option is also quite good. It may be slower than
the inline methods when you often open and close small files however.
The cost of the cryptographic handshake at the start of an scp
session can begin to absorb the advantage that the lack of encoding and
decoding presents.
There are also two variants, scp1 and scp2, that
call ssh -1 and ssh -2, respectively. This way, you can
explicitly select whether you want to use the SSH protocol version 1
or 2 to connect to the remote host. (You can also specify in
~/.ssh/config, the SSH configuration file, which protocol
should be used, and use the regular scp method.)
Two other variants, scp1_old and scp2_old, use the
ssh1 and ssh2 commands explicitly. If you don't
know what these are, you do not need these options.
All the ssh based methods support the kludgy -p
feature where you can specify a port number to connect to in the host
name. For example, the host name host#42 tells TRAMP to
specify -p 42 in the argument list for ssh.
rsync -- ssh and rsync
Using the ssh command to connect securely to the remote
machine and the rsync command to transfer files is almost
identical to the scp method.
While rsync performs much better than scp when
transferring files that exist on both hosts, this advantage is lost if
the file exists only on one side of the connection.
The rsync based method may be considerably faster than the
rcp based methods when writing to the remote system. Reading
files to the local machine is no faster than with a direct copy.
This method supports the -p hack.
scpx -- ssh and scp
As you would expect, this is similar to scp, only a little
different. Whereas scp opens a normal interactive shell on
the remote host, this option uses ssh -t -t host -l
user /bin/sh to open a connection. This is useful for users
where the normal login shell is set up to ask them a number of
questions when logging in. This procedure avoids these questions, and
just gives TRAMP a more-or-less `standard' login shell to work
with.
This is also useful for Windows users where ssh, when
invoked from an Emacs buffer, tells them that it is not
allocating a pseudo tty. When this happens, the login shell is wont
to not print any shell prompt, which confuses TRAMP mightily.
Maybe this applies to the Cygwin port of SSH.
This method supports the -p hack.
pscp -- plink and pscp
This method is similar to scp, but it uses the
plink command to connect to the remote host, and it uses
pscp for transferring the files. These programs are part
of PuTTY, an SSH implementation for Windows.
CCC: Does plink support the -p hack?
fcp -- fsh and fcp
This method is similar to scp, but it uses the fsh
command to connect to the remote host, and it uses fcp for
transferring the files. fsh/fcp are a front-end for
ssh which allow for reusing the same ssh session
for submitting several commands. This avoids the startup overhead of
scp (which has to establish a secure connection whenever it
is called). Note, however, that you can also use one of the inline
methods to achieve a similar effect.
This method uses the command fsh host -l user
/bin/sh -i to establish the connection, it does not work to just say
fsh host -l user.
There is no inline method using fsh as the multiplexing
provided by the program is not very useful in our context. TRAMP
opens just one connection to the remote host and then keeps it open,
anyway.
ftp
This is not a native TRAMP method. Instead of, it forwards all
requests to Ange-FTP.
smb -- smbclient
This is another not natural TRAMP method. It uses the
smbclient command on different Unices in order to connect to
an SMB server. An SMB server might be a Samba (or CIFS) server on
another UNIX host or, more interesting, a host running MS Windows. So
far, it is tested towards MS Windows NT, MS Windows 2000, and MS
Windows XP.
The first directory in the localname must be a share name on the remote
host. Remember, that the $ character in which default shares
usually end, must be written $$ due to environment variable
substitution in file names. If no share name is given (i.e. remote
directory /), all available shares are listed.
Since authorization is done on share level, you will be prompted always for a password if you access another share on the same host. This can be suppressed by Password caching.
MS Windows uses for authorization both a user name and a domain name.
Because of this, the TRAMP syntax has been extended: you can
specify a user name which looks like user%domain (the real user
name, then a percent sign, then the domain name). So, to connect to
the machine melancholia as user daniel of the domain
BIZARRE, and edit .emacs in the home directory (share
daniel$) I would specify the filename
/smb:daniel%BIZARRE@melancholia:/daniel$$/.emacs.
The domain name as well as the user name are optional. If no user name is specified at all, the anonymous user (without password prompting) is assumed. This is different from all other TRAMP methods, where in such a case the local user name is taken.
The smb method supports the -p hack.
Please note: If Emacs runs locally under MS
Windows, this method isn't available. Instead of, you can use UNC
file names like //melancholia/daniel$$/.emacs. The only
disadvantage is that there's no possibility to specify another user
name.
Sometimes, the methods described before are not sufficient. Sometimes, it is not possible to connect to a remote host using a simple command. For example, if you are in a secured network, you might have to log in to a `bastion host' first before you can connect to the outside world. Of course, the target host may also require a bastion host. The format of multi-hop filenames is slightly different than the format of normal TRAMP methods.
A multi-hop file name specifies a method, a number of hops, and a
localname (path name on the remote system). The method name is always
multi.
Each hop consists of a hop method specification, a user name and a host name. The hop method can be an inline method only. The following hop methods are (currently) available:
telnet
Uses the well-known telnet program to connect to the host.
Whereas user name and host name are supplied in the file name, the
user is queried for the password.
rsh
This uses rsh to connect to the host. You do not need to
enter a password unless rsh explicitly asks for it.
The variant remsh uses the remsh command. It
should be applied on machines where remsh is used instead of
rsh.
ssh
This uses ssh to connect to the host. You might have to enter
a password or a pass phrase.
su
This method does not actually contact a different host, but it allows
you to become a different user on the host you're currently on. This
might be useful if you want to edit files as root, but the remote host
does not allow remote root logins. In this case you can use
telnet, rsh or ssh to connect to the
remote host as a non-root user, then use an su hop to become
root. But su need not be the last hop in a sequence, you could
also use it somewhere in the middle, if the need arises.
Even though you must specify both user and host with an
su hop, the host name is ignored and only the user name is
used.
sudo
This is similar to the su hop, except that it uses
sudo rather than su to become a different user.
Some people might wish to use port forwarding with ssh or
maybe they have to use a nonstandard port. This can be accomplished
by putting a stanza in ~/.ssh/config for the account which
specifies a different port number for a certain host name. But it can
also be accomplished within TRAMP, by adding a multi-hop method.
For example:
(add-to-list
'tramp-multi-connection-function-alist
'("sshf" tramp-multi-connect-rlogin "ssh %h -l %u -p 4400%n"))
Now you can use an sshf hop which connects to port 4400 instead of
the standard port.
When you select an appropriate transfer method for your typical usage
you should set the variable tramp-default-method to reflect that
choice. This variable controls which method will be used when a method
is not specified in the TRAMP file name. For example:
(setq tramp-default-method "scp")
You can also specify different methods for certain user/host
combinations, via the variable tramp-default-method-alist. For
example, the following two lines specify to use the ssh
method for all user names matching john and the rsync
method for all host names matching lily. The third line
specifies to use the su method for the user root on
the machine localhost.
(add-to-list 'tramp-default-method-alist '("" "john" "ssh"))
(add-to-list 'tramp-default-method-alist '("lily" "" "rsync"))
(add-to-list 'tramp-default-method-alist
'("\\`localhost\\'" "\\`root\\'" "su"))
See the documentation for the variable
tramp-default-method-alist for more details.
External transfer methods are normally preferable to inline transfer methods, giving better performance. They may not be useful if you use many remote machines where you cannot log in without a password.
Voir Inline methods. Voir External transfer methods. Voir Multi-hop Methods.
Another consideration with the selection of transfer methods is the environment you will use them in and, especially when used over the Internet, the security implications of your preferred method.
The rsh and telnet methods send your password as
plain text as you log in to the remote machine, as well as transferring
the files in such a way that the content can easily be read from other
machines.
If you need to connect to remote systems that are accessible from the
Internet, you should give serious thought to using ssh based
methods to connect. These provide a much higher level of security,
making it a non-trivial exercise for someone to obtain your password or
read the content of the files you are editing.
Given all of the above, you are probably thinking that this is all fine and good, but it's not helping you to choose a method! Right you are. As a developer, we don't want to boss our users around but give them maximum freedom instead. However, the reality is that some users would like to have some guidance, so here I'll try to give you this guidance without bossing you around. You tell me whether it works ...
My suggestion is to use an inline method. For large files, out-of-band methods might be more efficient, but I guess that most people will want to edit mostly small files.
I guess that these days, most people can access a remote machine by
using ssh. So I suggest that you use the ssh method.
So, type C-x C-f /ssh:root@otherhost:/etc/motd <RET> to
edit the /etc/motd file on the other host.
If you can't use ssh to log in to the remote host, then select a
method that uses a program that works. For instance, Windows users
might like the plink method which uses the PuTTY implementation
of ssh. Or you use Kerberos and thus like krlogin.
For the special case of editing files on the local host as another
user, see the su or sudo method.
People who edit large files may want to consider scp instead of
ssh, or pscp instead of plink. These out-of-band
methods are faster than inline methods for large files. Note, however,
that out-of-band methods suffer from some limitations. Please try
first whether you really get a noticeable speed advantage from using an
out-of-band method! Maybe even for large files, inline methods are
fast enough.
The reason why I'm suggesting to use inline methods is that they work even if the remote end is asking you for a password. Out-of-band methods don't work in this situation. Also, multi-hop methods are inherently inline.
There is a variable tramp-methods which you can change if the
predefined methods don't seem right.
For the time being, I'll refer you to the Lisp documentation of that variable, accessible with C-h v tramp-methods <RET>.
The variable tramp-completion-function-alist is intended to
customize which files are taken into account for user and host name
completion (voir Filename completion). For every method, it keeps
a set of configuration files, accompanied by a Lisp function able to
parse that file. Entries in tramp-completion-function-alist
have the form (method pair1 pair2 ...).
Each pair is composed of (function file). function is responsible to extract user names and host names from file for completion. There are two functions which access this variable:
| tramp-get-completion-function method | Fonction |
|
This function returns the list of completion functions for method.
Example: (tramp-get-completion-function "rsh")
=> ((tramp-parse-rhosts "/etc/hosts.equiv")
(tramp-parse-rhosts "~/.rhosts"))
|
| tramp-set-completion-function method function-list | Fonction |
|
This function sets function-list as list of completion functions
for method.
Example: (tramp-set-completion-function "ssh"
'((tramp-parse-sconfig "/etc/ssh_config")
(tramp-parse-sconfig "~/.ssh/config")))
=> ((tramp-parse-sconfig "/etc/ssh_config")
(tramp-parse-sconfig "~/.ssh/config"))
|
The following predefined functions parsing configuration files exist:
tramp-parse-rhosts
This function parses files which are syntactical equivalent to
~/.rhosts. It returns both host names and user names, if
specified.
tramp-parse-shosts
This function parses files which are syntactical equivalent to
~/.ssh/known_hosts. Since there are no user names specified
in such files, it can return host names only.
tramp-parse-sconfig
This function returns the host nicknames defined by Host entries
in ~/.ssh/config style files.
tramp-parse-shostkeys
SSH2 parsing of directories /etc/ssh2/hostkeys/* and
~/ssh2/hostkeys/*. Hosts are coded in file names
hostkey_PORTNUMBER_HOST-NAME.pub. User names are always nil.
tramp-parse-sknownhosts
Another SSH2 style parsing of directories like
/etc/ssh2/knownhosts/* and ~/ssh2/knownhosts/*. This
case, hosts names are coded in file names
HOST-NAME.ALGORITHM.pub. User names are always nil.
tramp-parse-hosts
A function dedicated to /etc/hosts style files. It returns
host names only.
tramp-parse-passwd
A function which parses /etc/passwd like files. Obviously, it
can return user names only.
tramp-parse-netrc
Finally, a function which parses ~/.netrc like files.
If you want to keep your own data in a file, with your own structure, you might provide such a function as well. This function must meet the following conventions:
| my-tramp-parse file | Fonction |
file must be either a file name on your host, or nil. The
function must return a list of (user host), which are
taken as candidates for user and host name completion.
Example: (my-tramp-parse "~/.my-tramp-hosts")
=> ((nil "toto") ("daniel" "melancholia"))
|
Sometimes it is necessary to connect to the same remote host several times. Reentering passwords again and again would be annoying, when the choosen method does not support access without password prompt throught own configuration.
By default, TRAMP caches the passwords entered by you. They will be reused next time if a connection needs them for the same user name and host name, independant of the connection method.
Passwords are not saved permanently, that means the password caching
is limited to the lifetime of your Emacs session. You
can influence the lifetime of password caching by customizing the
variable password-cache-expiry. The value is the number of
seconds how long passwords are cached. Setting it to nil
disables the expiration.
A password is removed from the cache if a connection isn't established successfully. You can remove a password from the cache also by executing M-x tramp-clear-passwd in a buffer containing a related remote file or directory.
If you don't like this feature for security reasons, password caching
can be disabled totally by customizing the variable
password-cache (setting it to nil).
Implementation Note: password caching is based on the package
password.el in No Gnus. For the time being, it is activated only when
this package is seen in the load-path while loading TRAMP.
If you don't use No Gnus, you can take password.el from the TRAMP
contrib directory, see Installation parameters.
It will be activated mandatory once No Gnus has found its way into
Emacs.
TRAMP depends on a number of programs on the remote host in order to
function, including ls, test, find and
cat.
In addition to these required tools, there are various tools that may be required based on the connection method. See Inline methods and External transfer methods for details on these.
Certain other tools, such as perl (or perl5) and
grep will be used if they can be found. When they are
available, they are used to improve the performance and accuracy of
remote file access.
When TRAMP connects to the remote machine, it searches for the programs that it can use. The variable tramp-remote-path controls the directories searched on the remote machine.
By default, this is set to a reasonable set of defaults for most machines. It is possible, however, that your local (or remote ;) system administrator has put the tools you want in some obscure local directory.
In this case, you can still use them with TRAMP. You simply need to
add code to your .emacs to add the directory to the remote path.
This will then be searched by TRAMP when you connect and the software
found.
To add a directory to the remote search path, you could use code such as:
;; We load TRAMP to define the variable.
(require 'tramp)
;; We have perl in "/usr/local/perl/bin"
(add-to-list 'tramp-remote-path "/usr/local/perl/bin")
As explained in the Overview section, TRAMP connects to the remote host and talks to the shell it finds there. Of course, when you log in, the shell executes its init files. Suppose your init file requires you to enter the birth date of your mother; clearly TRAMP does not know this and hence fails to log you in to that host.
There are different possible strategies for pursuing this problem. One strategy is to enable TRAMP to deal with all possible situations. This is a losing battle, since it is not possible to deal with all situations. The other strategy is to require you to set up the remote host such that it behaves like TRAMP expects. This might be inconvenient because you have to invest a lot of effort into shell setup before you can begin to use TRAMP.
The package, therefore, pursues a combined approach. It tries to figure
out some of the more common setups, and only requires you to avoid
really exotic stuff. For example, it looks through a list of
directories to find some programs on the remote host. And also, it
knows that it is not obvious how to check whether a file exists, and
therefore it tries different possibilities. (On some hosts and shells,
the command test -e does the trick, on some hosts the shell
builtin doesn't work but the program /usr/bin/test -e or
/bin/test -e works. And on still other hosts, ls -d is
the right way to do this.)
Below you find a discussion of a few things that TRAMP does not deal with, and that you therefore have to set up correctly.
After logging in to the remote host, TRAMP has to wait for the remote
shell startup to finish before it can send commands to the remote
shell. The strategy here is to wait for the shell prompt. In order to
recognize the shell prompt, the variable shell-prompt-pattern has
to be set correctly to recognize the shell prompt on the remote host.
Note that TRAMP requires the match for shell-prompt-pattern
to be at the end of the buffer. Many people have something like the
following as the value for the variable: "^[^>$][>$] *". Now
suppose your shell prompt is a <b> c $ . In this case,
TRAMP recognizes the > character as the end of the prompt,
but it is not at the end of the buffer.
This regular expression is used by TRAMP in the same way as
shell-prompt-pattern, to match prompts from the remote shell.
This second variable exists because the prompt from the remote shell
might be different from the prompt from a local shell -- after all,
the whole point of TRAMP is to log in to remote hosts as a
different user. The default value of
tramp-shell-prompt-pattern is the same as the default value of
shell-prompt-pattern, which is reported to work well in many
circumstances.
tset and other questions
Some people invoke the tset program from their shell startup
scripts which asks the user about the terminal type of the shell.
Maybe some shells ask other questions when they are started. TRAMP
does not know how to answer these questions. There are two approaches
for dealing with this problem. One approach is to take care that the
shell does not ask any questions when invoked from TRAMP. You can
do this by checking the TERM environment variable, it will be
set to dumb when connecting.
The variable tramp-terminal-type can be used to change this value
to dumb.
The other approach is to teach TRAMP about these questions. See
the variables tramp-actions-before-shell and
tramp-multi-actions (for multi-hop connections).
.profile
FRUMPLE in
your shell environment, then this might cause trouble. Maybe rename
the variable to FRUMPLE_DIR or the like.
This weird effect was actually reported by a TRAMP user!
.profile
exec /bin/sh. (Actually, the command is slightly different.)
When /bin/sh is executed, it reads some init files, such as
~/.shrc or ~/.profile.
Now, some people have a login shell which is not /bin/sh but a
Bourne-ish shell such as bash or ksh. Some of these people might put
their shell setup into the files ~/.shrc or ~/.profile.
This way, it is possible for non-Bourne constructs to end up in those
files. Then, exec /bin/sh might cause the Bourne shell to barf
on those constructs.
As an example, imagine somebody putting export FOO=bar into the
file ~/.profile. The standard Bourne shell does not understand
this syntax and will emit a syntax error when it reaches this line.
Another example is the tilde (~) character, say when adding
~/bin to $PATH. Many Bourne shells will not expand this
character, and since there is usually no directory whose name consists
of the single character tilde, strange things will happen.
What can you do about this?
Well, one possibility is to make sure that everything in ~/.shrc
and ~/.profile on all remote hosts is Bourne-compatible. In the
above example, instead of export FOO=bar, you might use
FOO=bar; export FOO instead.
The other possibility is to put your non-Bourne shell setup into some
other files. For example, bash reads the file ~/.bash_profile
instead of ~/.profile, if the former exists. So bash
aficionados just rename their ~/.profile to
~/.bash_profile on all remote hosts, and Bob's your uncle.
The TRAMP developers would like to circumvent this problem, so if you
have an idea about it, please tell us. However, we are afraid it is not
that simple: before saying exec /bin/sh, TRAMP does not know
which kind of shell it might be talking to. It could be a Bourne-ish
shell like ksh or bash, or it could be a csh derivative like tcsh, or
it could be zsh, or even rc. If the shell is Bourne-ish already, then
it might be prudent to omit the exec /bin/sh step. But how to
find out if the shell is Bourne-ish?
Normally, Emacs writes backup files to the same directory
as the original files, but this behavior can be changed via the
variable backup-directory-alist. In connection with TRAMP,
this can have unexpected side effects. Suppose that you specify that
all backups should go to the directory ~/.emacs.d/backups/, and
then you edit the file /su:root@localhost:/etc/secretfile.
The effect is that the backup file will be owned by you and not by
root, thus possibly enabling others to see it even if they were not
intended to see it.
When backup-directory-alist is nil (the default), such problems
do not occur.
If you wish to customize the variable, the workaround is to include
special settings for TRAMP files. For example, the following statement
effectively `turns off' the effect of backup-directory-alist for
TRAMP files:
(require 'tramp)
(add-to-list 'backup-directory-alist
(cons tramp-file-name-regexp nil))
The same problem can happen with auto-saving files.
Since Emacs 21, the variable
auto-save-file-name-transforms keeps information, on which
directory an auto-saved file should go. By default, it is initialized
for TRAMP files to the local temporary directory.
On some versions of Emacs, namely the version built for
Debian Linux, the variable auto-save-file-name-transforms
contains the directory where Emacs was built. A
workaround is to manually set the variable to a sane value.
If auto-saved files should go into the same directory as the original
files, auto-save-file-name-transforms should be set to nil.
Another possibility is to set the variable
tramp-auto-save-directory to a proper value.
This section needs a lot of work! Please help.
If you use the Cygwin installation of ssh (you have to explicitly select
it in the installer), then it should work out of the box to just select
sshx as the connection method. You can find information about
setting up Cygwin in their FAQ at http://cygwin.com/faq/.
If you wish to use the scpx connection method, then you might
have the problem that Emacs calls scp with a
Windows filename such as c:/foo. The Cygwin version of
scp does not know about Windows filenames and interprets this
as a remote filename on the host c.
One possible workaround is to write a wrapper script for scp
which converts the Windows filename to a Cygwinized filename.
I guess that another workaround is to run Emacs under Cygwin, or to run a Cygwinized Emacs.
If you want to use either ssh based method on Windows, then you
might encounter problems with ssh-agent. Using this program,
you can avoid typing the pass-phrase every time you log in (and the
scpx method more or less requires you to use ssh-agent
because it does not allow you to type a password or pass-phrase).
However, if you start Emacs from a desktop shortcut, then
the environment variable SSH_AUTH_SOCK is not set and so
Emacs and thus TRAMP and thus ssh and
scp started from TRAMP cannot communicate with
ssh-agent. It works better to start Emacs from
the shell.
If anyone knows how to start ssh-agent under Windows in such a
way that desktop shortcuts can profit, please holler. I don't really
know anything at all about Windows...
Once you have installed TRAMP it will operate fairly transparently. You will be able to access files on any remote machine that you can log in to as though they were local.
Files are specified to TRAMP using a formalized syntax specifying the details of the system to connect to. This is similar to the syntax used by the Ange-FTP package.
Something that might happen which surprises you is that Emacs remembers all your keystrokes, so if you see a password prompt from Emacs, say, and hit <RET> twice instead of once, then the second keystroke will be processed by Emacs after TRAMP has done its thing. Why, this type-ahead is normal behavior, you say. Right you are, but be aware that opening a remote file might take quite a while, maybe half a minute when a connection needs to be opened. Maybe after half a minute you have already forgotten that you hit that key!
To access the file localname on the remote machine machine you
would specify the filename
/machine:localname.
This will connect to machine and transfer the file using the
default method. Voir Default Method.
Some examples of TRAMP filenames are shown below.
/melancholia:.emacs
.emacs in your home directory on the machine
melancholia.
/melancholia.danann.net:.emacs
/melancholia:~/.emacs
~ is expanded to your
home directory on the remote machine, just like it is locally.
/melancholia:~daniel/.emacs
.emacs in the home directory of the user
daniel on the machine melancholia. The ~<user>
construct is expanded to the home directory of that user on the remote
machine.
/melancholia:/etc/squid.conf
/etc/squid.conf on the machine
melancholia.
Unless you specify a different name to use, TRAMP will use the current local user name as the remote user name to log in with. If you need to log in as a different user, you can specify the user name as part of the filename.
To log in to the remote machine as a specific user, you use the syntax
/user@machine:/path/to.file.
That means that connecting to melancholia as daniel and
editing .emacs in your home directory you would specify
/daniel@melancholia:.emacs.
It is also possible to specify other file transfer methods
(voir Default Method) as part of the filename.
This is done by putting the method before the user and host name, as
in
/method:
(Note the trailing colon).
The user, machine and file specification remain the same.
So, to connect to the machine melancholia as daniel,
using the ssh method to transfer files, and edit .emacs
in my home directory I would specify the filename
/ssh:daniel@melancholia:.emacs.
The syntax of multi-hop file names is necessarily slightly different than the syntax of other TRAMP file names. Here's an example multi-hop file name:
/multi:rsh:out@gate:telnet:kai@real.host:/path/to.file
This is quite a mouthful. So let's go through it step by step. The
file name consists of three parts.
The parts are separated by colons
The first part is /multi, the method
specification. The second part is
rsh:out@gate:telnet:kai@real.host
and specifies the hops. The final part is /path/to.file and
specifies the file name on the remote host.
The first part and the final part should be clear. See Multi-hop Methods, for a list of alternatives for the method specification.
The second part can be subdivided again into components, so-called
hops. In the above file name, there are two hops,
rsh:out@gate and
telnet:kai@real.host.
Each hop can again be subdivided into (three) components, the hop method, the user name and the host name. The meaning of the second and third component should be clear, and the hop method says what program to use to perform that hop.
The first hop, rsh:out@gate,
says to use rsh to log in as user out to the host
gate. Starting at that host, the second hop,
telnet:kai@real.host, says to
use telnet to log in as user kai to host
real.host.
Voir Multi-hop Methods, for a list of possible hop method values.
The variable tramp-multi-connection-function-alist contains the
list of possible hop methods and information on how to execute them,
should you want to add your own.
Filename completion works with TRAMP for both completing methods, user names and machine names (except multi hop methods) as well as for files on remote machines.
If you, for example, type C-x C-f /t <TAB>, TRAMP might give you as result the choice for
telnet: tmp/
toto:
telnet:
is a possible completion for the respective method,
tmp/ stands for the directory /tmp on your local
machine,
and toto:
might be a host TRAMP has detected in your ~/.ssh/known_hosts
file (given you're using default method ssh).
If you go on to type e <TAB>, the minibuffer is completed to
/telnet:.
Next <TAB> brings you all machine names TRAMP detects in
your /etc/hosts file, let's say
telnet:127.0.0.1: telnet:192.168.0.1:
telnet:localhost: telnet:melancholia.danann.net:
telnet:melancholia:
Now you can choose the desired machine, and you can continue to complete file names on that machine.
As filename completion needs to fetch the listing of files from the remote machine, this feature is sometimes fairly slow. As TRAMP does not yet cache the results of directory listing, there is no gain in performance the second time you complete filenames.
If the configuration files (voir Customizing Completion), which TRAMP uses for analysis of completion, offer user names, those user names will be taken into account as well.
TRAMP works transparently with dired, enabling you to use this powerful file management tool to manage files on any machine you have access to over the Internet.
If you need to browse a directory tree, Dired is a better choice, at present, than filename completion. Dired has its own cache mechanism and will only fetch the directory listing once.
Bugs and problems with TRAMP are actively worked on by the development team. Feature requests and suggestions are also more than welcome.
The TRAMP mailing list is a great place to get information on working with TRAMP, solving problems and general discussion and advice on topics relating to the package.
The mailing list is at tramp-devel@mail.freesoftware.fsf.org. Messages sent to this address go to all the subscribers. This is not the address to send subscription requests to.
For help on subscribing to the list, send mail to the administrative
address, tramp-devel-request@mail.freesoftware.fsf.org, with the
subject help.
To report a bug in TRAMP, you should execute M-x tramp-bug. This will automatically generate a buffer with the details of your system and TRAMP version.
When submitting a bug report, please try to describe in excruciating detail the steps required to reproduce the problem, the setup of the remote machine and any special conditions that exist.
If you can identify a minimal test case that reproduces the problem, include that with your bug report. This will make it much easier for the development team to analyze and correct the problem.
TRAMP is available under the URL below. http://savannah.nongnu.org/download/tramp/
There is also a Savannah project page. http://savannah.nongnu.org/projects/tramp/
The package has been used successfully on Emacs 20 and Emacs 21, as well
as XEmacs 21. XEmacs 20 is more problematic, see the notes in
tramp.el. I don't think anybody has really tried it on Emacs 19.
The package was intended to work on Unix, and it really expects a
Unix-like system on the remote end (except the smb method),
but some people seemed to have some success getting it to work on NT
Emacs.
There is some informations on TRAMP on NT at the following URL; many thanks to Joe Stoy for providing the information: ftp://ftp.comlab.ox.ac.uk/tmp/Joe.Stoy/
The above mostly contains patches to old ssh versions; Tom Roche has a Web page with instructions: http://www4.ncsu.edu/~tlroche/plinkTramp.html
??? Is the XEmacs info correct?
??? Can somebody provide some information for getting it to work on NT
Emacs? I think there was some issue with ssh?
file-name-handler-alist's value is
(("^/[^/:]*\\'" . ange-ftp-completion-hook-function)
("^/[^/:]*[^/:.]:" . ange-ftp-hook-function)
("^/[^/]*$" . tramp-completion-file-name-handler)
("\\`/[^/:]+:" . tramp-file-name-handler)
("\\`/:" . file-name-non-special))
Please try to find out which package is responsible for loading Ange-FTP, and raise a bug report.
A workaround is to require Ange-FTP before TRAMP in
your ~/.emacs, because TRAMP cleans up the entries in
file-name-handler-alist:
;; Ange-FTP temporarily required
(require 'ange-ftp)
;; TRAMP cleans up file-name-handler-alist
(require 'tramp)
When you log in to the remote machine, do you see the output of
ls in color? If so, this may be the cause of your problems.
ls outputs ANSI escape sequences that your terminal
emulator interprets to set the colors. These escape sequences will
confuse TRAMP however.
In your .bashrc, .profile or equivalent on the remote
machine you probably have an alias configured that adds the option
--color=yes or --color=auto.
You should remove that alias and ensure that a new login does not
display the output of ls in color. If you still cannot use
filename completion, report a bug to the TRAMP developers.
TRAMP uses globbing for some operations. (Globbing means to use the shell to expand wildcards such as `*.c'.) This might create long command lines, especially in directories with many files. Some shells choke on long command lines, or don't cope well with the globbing itself.
If you have a large directory on the remote end, you may wish to execute
a command like ls -d * ..?* > /dev/null and see if it hangs.
Note that you must first start the right shell, which might be
/bin/sh, ksh or bash, depending on which
of those supports tilde expansion.
TRAMP really expects the remote system to be a Unix-like system. The local system should preferably be Unix-like, as well, but TRAMP might work on NT with some tweaking.
The following snippet can be put in your ~/.emacs file. It
makes Emacs beep after reading from or writing to the
remote host.
(defadvice tramp-handle-write-region
(after tramp-write-beep-advice activate)
" make tramp beep after writing a file."
(interactive)
(beep))
(defadvice tramp-handle-do-copy-or-rename-file
(after tramp-copy-beep-advice activate)
" make tramp beep after copying a file."
(interactive)
(beep))
(defadvice tramp-handle-insert-file-contents
(after tramp-copy-beep-advice activate)
" make tramp beep after copying a file."
(interactive)
(beep))
~/.sh_history file on the remote host which keeps
growing and growing. What's that?
Sometimes, TRAMP starts ksh on the remote host for tilde
expansion. Maybe ksh saves the history by default. TRAMP
tries to turn off saving the history, but maybe you have to help. For
example, you could put this in your .kshrc:
if [ -f $HOME/.sh_history ] ; then
/bin/rm $HOME/.sh_history
fi
if [ "${HISTFILE-unset}" != "unset" ] ; then
unset HISTFILE
fi
if [ "${HISTSIZE-unset}" != "unset" ] ; then
unset HISTSIZE
fi
On some few systems, the implementation of process-send-string
seems to be broken for longer strings. This case, you should
customize the variable tramp-chunksize to 500. For a
description how to determine whether this is necessary see the
documentation of tramp-chunksize.
Unlike Ange-FTP, TRAMP has full shell access to the remote machine. This makes it possible to provide version control for files accessed under TRAMP.
The actual version control binaries must be installed on the remote machine, accessible in the directories specified in tramp-remote-path.
This transparent integration with the version control systems is one of the most valuable features provided by TRAMP, but it is far from perfect. Work is ongoing to improve the transparency of the system.
The VC package uses the existence of on-disk revision control master files to determine if a given file is under revision control. These file tests happen on the remote machine through the standard TRAMP mechanisms.
There are no hooks provided by VC to allow intercepting of the version
control command execution. The calls occur through the
call-process mechanism, a function that is somewhat more
efficient than the shell-command function but that does not
provide hooks for remote execution of commands.
To work around this, the functions vc-do-command and
vc-simple-command have been advised to intercept requests for
operations on files accessed via TRAMP.
In the case of a remote file, the shell-command interface is
used, with some wrapper code, to provide the same functionality on the
remote machine as would be seen on the local machine.
As there is currently no way to get access to the mtime of a file on a
remote machine in a portable way, the vc-workfile-unchanged-p
function is advised to call an TRAMP specific function for remote files.
The tramp-vc-workfile-unchanged-p function uses the functioning VC
diff functionality to determine if any changes have occurred between the
workfile and the version control master.
This requires that a shell command be executed remotely, a process that is notably heavier-weight than the mtime comparison used for local files. Unfortunately, unless a portable solution to the issue is found, this will remain the cost of remote version control.
VC will, by default, check for remote files and refuse to act on them
when checking out files from the repository. To work around this
problem, the function vc-checkout knows about TRAMP files and
allows version control to occur.
Minor implementation details, &c.
user-full-name function to
return the login name of the current user as well as mapping from
arbitrary user id values back to login names. The VC code uses this
functionality to map from the uid of the owner of a workfile to the
login name in some circumstances.
This will not, for obvious reasons, work if the remote system has a different set of logins. As such, it is necessary to delegate to the remote machine the job of determining the login name associated with a uid.
Unfortunately, with the profusion of distributed management systems such
as NIS, NIS+ and NetInfo, there is no simple,
reliable and portable method for performing this mapping.
Thankfully, the only place in the VC code that depends on the mapping of
a uid to a login name is the vc-file-owner function. This returns
the login of the owner of the file as a string.
This function has been advised to use the output of ls on the
remote machine to determine the login name, delegating the problem of
mapping the uid to the login to the remote system which should know more
about it than I do.
VC needs to know what release your revision control binaries you are
running as not all features VC supports are available with older
versions of rcs(1), cvs(1) or sccs(1).
The default implementation of VC determines this value the first time it is needed and then stores the value globally to avoid the overhead of executing a process and parsing its output each time the information is needed.
Unfortunately, life is not quite so easy when remote version control comes into the picture. Each remote machine may have a different version of the version control tools and, while this is painful, we need to ensure that unavailable features are not used remotely.
To resolve this issue, TRAMP currently takes the sledgehammer approach of making the release values of the revision control tools local to each TRAMP buffer, forcing VC to determine these values again each time a new file is visited.
This has, quite obviously, some performance implications. Thankfully, most of the common operations performed by VC do not actually require that the remote version be known. This makes the problem far less apparent.
Eventually these values will be captured by TRAMP on a system by system basis and the results cached to improve performance.
TRAMP file names are somewhat different, obviously, to ordinary file
names. As such, the lisp functions file-name-directory and
file-name-nondirectory are overridden within the TRAMP
package.
Their replacements are reasonably simplistic in their approach. They dissect the filename, call the original handler on the localname and then rebuild the TRAMP file name with the result.
This allows the platform specific hacks in the original handlers to take effect while preserving the TRAMP file name information.
Due to the design of TRAMP, the encoding and decoding programs need to
read from stdin and write to stdout. On some systems, uudecode -o
- will read stdin and write the decoded file to stdout, on other
systems uudecode -p does the same thing. But some systems have
uudecode implementations which cannot do this at all--it is not
possible to call these uudecode implementations with suitable parameters
so that they write to stdout.
Of course, this could be circumvented: the begin foo 644 line
could be rewritten to put in some temporary file name, then
uudecode could be called, then the temp file could be printed and
deleted.
But I have decided that this is too fragile to reliably work, so on some systems you'll have to do without the uuencode methods.
This is because it requires the macro with-timeout which does not
appear to exist in XEmacs 20. I'm somewhat reluctant to add an
emulation macro to TRAMP, but if somebody who uses XEmacs 20 steps
forward and wishes to implement and test it, please contact me or the
mailing list.
The Emacs maintainers wish to use a unified filename syntax for Ange-FTP and TRAMP so that users don't have to learn a new syntax. It is sufficient to learn some extensions to the old syntax.
For the XEmacs maintainers, the problems caused from using a unified filename syntax are greater than the gains. The XEmacs package system uses EFS for downloading new packages. So, obviously, EFS has to be installed from the start. If the filenames were unified, TRAMP would have to be installed from the start, too.
.login file: Remote shell setup
.profile file: Remote shell setup