emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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