This file documents tramp version 2.1.13, a remote file editing package for GNU 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.gnu.org/software/tramp/.
The manual has been generated for GNU Emacs. If you're using the other Emacs flavor, you should read the XEmacs pages.
This manual is also available as a Japanese translation.
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@gnu.org, and archived at
the tramp Mail Archive.
Older archives are located at
SourceForge Mail Archive and
The Mail Archive.
Copyright © 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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.2 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 the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom.”
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.
For the end user:
For the developer:
--- The Detailed Node Listing ---
Installing tramp with your GNU Emacs
Configuring tramp for use
Using tramp
The inner workings of remote version control
Things related to Version Control that don't fit elsewhere
How file names, directories and localnames are mangled and managed
After the installation of tramp into your GNU 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.
Under Windows, tramp is integrated with the PuTTY package, using the plink program.
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, rsync or (under Windows) pscp.
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.
tramp is still under active development and any problems you encounter, trivial or major, should be reported to the tramp developers. See 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:
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.
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 ftp://ftp.gnu.org/gnu/tramp/. This release includes the full documentation and code for tramp, suitable for installation. But GNU Emacs (22 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.gnu.org/projects/tramp/
Or follow the example session below:
] cd ~/emacs
] export CVS_RSH="ssh"
] cvs -z3 -d:ext:anoncvs@savannah.gnu.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
People who have no direct CVS access (maybe because sitting behind a blocking firewall), can try the Nightly CVS Tree Tarball instead of.
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. In July 2004, multi-hop methods have been replaced by proxy hosts. Running commands on remote hosts was introduced in December 2005. Support of gateways exists since April 2007.
In December 2001, tramp has been added to the XEmacs package repository. Being part of the GNU Emacs repository happened in June 2002, the first release including tramp was GNU Emacs 22.1.
tramp is also a GNU/Linux Debian package since February 2001.
If you use the version that comes with your GNU Emacs, the following information is not necessary. Installing tramp into your GNU 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:
ln -s tramp-2.1.13 tramp
Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for.
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 GNU Emacs. Then press M-x texinfo-format-buffer <RET> to generate ~/emacs/tramp/info/tramp.
There are some Lisp packages which are not contained in older GNU Emacsen by default yet. In order to make a link for them into Tramp's contrib directory, you must use the --with-contrib option:
./configure --with-contrib
By default, make install will install tramp's files in /usr/local/share/emacs/site-lisp and /usr/local/share/info. You can specify an installation prefix other than /usr/local by giving configure the option --prefix=PATH. On GNU/Linux systems, it has been reported useful to apply
./configure --prefix=/usr
If your installed copy of GNU 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
You can even pass the GNU Emacs or XEmacs command to be called:
./configure --with-xemacs=xemacs21
If you specify the absolute path of the command, it must not contain whitespaces. If you need it, the corresponding path shall be appended to the $PATH environment variable.
The syntax of tramp file names is different for GNU 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 declare the directories Lisp and Info files should be installed.
For example, to put the Lisp files in ~/elisp and the Info file in ~/info, you would type:
./configure --with-lispdir=$HOME/elisp --infodir=$HOME/info
On MS Windows, given Emacs is installed at C:/Program Files/Emacs, you should apply
./configure --with-lispdir='C:/Program Files/Emacs/site-lisp' \
--infodir='C:/Program Files/Emacs/info'
make supports the DESTDIR variable for staged installation; see Command Variables:
make DESTDIR=/tmp install
Running configure might result in errors or warnings. The output explains in detail what's going wrong.
In case of errors, it is mandatory to fix them before continuation. This can be missing or wrong versions of emacs, GNU Emacs packages, make, or makeinfo.
Warnings let configure (and the whole installation process) continue, but parts of Tramp aren't installed. This can happen with missing or wrong versions of texi2dvi or install-info. Here you can decide yourself whether you want to renounce on the related feature (tramp.dvi file for printed output, Tramp entry in Info's dir file), or whether you want to adapt your $PATH environment variable, and rerun configure. An alternative is calling the missed parts manually later on.
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/")
(require 'tramp)
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 see Top.
tramp is (normally) fully functional when it is initially installed. It is initially configured to use the scp program to connect to the remote host. 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 See 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 (see Connection types).
If you don't know which method is right for you, see See 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 should be configured such a way that they don't require a password (with ssh-agent, or such alike). Modern scp implementations offer options to reuse existing ssh connections, see method scpc. If it isn't possible, you should consider Password caching, otherwise you will be prompted for a password every copy action.
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 GNU 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.
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.
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.
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.
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 GNU 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 require the doubled `-t' option.
This supports the `-p' kludge.
This supports the `-P' kludge.
Additionally, the methods plink1 and plink2 are provided, which call `plink -1 -ssh' or `plink -2 -ssh' in order to use SSH protocol version 1 or 2 explicitly.
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: Say something about the first shell command failing. This might
be due to a wrong setting of tramp-rsh-end-of-line.
The implementation lacks good performance. The code is offered anyway, maybe somebody can improve the performance.
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.
Since external transfer methods need their own overhead opening a new channel, all files which are smaller than tramp-copy-size-limit are still transferred with the corresponding inline method. It should provide a fair trade-off between both approaches.
The alternative method remcp uses the remsh and
rcp commands. It should be applied on machines where
remsh is used instead of rsh.
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, and to
specify `-P 42' in the argument list for scp.
This command does not work like Ange-FTP, where ftp is called interactively, and all commands are send from within this session. Instead of, ssh is used for login.
This method supports the `-p' hack.
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.
This is also useful for Windows users where ssh, when invoked from an GNU 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.
This method supports the `-p' hack.
Before you use this method, you shall check whether your ssh implementation does support this option. Try from the command line
ssh localhost -o ControlMaster=yes
This method supports the `-p' hack.
This method supports the `-P' hack.
This method supports the `-P' hack.
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.
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.
Depending on the Windows domain configuration, a Windows user might be
considered as domain user per default. In order to connect as local
user, the WINS name of that machine must be given as domain name.
Usually, it is the machine name in capital letters. In the example
above, the local user daniel would be specified as
/smb:daniel%MELANCHOLIA@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 GNU 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.
Gateway methods are not methods to access a remote host directly. These methods are intended to pass firewalls or proxy servers. Therefore, they can be used for proxy host declarations (see Multi-hops) only.
A gateway method must come always along with a method who supports port setting (referred to as `-p' kludge). This is because tramp targets the accompanied method to localhost#random_port, from where the firewall or proxy server is accessed to.
Gateway methods support user name and password declarations. These are used to authenticate towards the corresponding firewall or proxy server. They can be passed only if your friendly administrator has granted your access.
As authentication method, only Basic Authentication (see RFC
2617) is implemented so far. If no port number is given in the
declaration, port 8080 is used for the proxy server.
The default port number of the socks server is 1080, if not specified otherwise.
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 "ssh")
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.
See Inline methods. See External transfer 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 methods. They offer shortened syntax for the `root' account, like /su::/etc/motd.
People who edit large files may want to consider scpc 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 user part of a tramp file name can be omitted. Usually,
it is replaced by the user name you are logged in. Often, this is not
what you want. A typical use of tramp might be to edit some
files with root permissions on the local host. This case, you should
set the variable tramp-default-user to reflect that choice.
For example:
(setq tramp-default-user "root")
tramp-default-user is regarded as obsolete, and will be removed
soon.
You can also specify different users for certain method/host
combinations, via the variable tramp-default-user-alist. For
example, if you always have to use the user `john' in the domain
`somewhere.else', you can specify the following:
(add-to-list 'tramp-default-user-alist
'("ssh" ".*\\.somewhere\\.else\\'" "john"))
See the documentation for the variable
tramp-default-user-alist for more details.
One trap to fall in must be known. If tramp finds a default user, this user will be passed always to the connection command as parameter (for example `ssh here.somewhere.else -l john'. If you have specified another user for your command in its configuration files, tramp cannot know it, and the remote access will fail. If you have specified in the given example in ~/.ssh/config the lines
Host here.somewhere.else
User lily
than you must discard selecting a default user by tramp. This
will be done by setting it to nil (or `lily', likewise):
(add-to-list 'tramp-default-user-alist
'("ssh" "\\`here\\.somewhere\\.else\\'" nil))
The last entry in tramp-default-user-alist could be your
default user you'll apply predominantly. You shall append it
to that list at the end:
(add-to-list 'tramp-default-user-alist '(nil nil "jonas") t)
Finally, it is even possible to omit the host name part of a
tramp file name. This case, the value of the variable
tramp-default-host is used. Per default, it is initialized
with the host name your local GNU Emacs is running.
If you, for example, use tramp mainly to contact the host `target' as user `john', you can specify:
(setq tramp-default-user "john"
tramp-default-host "target")
Then the simple file name `/ssh::' will connect you to John's home directory on target. Note, however, that the most simplification `/::' won't work, because `/:' is the prefix for quoted file names.
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.
In order to specify such multiple hops, it is possible to define a proxy
host to pass through, via the variable
tramp-default-proxies-alist. This variable keeps a list of
triples (host user proxy).
The first matching item specifies the proxy host to be passed for a
file name located on a remote target matching user@host.
host and user are regular expressions or nil, which
is interpreted as a regular expression which always matches.
proxy must be a Tramp filename which localname part is ignored.
Method and user name on proxy are optional, which is interpreted
with the default values.
The method must be an inline or gateway method (see Inline methods, see Gateway methods).
If proxy is nil, no additional hop is required reaching
user@host.
If you, for example, must pass the host `bastion.your.domain' as user `bird' for any remote host which is not located in your local domain, you can set
(add-to-list 'tramp-default-proxies-alist
'("\\." nil "/ssh:bird@bastion.your.domain:"))
(add-to-list 'tramp-default-proxies-alist
'("\\.your\\.domain\\'" nil nil))
Please note the order of the code. add-to-list adds elements at the
beginning of a list. Therefore, most relevant rules must be added last.
Proxy hosts can be cascaded. If there is another host called `jump.your.domain', which is the only one in your local domain who is allowed connecting `bastion.your.domain', you can add another rule:
(add-to-list 'tramp-default-proxies-alist
'("\\`bastion\\.your\\.domain\\'"
"\\`bird\\'"
"/ssh:jump.your.domain:"))
proxy can contain the patterns %h or %u. These
patterns are replaced by the strings matching host or
user, respectively.
If you, for example, wants to work as `root' on hosts in the domain `your.domain', but login as `root' is disabled for non-local access, you might add the following rule:
(add-to-list 'tramp-default-proxies-alist
'("\\.your\\.domain\\'" "\\`root\\'" "/ssh:%h:"))
Opening /sudo:randomhost.your.domain: would connect
first `randomhost.your.domain' via ssh under your account
name, and perform sudo -u root on that host afterwards. It is
important to know that the given method is applied on the host which
has been reached so far. sudo -u root, applied on your local
host, wouldn't be useful here.
This is the recommended configuration to work as `root' on remote Ubuntu hosts.
Finally, tramp-default-proxies-alist can be used to pass
firewalls or proxy servers. Imagine your local network has a host
`proxy.your.domain' which is used on port 3128 as HTTP proxy to
the outer world. Your friendly administrator has granted you access
under your user name to `host.other.domain' on that proxy
server.2 You would need to add the
following rule:
(add-to-list 'tramp-default-proxies-alist
'("\\`host\\.other\\.domain\\'" nil
"/tunnel:proxy.your.domain#3128:"))
Gateway methods can be declared as first hop only in a multiple hop chain.
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 (see 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:
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"))
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-rhoststramp-parse-shoststramp-parse-sconfigHost entries
in ~/.ssh/config style files.
tramp-parse-shostkeysnil.
tramp-parse-sknownhostsnil.
tramp-parse-hoststramp-parse-passwdtramp-parse-netrcIf 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:
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 chosen method does not support access without password prompt through 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, independently of the connection method.
Passwords are not saved permanently, that means the password caching
is limited to the lifetime of your GNU 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.
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
GNU Emacs.
In order to reduce initial connection time, tramp stores
connection related information persistently. The variable
tramp-persistency-file-name keeps the file name where these
information are written. Its default value is
~/.emacs.d/tramp.
It is recommended to choose a local file name.
tramp reads this file during startup, and writes it when exiting GNU Emacs. You can simply remove this file if tramp shall be urged to recompute these information next GNU Emacs startup time.
Using such persistent information can be disabled by setting
tramp-persistency-file-name to nil.
Once consequence of reusing connection related information is that
tramp needs to distinguish hosts. If you, for example, run a
local sshd on port 3001, which tunnels ssh to another
host, you could access both /ssh:localhost: and
/ssh:localhost#3001:. tramp would use the
same host related information (like paths, Perl variants, etc) for
both connections, although the information is valid only for one of
them.
In order to avoid trouble, you must use another host name for one of the connections, like introducing a Host section in ~/.ssh/config (see Frequently Asked Questions) or applying multiple hops (see Multi-hops).
When tramp detects a changed operating system version on a remote host (via the command uname -sr), it flushes all connection related information for this host, quits the execution, and displays a message like this:
Quit: "Connection reset, because remote host changed from `Linux
2.6.22-13-generic' to `Linux 2.6.22-14-generic'"
You can simply open the remote file again in such a case.
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. The symbol tramp-default-remote-path is a place
holder, it is replaced by the list of directories received via the
command getconf PATH on your remote machine. For example,
on GNU Debian this is /bin:/usr/bin, whereas on Solaris this is
/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin. It is
recommended to apply this symbol on top of tramp-remote-path.
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")
tramp caches several information, like the Perl binary location. The changed remote search path wouldn't affect these settings. In order to force tramp to recompute these values, you must exit GNU Emacs, remove your persistency file (see Connection caching), and restart GNU Emacs.
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.
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.
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.
tramp-password-prompt-regexp handles the detection of such requests for English environments. When you use another localization of your (local or remote) host, you might need to adapt this. Example:
(setq
tramp-password-prompt-regexp
(concat
"^.*"
(regexp-opt
'("passphrase" "Passphrase"
;; English
"password" "Password"
;; Deutsch
"passwort" "Passwort"
;; Français
"mot de passe" "Mot de passe") t)
".*: ? *"))
In parallel, it might also be necessary to adapt
tramp-wrong-passwd-regexp.
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 variable tramp-actions-before-shell. Example:
(defconst my-tramp-prompt-regexp
(concat (regexp-opt '("Enter the birth date of your mother:") t)
"\\s-*")
"Regular expression matching my login prompt question.")
(defun my-tramp-action (proc vec)
"Enter \"19000101\" in order to give a correct answer."
(save-window-excursion
(with-current-buffer (tramp-get-connection-buffer vec)
(tramp-message vec 6 "\n%s" (buffer-string))
(tramp-send-string vec "19000101"))))
(add-to-list 'tramp-actions-before-shell
'(my-tramp-prompt-regexp my-tramp-action))
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!
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, GNU 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.
Therefore, it is useful to set special values for tramp
files. For example, the following statement effectively `turns off'
the effect of
backup-directory-alist
for tramp files:
(add-to-list 'backup-directory-alist
(cons tramp-file-name-regexp nil))
Another possibility is to use the tramp variable
tramp-backup-directory-alist.
This variable has the same meaning like
backup-directory-alist.
If a tramp file is backed up, and DIRECTORY is an absolute
local file name, DIRECTORY is prepended with the tramp file
name prefix of the file to be backed up.
Example:
(add-to-list 'backup-directory-alist
(cons "." "~/.emacs.d/backups/"))
(setq tramp-backup-directory-alist backup-directory-alist)
The backup file name of /su:root@localhost:/etc/secretfile would be /su:root@localhost:~/.emacs.d/backups/!su:root@localhost:!etc!secretfile~
The same problem can happen with auto-saving files.
Since GNU 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 GNU Emacs, namely the version built for
Debian GNU/Linux, the variable auto-save-file-name-transforms
contains the directory where GNU 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.
The recent Cygwin installation of ssh works only with a Cygwinized GNU Emacs. You can check it by typing M-x eshell, and starting ssh test.machine. The problem is evident if you see a message like this:
Pseudo-terminal will not be allocated because stdin is not a terminal.
Older ssh versions of Cygwin are told to cooperate with tramp selecting 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 GNU 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.
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.
However, if you start GNU Emacs from a desktop shortcut, then
the environment variable SSH_AUTH_SOCK is not set and so
GNU Emacs and thus tramp and thus ssh and
scp started from tramp cannot communicate with
ssh-agent. It works better to start GNU 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 GNU Emacs remembers all your keystrokes, so if you see a password prompt from GNU Emacs, say, and hit <RET> twice instead of once, then the second keystroke will be processed by GNU 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. See Default Method.
Some examples of tramp filenames are shown below.
melancholia.
daniel on the machine melancholia. The ~<user>
construct is expanded to the home directory of that user on the remote
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 (see Inline methods, see External transfer methods) 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.
Additionally to the syntax described in the previous chapter, it is
possible to use a URL-like syntax for tramp. This can be
switched on by customizing the variable tramp-syntax. Please
note that this feature is experimental for the time being.
The variable tramp-syntax must be set before requiring tramp:
(setq tramp-syntax 'url)
(require 'tramp)
Then, a tramp filename would look like this: /method://user@machine:port/path/to.file. /method:// is mandatory, all other parts are optional. :port is useful for methods only who support this.
The last example from the previous section would look like this: /ssh://daniel@melancholia/.emacs.
For the time being, tramp-syntax can have the following values:
ftp – That is the default syntax
url – URL-like syntax
Filename completion works with tramp for completion of method names, of user names and of machine names as well as for completion of file names on remote machines. In order to enable this, Partial Completion mode must be set on.
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.
If the configuration files (see Customizing Completion), which tramp uses for analysis of completion, offer user names, those user names will be taken into account as well.
Remote machines, which have been visited in the past and kept persistently (see Connection caching), will be offered too.
Once the remote machine identification is completed, it comes to filename completion on the remote host. This works pretty much like for files on the local host, with the exception that minibuffer killing via a double-slash works only on the filename part, except that filename part starts with //. A triple-slash stands for the default behaviour.
Example:
C-x C-f /telnet:melancholia:/usr/local/bin//etc <TAB>
-| /telnet:melancholia:/etc
C-x C-f /telnet:melancholia://etc <TAB>
-| /etc
C-x C-f /telnet:melancholia:/usr/local/bin///etc <TAB>
-| /etc
A remote directory might have changed its contents out of GNU Emacs control, for example by creation or deletion of files by other processes. Therefore, during filename completion the remote directory contents is reread regularly in order to detect such changes, which would be invisible otherwise (see Connection caching).
This variable defines the number of seconds since last remote command before rereading a directory contents. A value of 0 would require an immediate reread during filename completion,
nilmeans to use always cached values for the directory contents.
tramp supports running processes on a remote host. This allows to exploit GNU Emacs packages without modification for remote file names. It does not work for the ftp and smb methods.
Remote processes are started when a corresponding command is executed
from a buffer belonging to a remote file or directory. Up to now, the
packages compile.el (commands like compile and
grep) and gud.el (gdb or perldb) have been
integrated. Integration of further packages is planned, any help for
this is welcome!
When your program is not found in the default search path
tramp sets on the remote machine, you should either use an
absolute path, or extend tramp-remote-path (see Remote Programs):
(add-to-list 'tramp-remote-path "~/bin")
(add-to-list 'tramp-remote-path "/appli/pub/bin")
The environment for your program can be adapted by customizing
tramp-remote-process-environment. This variable is a list of
strings. It is structured like process-environment. Each
element is a string of the form ENVVARNAME=VALUE. An entry
ENVVARNAME= disables the corresponding environment variable, which
might have been set in your init file like ~/.profile.
Adding an entry can be performed via add-to-list:
(add-to-list 'tramp-remote-process-environment "JAVA_HOME=/opt/java")
Changing or removing an existing entry is not encouraged. The default
values are chosen for proper tramp work. Nevertheless, if for
example a paranoid system administrator disallows changing the
$HISTORY environment variable, you can customize
tramp-remote-process-environment, or you can apply the
following code in your .emacs:
(let ((process-environment tramp-remote-process-environment))
(setenv "HISTORY" nil)
(setq tramp-remote-process-environment process-environment))
If you use other GNU Emacs packages which do not run out-of-the-box on a remote host, please let us know. We will try to integrate them as well. See Bug Reports.
shell-command allows to execute commands in a shell, either
synchronously, either asynchronously. This works also on remote
hosts. Example:
C-x C-f /sudo:: <RET>
M-! tail -f /var/log/syslog.log & <RET>
You will see the buffer *Async Shell Command*, containing the continous output of the tail command.
tramp is integrated into eshell.el. That is, you can
open an interactive shell on your remote host, and run commands there.
After you have started eshell, you could perform commands like
this:
~ $ cd /sudo::/etc <RET>
/sudo:root@host:/etc $ hostname <RET>
host
/sudo:root@host:/etc $ id <RET>
uid=0(root) gid=0(root) groups=0(root)
/sudo:root@host:/etc $ find-file shadow <RET>
#<buffer shadow>
/sudo:root@host:/etc $
gud.el offers an unified interface to several symbolic
debuggers
With tramp, it is possible to debug programs on
remote hosts. You can call gdb with a remote file name:
M-x gdb <RET>
Run gdb (like this): gdb --annotate=3 /ssh:host:~/myprog <RET>
The file name can also be relative to a remote default directory. Given you are in a buffer that belongs to the remote directory /ssh:host:/home/user, you could call
M-x perldb <RET>
Run perldb (like this): perl -d myprog.pl <RET>
It is not possible to use just the absolute local part of a remote file name as program to debug, like perl -d /home/user/myprog.pl, though.
Arguments of the program to be debugged are taken literally. That means, file names as arguments must be given as ordinary relative or absolute file names, without any remote specification.
Sometimes it is useful to cleanup remote connections. The following commands support this.
This command flushes all connection related objects. vec is the internal representation of a remote connection. Called interactively, the command offers all active remote connections in the minibuffer as remote file name prefix like /method:user@host:. The cleanup includes password cache (see Password caching), file cache, connection cache (see Connection caching), connection buffers.
This command flushes objects for all active remote connections. The same objects are removed as in
tramp-cleanup-connection.
Like in
tramp-cleanup-all-connections, all remote connections are cleaned up. Additionally all buffers, which are related to a remote connection, are killed.
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. It is moderated so non-subscribers can post but messages will be delayed, possibly up to 48 hours (or longer in case of holidays), until the moderator approves your message.
The mailing list is at tramp-devel@gnu.org. Messages sent to this address go to all the subscribers. This is not the address to send subscription requests to.
Subscribing to the list is performed via the tramp Mail Subscription Page.
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. You should also check that your problem is not described already in See Frequently Asked Questions.
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.
Before reporting the bug, you should set the verbosity level to 6 (see Traces) in the ~/.emacs file and repeat the bug. Then, include the contents of the *tramp/foo* and *debug tramp/foo* buffers in your bug report. A verbosity level greater than 6 will produce a very huge debug buffer, which is mostly not necessary for the analysis.
Please be aware that, with a verbosity level of 6 or greater, the contents of files and directories will be included in the debug buffer. Passwords you've typed will never be included there.
tramp is available under the URL below.
There is also a Savannah project page.
The package has been used successfully on GNU Emacs 21, GNU Emacs 22 and XEmacs 21 (starting with 21.4). Gateway methods are supported for GNU Emacs 22 only.
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 MS Windows NT/2000/XP GNU 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/
In the backstage, tramp needs a lot of operations on the remote host. The time for transferring data from and to the remote host as well as the time needed to perform the operations there count. In order to speed up tramp, one could either try to avoid some of the operations, or one could try to improve their performance.
Use an external transfer method, like scpc.
Use caching. This is already enabled by default. Information about
the remote host as well as the remote files are cached for reuse. The
information about remote hosts is kept in the file specified in
tramp-persistency-file-name. Keep this file.
Disable version control. If you access remote files which are not under version control, a lot of check operations can be avoided by disabling VC. This can be achieved by
(setq vc-handled-backends nil)
Disable excessive traces. The default trace level of tramp,
defined in the variable tramp-verbose, is 3. You should
increase this level only temporarily, hunting bugs.
When tramp does not connect to the remote host, there are two reasons heading the bug mailing list:
tramp needs to recognize the prompt on the remote machine after execution any command. This is not possible, when the prompt contains unknown characters like escape sequences for coloring. This should be avoided on the remote side. See Remote shell setup. for setting the regular expression detecting the prompt.
You can check your settings after an unsuccessful connection by switching to the tramp connection buffer *tramp/foo*, setting the cursor at the top of the buffer, and applying the expression
M-: (re-search-forward (concat tramp-shell-prompt-pattern "$"))
If it fails, or the cursor is not moved at the end of the buffer, your prompt is not recognised correctly.
A special problem is the zsh, which uses left-hand side and right-hand side prompts in parallel. Therefore, it is necessary to disable the zsh line editor on the remote host. You shall add to ~/.zshrc the following command:
[ $TERM = "dumb" ] && unsetopt zle && PS1='$ '
On some few systems, the implementation of process-send-string
seems to be broken for longer strings. It is reported for HP-UX,
FreeBSD and Tru64 Unix, for example. 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.
Additionally, it will be useful to set file-precious-flag to
t for tramp files. Then the file contents will be
written into a temporary file first, which is checked for correct
checksum.
(add-hook
'find-file-hooks
'(lambda ()
(when (file-remote-p default-directory)
(set (make-local-variable 'file-precious-flag) t))))
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.
The following snippet can be put in your ~/.emacs file. It makes GNU 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-insert-beep-advice activate)
"Make tramp beep after inserting a file."
(interactive)
(beep))
When you are working with `root' privileges, it might be useful to get an indication in the buffer's modeline. The following code, tested with GNU Emacs 22.1, does the job. You should put it into your ~/.emacs:
(defun my-mode-line-function ()
(when (string-match "^/su\\(do\\)?:" default-directory)
(setq mode-line-format
(format-mode-line mode-line-format 'font-lock-warning-face))))
(add-hook 'find-file-hooks 'my-mode-line-function)
(add-hook 'dired-mode-hook 'my-mode-line-function)
The following code has been tested with GNU Emacs 22.1. You should put it into your ~/.emacs:
(defconst my-mode-line-buffer-identification
(list
'(:eval
(let ((host-name
(if (file-remote-p default-directory)
(tramp-file-name-host
(tramp-dissect-file-name default-directory))
(system-name))))
(if (string-match "^[^0-9][^.]*\\(\\..*\\)" host-name)
(substring host-name 0 (match-beginning 1))
host-name)))
": %12b"))
(setq-default
mode-line-buffer-identification
my-mode-line-buffer-identification)
(add-hook
'dired-mode-hook
'(lambda ()
(setq
mode-line-buffer-identification
my-mode-line-buffer-identification)))
Since GNU Emacs 23.1, the mode line contains an indication if
default-directory for the current buffer is on a remote host.
The corresponding tooltip includes the name of that host. If you
still want the host name as part of the mode line, you can use the
example above, but the :eval clause can be simplified:
'(:eval
(let ((host-name
(or (file-remote-p default-directory 'host)
(system-name))))
(if (string-match "^[^0-9][^.]*\\(\\..*\\)" host-name)
(substring host-name 0 (match-beginning 1))
host-name)))
GNU Emacs computes the dired options depending on the local host you are working. If your ls command on the remote host does not understand those options, you can change them like this:
(add-hook
'dired-before-readin-hook
'(lambda ()
(when (file-remote-p default-directory)
(setq dired-actual-switches "-al"))))
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
Let's say you need regularly access to /ssh:news@news.my.domain:/opt/news/etc, which is boring to type again and again. The following approaches can be mixed:
You can define default methods and user names for hosts, (see Default Method, see Default User):
(setq tramp-default-method "ssh"
tramp-default-user "news")
The file name left to type would be C-x C-f /news.my.domain:/opt/news/etc.
Note, that there are some useful settings already. Accessing your local host as `root' user, is possible just by C-x C-f /su::.
Several connection methods (i.e. the programs used) offer powerful configuration possibilities (see Customizing Completion). In the given case, this could be ~/.ssh/config:
Host xy
HostName news.my.domain
User news
The file name left to type would be C-x C-f /ssh:xy:/opt/news/etc. Depending on files in your directories, it is even possible to complete the host name with C-x C-f /ssh:x <TAB>.
File names typed in the minibuffer can be expanded by environment variables. You can set them outside GNU Emacs, or even with Lisp:
(setenv "xy" "/ssh:news@news.my.domain:/opt/news/etc/")
Then you need simply to type C-x C-f $xy <RET>, and here you are. The disadvantage is, that you cannot edit the file name, because environment variables are not expanded during editing in the minibuffer.
You can define your own key sequences in GNU Emacs, which can be used instead of C-x C-f:
(global-set-key
[(control x) (control y)]
(lambda ()
(interactive)
(find-file
(read-file-name
"Find Tramp file: "
"/ssh:news@news.my.domain:/opt/news/etc/"))))
Simply typing C-x C-y would initialize the minibuffer for editing with your beloved file name.
See also the Emacs Wiki for a more comprehensive example.
It is possible to define an own abbreviation list for expanding file names:
(add-to-list
'directory-abbrev-alist
'("^/xy" . "/ssh:news@news.my.domain:/opt/news/etc/"))
This shortens the file openening command to C-x C-f /xy <RET>. The disadvantage is, again, that you cannot edit the file name, because the expansion happens after entering the file name only.
The abbrev-mode gives more flexibility for editing the
minibuffer:
(define-abbrev-table 'my-tramp-abbrev-table
'(("xy" "/ssh:news@news.my.domain:/opt/news/etc/")))
(add-hook
'minibuffer-setup-hook
'(lambda ()
(abbrev-mode 1)
(setq local-abbrev-table my-tramp-abbrev-table)))
(defadvice minibuffer-complete
(before my-minibuffer-complete activate)
(expand-abbrev))
;; If you use partial-completion-mode
(defadvice PC-do-completion
(before my-PC-do-completion activate)
(expand-abbrev))
After entering C-x C-f xy <TAB>, the minibuffer is expanded, and you can continue editing.
Bookmarks can be used to visit Tramp files or directories.
When you have opened /ssh:news@news.my.domain:/opt/news/etc/, you should save the bookmark via <menu-bar> <edit> <bookmarks> <set>.
Later on, you can always navigate to that bookmark via <menu-bar> <edit> <bookmarks> <jump>.
recentf remembers visited places.
You could keep remote file names in the recent list without checking their readability through a remote access:
(recentf-mode 1)
The list of files opened recently is reachable via <menu-bar> <file> <Open Recent>.
filecache remembers visited places. Add the directory into the cache:
(eval-after-load "filecache"
'(file-cache-add-directory
"/ssh:news@news.my.domain:/opt/news/etc/"))
Whenever you want to load a file, you can enter C-x C-f C-<TAB> in the minibuffer. The completion is done for the given directory.
bbdb has a built-in feature for Ange-FTP files, which works also for tramp.
You need to load bbdb:
(require 'bbdb)
(bbdb-initialize)
Then you can create a BBDB entry via M-x bbdb-create-ftp-site. Because BBDB is not prepared for tramp syntax, you must specify a method together with the user name, when needed. Example:
M-x bbdb-create-ftp-site <RET>
Ftp Site: news.my.domain <RET>
Ftp Directory: /opt/news/etc/ <RET>
Ftp Username: ssh:news <RET>
Company: <RET>
Additional Comments: <RET>
When you have opened your BBDB buffer, you can access such an entry by pressing the key <F>.
I would like to thank all tramp users, who have contributed to the different recipes!
Shame on you, why did you read until now?
If you just want to have Ange-FTP as default remote files access package, you should apply the following code:
(setq tramp-default-method "ftp")
Unloading tramp can be achieved by applying M-x tramp-unload-tramp. This resets also the Ange-FTP plugins.
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.
GNU Emacs provides the user-login-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.
While reading filenames in the minibuffer, tramp must decide whether it completes possible incomplete filenames, or not. Imagine there is the following situation: You have typed C-x C-f /ssh: <TAB>. tramp cannot know, whether ssh is a method or a host name. It checks therefore the last input character you have typed. If this is <TAB>, <SPACE> or ?, tramp assumes that you are still in filename completion, and it does not connect to the possible remote host ssh.
External packages, which use other characters for completing filenames
in the minibuffer, must signal this to tramp. For this case,
the variable tramp-completion-mode can be bound temporarily to
a non-nil value.
(let ((tramp-completion-mode t))
...)
All tramp messages are raised with a verbosity level. The
verbosity level can be any number between 0 and 10. Only messages with
a verbosity level less than or equal to tramp-verbose are
displayed.
The verbosity levels are
0 silent (no tramp messages at all)
1 errors
2 warnings
3 connection to remote hosts (default verbosity)
4 activities
5 internal
6 sent and received strings
7 file caching
8 connection properties
10 traces (huge)
When tramp-verbose is greater than or equal to 4, the messages
are also written into a tramp debug buffer. This debug buffer
is useful for analysing problems; sending a tramp bug report
should be done with tramp-verbose set to a verbosity level of at
least 6 (see Bug Reports).
The debug buffer is in Outline Mode. That means, you can change the level of messages to be viewed. If you want, for example, see only messages up to verbosity level 5, you must enter C-u 6 C-c C-q.
tramp errors are handled internally in order to raise the verbosity level 1 messages. When you want to get a Lisp backtrace in case of an error, you need to set both
(setq debug-on-error t
debug-on-signal t)
Sometimes, it might be even necessary to step through tramp function call traces. Such traces are enabled by the following code:
(require 'tramp)
(require 'trace)
(dolist (elt (all-completions "tramp-" obarray 'functionp))
(trace-function-background (intern elt)))
(untrace-function 'tramp-read-passwd)
(untrace-function 'tramp-gw-basic-authentication)
The function call traces are inserted in the buffer
*trace-output*. tramp-read-passwd and
tramp-gw-basic-authentication shall be disabled when the
function call traces are added to tramp, because both
functions return password strings, which should not be distributed.
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.
The GNU 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.
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft,” which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document,” below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you.” You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque.”
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements,” “Dedications,” “Endorsements,” or “History.”) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History,” Preserve its Title, and add
to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section Entitled “History” in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the “History” section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications,”
Preserve the Title of the section, and preserve in the section all
the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section Entitled “Endorsements.” Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements”
or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements,” provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements,” and any sections Entitled “Dedications.” You must delete all sections Entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements,” “Dedications,” or “History,” the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled ``GNU
Free Documentation License.''
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:
with the Invariant Sections being list their titles, with the
Front-Cover Texts being list, and with the Back-Cover Texts being
list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
my-tramp-parse: Customizing Completiontramp-bug: Bug Reportstramp-cleanup-all-buffers: Cleanup remote connectionstramp-cleanup-all-connections: Cleanup remote connectionstramp-cleanup-connection: Cleanup remote connectionstramp-get-completion-function: Customizing Completiontramp-parse-hosts: Customizing Completiontramp-parse-netrc: Customizing Completiontramp-parse-passwd: Customizing Completiontramp-parse-rhosts: Customizing Completiontramp-parse-shostkeys: Customizing Completiontramp-parse-shosts: Customizing Completiontramp-set-completion-function: Customizing Completionbackup-directory-alist: Auto-save and Backuppassword-cache: Password cachingpassword-cache-expiry: Password cachingshell-prompt-pattern: Remote shell setuptramp-actions-before-shell: Remote shell setuptramp-completion-function-alist: Customizing Completiontramp-completion-mode: External packagestramp-completion-reread-directory-timeout: Filename completiontramp-default-host: Default Hosttramp-default-method: Default Methodtramp-default-method-alist: Default Methodtramp-default-proxies-alist: Multi-hopstramp-default-user-alist: Default Usertramp-password-prompt-regexp: Remote shell setuptramp-persistency-file-name: Connection cachingtramp-remote-path: Remote Programstramp-shell-prompt-pattern: Remote shell setuptramp-terminal-type: Remote shell setuptramp-wrong-passwd-regexp: Remote shell setup[1] Invoking /bin/sh will fail if your login shell doesn't recognize `exec /bin/sh' as a valid command. Maybe you use the Scheme shell scsh...
[2] HTTP tunnels are intended for secure SSL/TLS communication. Therefore, many proxy server restrict the tunnels to related target ports. You might need to run your ssh server on your target host `host.other.domain' on such a port, like 443 (https). See http://savannah.gnu.org/maintenance/CvsFromBehindFirewall for discussion of ethical issues.