[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tramp 2.0 -> 2.1 migration woes

From: Trent W. Buck
Subject: Re: Tramp 2.0 -> 2.1 migration woes
Date: Tue, 29 Jan 2008 02:57:12 +1100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, Jan 28, 2008 at 04:32:40PM +0100, Michael Albinus wrote:
>> Would it be correct to say that the explicit multi: method was
>> removed because other TRAMP changes broke it, and that it will be
>> brought back once it's fixed?  Or is it gone for good?  I would
>> (obviously) prefer the former.
> Nope. The internal data structures have changed significantly, there
> is no easy way to get this syntax back.

Darn.  Whenever I get used to something it goes and changes on me :-)

> > Well, personally I prefer a single complex prompt like [...]  to a
> > long series of simple prompts [...]  mainly because I find it
> > easier to copy/paste or M-p (previous-history-element) a single
> > prompt than to do it repeatedly for several prompts.
> Hmm. Then we have conflicting requirements. Reiner's intention was to
> guide the novice user ... maybe we need indeed two kinds of interactive
> guidance. In your case, something like this could be done:
>   Where do you want to go? /sudo:leek: RET
>   Which proxy is in front of it? /ssh:address@hidden: RET
>   Which proxy is in front of it? /ssh:address@hidden: RET
>   Which proxy is in front of it? RET
>   Do you want to add it permanently [Y/n]? n RET
>   => Added to `tramp-default-proxies-alist' temporarily:
>      (("leek" "root" "/ssh:address@hidden:")
>       ("leek" "twb"  "/ssh:address@hidden:"))

I think I could learn to tolerate that amount of prompting... one
thing to consider is what happens if I mess up the multihop (proxy)
sequence because e.g. the notes the other sysadmin gave me are out of
date.  Would I have to manually remove the entries from

I'm also not sure that middling to complicated proxying arrangements
can even be set up with the current tramp-default-proxies-alist.  For
example, suppose a host allows ssh from anywhere, but locks down its
internal staff-only FTP upload area to sites on the corporate subnet?
You'd need to have the /ftp:appdev:/incoming use an /ssh:gw: proxy,
but /ssh:appdev: should not use any proxy (although it would still
work with one, it would just waste gw's bandwidth).

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]