Re: aliases? was: names
On 10 Mar 2001, Daniel Pittman wrote: > Directory aliases can be done trivially using environment variable > substitutions, I think. Does this do what you need: > > (setenv "src" "/local/dev/tlroche") > C-x C-f /.../$src/Score... I think it even works to say (setenv "remote" "/r@sm:[EMAIL PROTECTED]:/local/dev/tlroche/webassign/v4") Then you can do `C-x C-f $remote/foo RET'. I think. kai -- Be indiscrete. Do it continuously.
Re: aliases? was: names
On Fri, 09 Mar 2001, Tom Roche wrote: > Presuming TRAMP2 is still wish-list-able, could I suggest what might > be a feature? Of course it is. It's not likely to /stop/ being enhanced before it dies of old age. :) > I work with several servers, more than a few of which have ungodly > long user/host/paths: e.g. [...] > PuTTY, like many FTPs, has a nice feature whereby one can save the > details of a connection setup (notably server name) with a short > label. PuTTY calls these 'Saved Sessions': I prefer to think of them > as aliases. Thus having once made and saved a connection to the above > server as 'w2', I need only type [...] > So I was wondering: might it be possible to provide a similar > functionality in TRAMP? Extra points if one could alias a path as well > as user/hostname: if I could do something like > > + C-x C-f /r@t;v4/ScoreAnalysis.pm > > instead of (broken for mail) > > - C-x C-f /r@t:[EMAIL PROTECTED]:/local/dev/tlroche/ > - webassign/v4/ScoreAnalysis.pm > > I'd be thrilled. You may, of course, substitute for > ';'. You could have a putty protocol that used the `@' syntax, happily enough. Then the host part would be fine. Since you would need to add the protocol anyhow... In any case, I don't think it's a bad idea. Grab the tramp2 sources and look at the construction of the file-names as is. Then make a suggestion about exactly what to use there. :) Directory aliases can be done trivially using environment variable substitutions, I think. Does this do what you need: (setenv "src" "/local/dev/tlroche") C-x C-f /.../$src/Score... TRAMP v2 will support expanding local and remote environment variables (in that order) fairly soon... Daniel -- Most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton
aliases? was: names
Presuming TRAMP2 is still wish-list-able, could I suggest what might be a feature? I work with several servers, more than a few of which have ungodly long user/host/paths: e.g. > [EMAIL PROTECTED]:/local/dev/tlroche/webassign/v4 PuTTY, like many FTPs, has a nice feature whereby one can save the details of a connection setup (notably server name) with a short label. PuTTY calls these 'Saved Sessions': I prefer to think of them as aliases. Thus having once made and saved a connection to the above server as 'w2', I need only type > putty @w2 instead of > putty [EMAIL PROTECTED] So I was wondering: might it be possible to provide a similar functionality in TRAMP? Extra points if one could alias a path as well as user/hostname: if I could do something like + C-x C-f /r@t;v4/ScoreAnalysis.pm instead of (broken for mail) - C-x C-f /r@t:[EMAIL PROTECTED]:/local/dev/tlroche/ - webassign/v4/ScoreAnalysis.pm I'd be thrilled. You may, of course, substitute for ';'. FWIW, [EMAIL PROTECTED]
Re: names
On 09 Mar 2001, Kai Großjohann wrote: > On 09 Mar 2001, Daniel Pittman wrote: > >> Hrm. I will add it to the tramp2 todo list because of the >> compatibility needs with tramp1. I don't know how soon it will be >> working, though. > > IMVHO it's not necessary to try too hard to make the filename syntax > be compatible with the old one. After all, it's only something that > users type, and they'll see the advantage with the new unified method, > I hope. I agree with you. It's not that hard, though, to make the tramp compatibility layer, I think. So, I will look at it right after I get `insert-file-contents' working and committed. Which should be in an hour or two, I hope. At which point, aside from needing to implement more file operations, connection types, encoders and the like, tramp2 could be considered to actually work. Daniel -- Equality today means "sameness" rather than "oneness". -- Erich Fromm, _The Art of Loving_, (1956)
Re: names
On 09 Mar 2001, Daniel Pittman wrote: > Hrm. I will add it to the tramp2 todo list because of the > compatibility needs with tramp1. I don't know how soon it will be > working, though. IMVHO it's not necessary to try too hard to make the filename syntax be compatible with the old one. After all, it's only something that users type, and they'll see the advantage with the new unified method, I hope. kai -- Be indiscrete. Do it continuously.
Re: names
On Thu, 08 Mar 2001, Francesco Potorti` wrote: >>>/#sh:[user@]machine[:options]/[remote-dir] > >Well, there isn't any /technical/ reason that the syntax mentioned >above couldn't be supported. > >So, if Francesco really likes the mc(1) style, it's possible to: > >1. Write a file-name handler for it which uses TRAMP2 internally. > > I think that having different possible styles of file names is a good > thing. That way, we can experiment practically with them, and > hopefully find a sort of consensus about which one is better. Indeed. It shouldn't be very hard to write some generic support for mapping one style of file-name to another. One bit of code. Hrm. I will add it to the tramp2 todo list because of the compatibility needs with tramp1. I don't know how soon it will be working, though. [...] > For example we could experiment with the url-like syntax that was > proposed long ago. I don't know that this will work too well with a standard XEmacs, at least. They remove everything up to the second / when you enter '//' into the field. This is nice, from a UI point-of-view, but difficult with URLs. :) > The problem with all-encompassing syntaxes is that they are long and > complex, so the challenge is to find a global one which is easy to > use, for example using abbreviations, optional parts, and so on. I think that the tramp2 syntax covers every possible option for most people. If not, I would very much like to know what problems were seen with it. Daniel -- Fetters of gold are still fetters, and the softest lining can never make them so easy as liberty. -- Mary Astell, _An Essay in Defence of the Female Sex_ (1696)
Re: names
>>/#sh:[user@]machine[:options]/[remote-dir] Well, there isn't any /technical/ reason that the syntax mentioned above couldn't be supported. So, if Francesco really likes the mc(1) style, it's possible to: 1. Write a file-name handler for it which uses TRAMP2 internally. I think that having different possible styles of file names is a good thing. That way, we can experiment practically with them, and hopefully find a sort of consensus about which one is better. I mentioned mc because it has a similar problem as us, and it solved it. A syntax like that is very elastic, and it can naturally express ftp remote file names (with /#ftp:), so it could be the global syntax for file names, encompassing tramp, ange-ftp and w3. I'd like very much to see a unique syntax for remote file names.Having a way of experimenting with different ones would make us in the position of asking people outside this mailing list for suggestions and opinions, and try them quickly. For example we could experiment with the url-like syntax that was proposed long ago. The problem with all-encompassing syntaxes is that they are long and complex, so the challenge is to find a global one which is easy to use, for example using abbreviations, optional parts, and so on.
Re: names
On 07 Mar 2001, Kai Großjohann wrote: > On Mon, 05 Mar 2001, Francesco Potorti` wrote: > >> The midnight commander uses this sort of file names: >> >>/#sh:[user@]machine[:options]/[remote-dir] > > I wonder what the beginning means? Does "/#sh:" mean it's to be > fetched via ssh? And are there other "/#" filenames? > > But the (new) Tramp syntax is too different from the above, so maybe > making the second character the same doesn't make all that much of a > difference. The new syntax needs an unambiguous terminator for the > hop list, due to the unification of single-hop and multi-hop methods. Well, there isn't any /technical/ reason that the syntax mentioned above couldn't be supported. I have vague plans, if I had not mentioned, of writing a compatibility module for the new TRAMP code. It's not that hard to have a handler that accepts the old path syntax and massages it into the new syntax. So, if Francesco really likes the mc(1) style, it's possible to: 1. Write a file-name handler for it which uses TRAMP2 internally. This is simple, really. Just match their paths, create a new tramp2 path string are run the operation with the new path. 2. Redefine the path parser/constructor (`tramp2-path-parse', `tramp2-path-construct') These are nice and modular. The path object is well defined and the *only* places that use anything but the object are the file-name-handler table entry (modify `tramp2-path-tag') and the parser. I was fairly careful to keep the parser modular. If there are several syntaxes that people feel strongly about I can write a framework for supporting them through option 1. That, incidentally, is something that may well happen anyway, presuming that I do want to support the TRAMP1 style filenames. Daniel -- What the caterpillar calls the end of the world, the Master calls the butterfly -- Richard Bach
Re: names
On Mon, 05 Mar 2001, Francesco Potorti` wrote: > The midnight commander uses this sort of file names: > >/#sh:[user@]machine[:options]/[remote-dir] I wonder what the beginning means? Does "/#sh:" mean it's to be fetched via ssh? And are there other "/#" filenames? But the (new) Tramp syntax is too different from the above, so maybe making the second character the same doesn't make all that much of a difference. The new syntax needs an unambiguous terminator for the hop list, due to the unification of single-hop and multi-hop methods. kai -- Be indiscrete. Do it continuously.
names
The midnight commander uses this sort of file names: /#sh:[user@]machine[:options]/[remote-dir]
default login names
I've been thinking about default login names. Right now, deep down in the bowels of rcp.el, every file name with a missing login name is rewritten to put in the local user name instead. I was thinking of allowing nil as user name everywhere, with the semantics that the user name is then not passed to the commands at all. Ie, rather than saying `rsh HOST -l USER', I just say `rsh HOST'. But this breaks with `telnet'. Hm. Maybe there, the best thing to do is to pass the local user name. And what do we do in the multi-hop method? There, passing the local user name to telnet would be kinda strange. Hm. Do you think I should require a user name with telnet in the multi-hop method? kai -- The birch trees fly way too low these days.
rcp.el 1.104 -- bug with special chars in file names
It wouldn't properly quote the special characters when copying files. Hope this is fixed now. ftp://ls6-ftp.cs.uni-dortmund.de/pub/src/emacs/rcp.el kai -- Abort this operation? [Abort] [Cancel]
