[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recommend move eshell/su and eshell/sudo to em-tramp.el
From: |
Michael Albinus |
Subject: |
Re: Recommend move eshell/su and eshell/sudo to em-tramp.el |
Date: |
Wed, 04 Jul 2012 16:53:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
"John Wiegley" <address@hidden> writes:
> This type of behavior, being that it is special, really deserves to be in its
> own "opt-in" module. It's better to educate people how to turn on behavior
> that may have surprising consequences, rather than to make it the default and
> then educate them how to disable it.
Understood. Maybe we should change it such a way, that plain sudo is
called when your default directory is local. This is what people expect.
> Also, eshell/sudo does not fit with the philosophy of the other
> functions in em-unix.el. Every other function in that file provides a
> *pure Lisp* implementation of an equivalent Unix command. As far as I
> can see, both *sudo and eshell/sudo end up calling /usr/bin/sudo.
> sehell/sudo is not pure Lisp (i.e., it involves an external command).
> So I'm not sure what benefit eshell/sudo gains, since ultimately it
> does the same thing, only slower and with blocking I/O?
The idea behind eshell/sudo (and eshell/su) is
- Allow su(do) to run lisp commands. "sudo ls" would call the Lisp
implementation of ls, not the UNIX ls .
- Allow su(do) on remote hosts. On the fly, tramp-default-proxies-alist
is expanded, in order to apply sudo on that remote host, and not on
the local host.
Two new features, which weren't in eshell before (IIRC).
> Other than that, you know I'm a huge Tramp fan, and I use Tramp+eshell quite
> often. I'm very interested in seeing this work progress, albeit in its own
> module.
I agree with you that we shall not surprise people, especially when
calling sudo for local machine purposes. OTOH, I'd love to have a kind
of automagic to let it work on remote machines. Opt-in modules need time
and courage to discover.
> Thanks,
> John
Best regards, Michael.