Re: Obsolence of rlogin.el

[Michael Albinus]

Kalman Reti <address@hidden> writes:

Hi Kalman,

>     Sounds to me like you need shadowfile.el. With this package, you
>     could define clusters, which implement a similar feature as you
>     apply, keeping several files in sync on different hosts, once one
>     of the files is changed.
>
> This sounds more like a 'keep files in sync wherever the changes are
> made' solution rather than a 'I want changes made only in the
> canonical location and distributed (non-automatically) to the
> subordinate locations at times of my choosing' solution. However, I'll
> look into it to see if it might be useful.

My idea is to use the "primary host" declaration of a cluster in
shadowfile.el. It shall be possible to declare the local host as the
primary host (no Tramp involved at all) of a clster. And if a file from
any host of the cluster is asked for visiting, the corresponding file
from the primary host, the local file, shall be taken. This would mimic
what you do with your rlogin setup, w/o the hack to redirect directory
tracking as you do. This would even free you from the precondition, that
a given file must be exactly on the same directory location on the
remote and local hosts.

shadowfile.el does not sync all cluster files automatically, once you
have edited one of them. You could configure it this way, but you could
configure it also differently, that it does it only when you call
shadow-copy-files. This said, you could even keep your approach to
distribute the changed local file to the involved remote hosts outside
Emacs.

> I think I wasn't being clear; I don't WANT to use tramp.

If you don't want to use Tramp at all, I cannot help you. It would be
the precondition to use directory tracking in `shell'.

> Rlogin.el gives me exactly the two capabilities I want, executing
> remote commands and relative directory tracking without adding others
> that I don't want, e.g. a remote shell's interpreting pathnames as if
> they existed on the remote host.

Even after rlogin.el has been declared as obsolete, you could still use
it. It will be moved into the directory lisp/obsolete, and Emacs
maintainers won't feel obliged anymore to maintain it, fixing
bugs. That's all.

Best regards, Michael.