Simple tramp stumbling blocks

I've recently blogged about my usage of Emacs for editing python code, in which I said that it sometimes involves remote editing via Tramp. At roughly the time I wrote the entry, I joined a different project in which the central development server only has a not-so-recent version of Emacs installed (besides the fact that it doesn't serve my favourite flavour of Emacs at all). This time, however, my naive usage of tramp failed: when accessing files via C-x C-f /[ssh/schauer@remote]/home/schauer/ all I would receive would be "Waiting 60s for prompt from remote shell" and tramp would be hanging. Searching the web had two interesting tips for debugging (regardless of what problem you have with tramp): go to the *scratch* buffer and evaluate (i.e. hit C-x C-e behind each of the closing parantheses of the following statements):

(setq tramp-debug-buffer t) 
(setq tramp-verbose 10)

The former setting will result in an additional buffer *debug tramp\*, while the latter will enhance the verbosity of information shown in the usual *tramp\* buffer that holds the actual remote shell interaction. Another hint then let me too a potential problem with my shell prompt setup, which is even mentioned in the FAQ. After clearing that issue by setting my fancy prompt only if the "TERM" environment variable isn't set to "dumb" or "emacs", I ran into another bit: I was getting an error about tramp not being able to issue the command "test -e". I'm still at a loss how that can happen, as 'test' is surely built in to the default shell I'm getting on that system and "/usr/bin/test" is also directly available when I log in. However, adding (add-to-list 'tramp-remote-path "/usr/bin") to my .emacs finally solved the problem.

To complete this post, I would also like to point at the manual on default method configuration, another interesting piece for my configuration.