Host name for su(do)? (was: Tramp 2.0 -> 2.1 migration woes)

[Michael Albinus <michael.albinus@gmx.de>]

"Trent W. Buck" <trentbuck@gmail.com> writes:

>> The appended patch shall fix it. Could you, please, test?
>
> Yes, that seems to work, but I would extend the whitelist:
>
> - The class A network 127.0.0.0/8
> - The unqualified system name (e.g. Clio instead of Clio.twb.ath.cx)
> - The comparison should be case-insensitive.
>
> Obviously this whitelist will never be perfect, e.g. if "mail" is a
> CNAME alias in on the DNS server for the local host, /sudo:mail: is
> meaningful but it would be hard to catch that.

The typical use case for "su" and "sudo" are file names like
"/sudo::/file". Therefore, I don't believe we shall invest too much in
the whitelist. "127.0.0.1" as host name doesn't seem to be needed; if
somebody uses it, s?he will be taught not to do.

`system-name' will mostly the unqualified system name I believe, so it
is already compliant to your request. Or am I wrong?

> Maybe instead of an error, it should show a warning and continue?  I'm
> not sure how you could make a warning pop up so that it would be seen
> by the user.  Obviously `message' wouldn't work, because the echo area
> would be reused as tramp continued to sudo'ing to localhost.

That was my first idea as well. But it isn't so simple to implement,
and there would be still the problem that a file name is shown as
"/sudo:otherhost:/file", although you are on the local host. It might
be inconvenient to get an error, but the user will learn very fast
that "/sudo::/file" or "/sudo:user@localhost:/file" is the better
choice.

> I would also change the error message to read
>
>     "Host `foo' looks like a remote host, `sudo' can only use the
>     local host."

OK, I'll do so.

Best regards, Michael.