More on TRAMP

2010-10-29T12:10:00+01:00

I've mentioned TRAMP before. It's a very handy way of editing remote files. However I've been having a few problems with it today.

The most common access method used by TRAMP to access files these days is via ssh. It basically uses a remote terminal session to navigate the remote file system and fetch files back and forth. However it does take a few things for granted and one of those is the shell environment on the far end. For most *nix users this will be Bash. Long time command line hackers like myself usually have a rather heavily customised shell environment which can cause problems for TRAMP, especially if you pull tricks with customising the command prompt. In an effort to handle this a little better I modified my .bashrc to treat 'dumb' terminals as non-interactive. It works but it still seems a little hacky. I would welcome any better suggestions for detecting TRAMP sessions my start-up files.

I was still experiencing a problem navigating to one of the directories on my remote machine. Whatever I did when I got to the root of my code tree I couldn't navigate into the correct directory. The prompt would only offer me an old (since moved away) directory. Tricks like opening dired mode and navigating in would cause the session to spin consuming 100% cpu. In the end I tracked it down to IDO and the old directory existing in my ~/.ido.last file. Once removed and emacs restarted the problem went away. I'm hoping this is just a peculiarity of the interaction between ido and TRAMP but is was certainly annoying.

The power of Tramp

2010-07-29T08:06:00+01:00

The project I've been working on at work the last few weeks has involved bringing up a brand new embedded system. As part of that I've been tweaking a lot of start-up scripts and configuration files on the new system.

For part of that task I've installed GNU Zile which provides a nice Emacs-like experience for quick edits where you would usually fire-up vi. Despite the fact the new platform has a considerably larger backing store I'm not going to install the full-fat Emacs just to satisfy my editing needs.

Fortunately the full-fat Emacs has long carried a feature called TRAMP (standing for "Transparent Remote (file) Access, Multiple Protocol") which is incredibly useful in this and other use cases. TRAMP allows you to edit files on remote machines in your normal home Emacs environment. find-file and friends all behave as if you are editing local files while behind the scenes Emacs pulls directory listings and files from the remote machine with ssh (or ftp or whatever actually works). I use TRAMP all the time to edit files on the rather ancient build machine rather the using the relatively ancient Emacs it has installed on it.

There was one minor wrinkle getting TRAMP working with my new embedded system. As some of the methods used to move files back and forth are designed for transferring text files Emacs goes to great pains to ensure the files are moved across un-mangled. Typically this involves some sort of encode/decode utility. The tramp code is actually quite a good example of using elisp in an extensible way and if you look at tramp-remote-coding-commands you'll see it will even fall back to running remote in-line perl if it has to. As it happens we don't have perl running on the embedded platform and as it would be a little overkill to put perl on the remote machine so I added the recode utility.

I consider TRAMP to be one of Emacs' killer features. Next time you sigh at the prospect of being consigned to an inferior editor on some remote box consider visiting the file with TRAMP straight from your current Emacs session.

Alex's Adventures on the Infobahn - tramp

More on TRAMP

The power of Tramp