GNU bug report logs - #11194
24.0.95; sudo rm doesn't work with absolute directory paths on the file system

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11194 in the body.
You can then email your comments to 11194 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cray Elliott <mp2e <at> archlinux.us>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Sat, 07 Apr 2012 03:45:38 -0700

For example, if you went to eshell and typed 'sudo rm -rf /opt/folder'
it would complain about permissions being needed and wouldn't query
for password. Bug doesn't exist with relative paths. Bug does exist with wildcards.


In GNU Emacs 24.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
 of 2012-04-07 on rbdash
Windowing system distributor `The X.Org Foundation', version 11.0.11104000
Configured using:
 `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var'
 '--libexecdir=/usr/lib' '--mandir=/usr/share/man' '--without-sound'
 '--with-xft' '--with-x-toolkit=gtk' 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4
 -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: 
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  evil-mode: t
  evil-local-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  shell-dirtrack-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-b C-x 1 M-x r e p o <tab> r t - e m <tab> b <backspace> 
<return>

Recent messages:
("emacs")
Loading "/home/cray/.emacs.d/byte-cache/home!cray!.emacs.d!el-get!color-theme!themes!color-theme-example.elc" as "/home/cray/.emacs.d/el-get/color-theme/themes/color-theme-example.el"...done
Loading "/home/cray/.emacs.d/byte-cache/home!cray!.emacs.d!el-get!color-theme!themes!color-theme-library.elc" as "/home/cray/.emacs.d/el-get/color-theme/themes/color-theme-library.el"...done
ad-handle-definition: `evil-mode' got redefined [38 times]
Starting Emacs daemon.
When done with this frame, type C-x 5 0
Making completion list...

Load-path shadows:
/home/cray/.emacs.d/el-get/dired-plus/dired+ hides /home/cray/.emacs.d/el-get/dired+/dired+
/home/cray/.emacs.d/el-get/emacschrome/servers/el-get hides /home/cray/.emacs.d/el-get/el-get/el-get
/home/cray/.emacs.d/el-get/cmake-mode/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/cray/.emacs.d/el-get/remember/remember hides /usr/share/emacs/24.0.95/lisp/textmodes/remember
/home/cray/.emacs.d/el-get/magit/.dir-locals hides /usr/share/emacs/24.0.95/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils server ampc-autoloads
re-builder .loaddefs arduino-mode cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vkill sudo-save
smarttabs remember-autoloads qmake-mode pkgbuild-mode sh-script
executable pastebin muse-journal muse-book cus-edit cus-start cus-load
muse-project muse-latex muse-html muse-xml-common muse-protocols
muse-regexps derived muse muse-nested-tags muse-publish muse-autoloads
list-processes+ linum-off linum linum-ex icomplete+ icomplete go-mode
flyguess flyspell ispell evil-core undo-tree rect evil-vars dired-view
dired-sync dired-single dired-details dired-x ediff-merg ediff-diff
ediff-wind ediff-mult ediff-help ediff-init ediff-util dired-aux cssh
tramp tramp-compat auth-source eieio assoc gnus-util time-date mm-util
mail-prsvr password-cache shell pcomplete format-spec tramp-loaddefs
term disp-table ehelp electric ibuffer command-frequency
color-theme-twilight color-theme wid-edit cmake-mode thingatpt
byte-code-cache buffer-move windmove browse-kill-ring
auto-complete-config auto-complete edmacro kmacro preview-latex tex-site
auto-loads info anything byte-opt warnings advice advice-preload
any-ini-mode imenu ahg grep compile comint ansi-color ewoc log-edit ring
pcvs-util add-log diff-mode easy-mmode popup el-get help-mode easymenu
view autoload help-fns bytecomp byte-compile cconv macroexp cl package
tabulated-list dired regexp-opt tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Message #8 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Cray Elliott <mp2e <at> archlinux.us>
Cc: 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Sun, 08 Apr 2012 13:00:29 +0200

Cray Elliott <mp2e <at> archlinux.us> writes:

> For example, if you went to eshell and typed 'sudo rm -rf /opt/folder'
> it would complain about permissions being needed and wouldn't query
> for password. Bug doesn't exist with relative paths. Bug does exist with wildcards.

If you want to use absolute paths in eshell, you should apply

rm -rf /sudo::/opt/folder

Best regards, Michael.

Message #13 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Sun, 08 Apr 2012 22:20:50 -0400

>> For example, if you went to eshell and typed 'sudo rm -rf
>> /opt/folder' it would complain about permissions being needed and
>> wouldn't query for password. Bug doesn't exist with relative paths.
>> Bug does exist with wildcards.
> If you want to use absolute paths in eshell, you should apply
> rm -rf /sudo::/opt/folder

While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
is a perfectly valid command and wonder why it wouldn't work correctly.


        Stefan

Message #16 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Mon, 09 Apr 2012 20:08:15 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> For example, if you went to eshell and typed 'sudo rm -rf
>>> /opt/folder' it would complain about permissions being needed and
>>> wouldn't query for password. Bug doesn't exist with relative paths.
>>> Bug does exist with wildcards.
>> If you want to use absolute paths in eshell, you should apply
>> rm -rf /sudo::/opt/folder
>
> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
> is a perfectly valid command and wonder why it wouldn't work correctly.

In eshell, `sudo' is an built-in for `eshell/sudo':

~ $ which sudo
eshell/sudo is a compiled Lisp function in `em-unix.el'

In order to call the native sudo, one must apply

*sudo rm -rf /opt/folder

See also (info "(eshell)Built-ins")

>         Stefan

Best regards, Michael.

Message #19 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Mon, 09 Apr 2012 21:58:05 -0400

>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>> is a perfectly valid command and wonder why it wouldn't work correctly.
> In eshell, `sudo' is an built-in for `eshell/sudo':

That does not in itself explain why it doesn't do the right thing: the
intention seems fairly clear.


        Stefan

Message #22 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 09:07:21 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>>> is a perfectly valid command and wonder why it wouldn't work correctly.
>> In eshell, `sudo' is an built-in for `eshell/sudo':
>
> That does not in itself explain why it doesn't do the right thing: the
> intention seems fairly clear.

Sure.

The problem is `rm', which is another built-in. Built-ins are not aware
of being called in a `su(do)?' context.

Sounds like a new feature in eshell. Do we want it? Do we know, that
there are no unwanted side effects, if (local) "/foo/bar" is handled as
(remote) "/su(do)?::/foo/bar" for *all* built-ins, when being called
from `eshell/su(do)?'?

>         Stefan

Best regards, Michael.

Message #25 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 09:01:11 -0400

>>>> While using Tramp might make sense, I think that "sudo rm -rf /foo/bar"
>>>> is a perfectly valid command and wonder why it wouldn't work correctly.
>>> In eshell, `sudo' is an built-in for `eshell/sudo':
>> That does not in itself explain why it doesn't do the right thing: the
>> intention seems fairly clear.
> Sure.
> The problem is `rm', which is another built-in.  Built-ins are not aware
> of being called in a `su(do)?' context.

Sounds like a bug in eshell/sudo: it should not use builtins.


        Stefan

Message #28 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 16:00:17 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Sounds like a bug in eshell/sudo: it should not use builtins.

Don't know. Sometimes, it makes sense for builtins running under sudo.
Like `.', an alias for `eshell/.'. It sources a file, and executes
eshell commands from this file.

sudo . .eshell/history

sounds like a useful command. Just as example, other examples could  be there.

I still believe, we shall emphasize in the manual, that file names are
interpreted like in `find-file'. This is the spirit of `eshell'.
Otherwise, one shall use plain `shell'.

>         Stefan

Best regards, Michael.

Message #31 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 10:55:44 -0400

>> Sounds like a bug in eshell/sudo: it should not use builtins.
> Don't know. Sometimes, it makes sense for builtins running under sudo.
> Like `.', an alias for `eshell/.'. It sources a file, and executes
> eshell commands from this file.
> sudo . .eshell/history

"sudo . .eshell/history" means "execute the commands in .eshell/history
as user `root'".  I.e. it's very different from
". /sudo::.eshell/history" which runs those command as the current user.
I don't think eshell/sudo knows how to do it right.


        Stefan

Message #34 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 17:14:28 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> "sudo . .eshell/history" means "execute the commands in .eshell/history
> as user `root'".  I.e. it's very different from
> ". /sudo::.eshell/history" which runs those command as the current user.

I haven't said there's only one way to do it :-) I mean we should think
about, before we disable builtins in sudo. I'm still not convinced it is
a bug. In eshell, one must understand how file names are handled.

And, btw, people who don't like the current behaviour are free to add

alias sudo *sudo $*

to ~/.eshell/alias.

>         Stefan

Best regards, Michael.

Message #37 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 12:23:08 -0400

>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>> as user `root'".  I.e. it's very different from
>> ". /sudo::.eshell/history" which runs those command as the current user.
> I haven't said there's only one way to do it :-) I mean we should
> think about, before we disable builtins in sudo.  I'm still not
> convinced it is a bug.
> In eshell, one must understand how file names are handled.

I'd be happy to hear of arguments in favor of the current behavior of
eshell/sudo w.r.t builtins.


        Stefan

Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 18:35:57 +0200

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

> And, btw, people who don't like the current behaviour are free to add
>
> alias sudo *sudo $*
Most people use such an alias because eshell/sudo is not working with
commands where files are not involved 
e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...

==> ssh: connect to host localhost port 22: Connection refused

Using default-directory instead of
/sudo:user <at> localhost:<default-directory> (which use ssh port 22!!!!)
fix it

--8<---------------cut here---------------start------------->8---
(let ((default-directory (if (string= host "localhost")
                             default-directory
                             (format "/sudo:%s@%s:%s" user host dir))))
--8<---------------cut here---------------end--------------->8---

But maybe I missed something?

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #43 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 18:41:21 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>>> as user `root'".  I.e. it's very different from
>>> ". /sudo::.eshell/history" which runs those command as the current user.
>> I haven't said there's only one way to do it :-) I mean we should
>> think about, before we disable builtins in sudo.  I'm still not
>> convinced it is a bug.
>> In eshell, one must understand how file names are handled.
>
> I'd be happy to hear of arguments in favor of the current behavior of
> eshell/sudo w.r.t builtins.
It seem it doesn't ask for passwd at everytime 
(seem it read his timestamp in /var/lib/sudo/<user>/?).

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 18:57:31 +0200

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Hi Michael,
>
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> And, btw, people who don't like the current behaviour are free to add
>>
>> alias sudo *sudo $*
> Most people use such an alias because eshell/sudo is not working with
> commands where files are not involved 
> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>
> ==> ssh: connect to host localhost port 22: Connection refused
>
> Using default-directory instead of
> /sudo:user <at> localhost:<default-directory> (which use ssh port 22!!!!)
> fix it
>
> (let ((default-directory (if (string= host "localhost")
>                              default-directory
>                              (format "/sudo:%s@%s:%s" user host dir))))
>
> But maybe I missed something?
And also it is using /bin/sh which is not aware of many system
maintenance commands mostly used as root with sudo.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 19:07:30 +0200

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>
>>>> "sudo . .eshell/history" means "execute the commands in .eshell/history
>>>> as user `root'".  I.e. it's very different from
>>>> ". /sudo::.eshell/history" which runs those command as the current user.
>>> I haven't said there's only one way to do it :-) I mean we should
>>> think about, before we disable builtins in sudo.  I'm still not
>>> convinced it is a bug.
>>> In eshell, one must understand how file names are handled.
>>
>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> It seem it doesn't ask for passwd at everytime 
> (seem it read his timestamp in /var/lib/sudo/<user>/?).
No, it just doesn't use sudo at all! it is why no password is required.
And command which need a passwd e.g cat /etc/passwd- end up with
permission denied.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #52 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Tue, 10 Apr 2012 14:00:41 -0400

>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> It seem it doesn't ask for passwd at everytime
> (seem it read his timestamp in /var/lib/sudo/<user>/?).

That rather sounds like a problem of the alternative code that
needs fixing.


        Stefan

Message #55 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Fri, 20 Apr 2012 15:35:50 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

[Sorry for the delay, I was busy in RL last days]

> I'd be happy to hear of arguments in favor of the current behavior of
> eshell/sudo w.r.t builtins.

I've checked the implementation of eshell/sudo: It simply let-binds
default-directory to "/sudo:user <at> host:dir", and let the command like rm
run. That's why the built-in version of rm is in place.

Another implementation of sudo would not be in the spirit of eshell, I
think.

>         Stefan

Best regards, Michael.

Message #58 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Fri, 20 Apr 2012 15:38:34 +0200

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

>> Hi Michael,

Hi Thierry,

>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>>
>>> And, btw, people who don't like the current behaviour are free to add
>>>
>>> alias sudo *sudo $*
>> Most people use such an alias because eshell/sudo is not working with
>> commands where files are not involved 
>> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>>
>> ==> ssh: connect to host localhost port 22: Connection refused
>>
>> Using default-directory instead of
>> /sudo:user <at> localhost:<default-directory> (which use ssh port 22!!!!)
>> fix it
>>
>> (let ((default-directory (if (string= host "localhost")
>>                              default-directory
>>                              (format "/sudo:%s@%s:%s" user host dir))))
>>
>> But maybe I missed something?
> And also it is using /bin/sh which is not aware of many system
> maintenance commands mostly used as root with sudo.

Does there exist a corresponding bug report? I'm short in time, but
maybe I could have a look on it later.

Best regards, Michael.

Message #61 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Fri, 20 Apr 2012 22:58:52 +0200

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:
>
>>> Hi Michael,
>
> Hi Thierry,
>
>>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>>>
>>>> And, btw, people who don't like the current behaviour are free to add
>>>>
>>>> alias sudo *sudo $*
>>> Most people use such an alias because eshell/sudo is not working with
>>> commands where files are not involved 
>>> e.g "eshell/sudo uname -a" or "eshell/sudo fdisk -l" etc...
>>>
>>> ==> ssh: connect to host localhost port 22: Connection refused
This happen with a bad configuration of `tramp-default-proxies-alist':

--8<---------------cut here---------------start------------->8---
(add-to-list 'tramp-default-proxies-alist
             '(nil "\\`root\\'" "/ssh:%h:"))
--8<---------------cut here---------------end--------------->8---

With this with host set to nil,
(directory-file-p "/sudo:localhost:")
C-x C-f "/sudo:localhost:"
eshell/sudo
fail with error above.
The host should be set to the real name of the host we want to connect
on as root:

--8<---------------cut here---------------start------------->8---
(add-to-list 'tramp-default-proxies-alist
             '("\\`realhostname\\'" "\\`root\\'" "/ssh:%h:"))
--8<---------------cut here---------------end--------------->8---

>> And also it is using /bin/sh which is not aware of many system
>> maintenance commands mostly used as root with sudo.
>
> Does there exist a corresponding bug report? I'm short in time, but
> maybe I could have a look on it later.
No but you can reproduce easily with:

$ eshell/sudo fdisk -l
=>/bin/sh: fdisk: not found

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Message #64 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Fri, 20 Apr 2012 22:03:03 -0400

>> I'd be happy to hear of arguments in favor of the current behavior of
>> eshell/sudo w.r.t builtins.
> I've checked the implementation of eshell/sudo: It simply let-binds
> default-directory to "/sudo:user <at> host:dir", and let the command like rm
> run. That's why the built-in version of rm is in place.
> Another implementation of sudo would not be in the spirit of eshell, I
> think.

Spirit or not, the resulting behavior for `sudo' makes no sense and
should be fixed,


        Stefan

Message #67 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Sun, 22 Apr 2012 19:47:47 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> I'd be happy to hear of arguments in favor of the current behavior of
>>> eshell/sudo w.r.t builtins.
>> I've checked the implementation of eshell/sudo: It simply let-binds
>> default-directory to "/sudo:user <at> host:dir", and let the command like rm
>> run. That's why the built-in version of rm is in place.
>> Another implementation of sudo would not be in the spirit of eshell, I
>> think.
>
> Spirit or not, the resulting behavior for `sudo' makes no sense and
> should be fixed,

Last attempt to convince you: The eshell manual gives as example

          ~ $ cd /ssh:otherhost:/etc
          /ssh:user <at> otherhost:/etc $ sudo find-file shadow

If you disable built-in commands inside sudo, you would disable all
other Lisp functions as well. Do we want this?

>         Stefan

Best regards, Michael.

Message #70 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Mon, 23 Apr 2012 21:52:36 -0400

>> Spirit or not, the resulting behavior for `sudo' makes no sense and
>> should be fixed,
> Last attempt to convince you: The eshell manual gives as example
>           ~ $ cd /ssh:otherhost:/etc
>           /ssh:user <at> otherhost:/etc $ sudo find-file shadow
> If you disable built-in commands inside sudo, you would disable all
> other Lisp functions as well.  Do we want this?

The problem is the following:
- eshell/sudo has the same name as /usr/bin/sudo but does something
  slightly different.
- eshell/rm has the same name as /bin/rm but does something
  slightly different.
- the combination of the two leads to "sudo rm" doing something less
  slightly different.
I don't use Eshell myself, so I'm not sure what the best way to
fix this.  Maybe it's eshell/rm that needs fixing, maybe Eshell should
change to use different name for its `sudo', or maybe the solution
should be yet different.


        Stefan

Message #73 received at 11194 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Cray Elliott <mp2e <at> archlinux.us>, 11194 <at> debbugs.gnu.org
Subject: Re: bug#11194: 24.0.95;
	sudo rm doesn't work with absolute directory paths on the file system
Date: Wed, 25 Apr 2012 11:32:17 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> The problem is the following:
> - eshell/sudo has the same name as /usr/bin/sudo but does something
>   slightly different.
> - eshell/rm has the same name as /bin/rm but does something
>   slightly different.

That's the idea of eshell's built-ins.

> - the combination of the two leads to "sudo rm" doing something less
>   slightly different.

Again, it does what you could expect from *eshell*. If you do not want
this behaviour, you could use *shell*. Or you could mask the built-in by
prepending a "*" to the command, as described.

> I don't use Eshell myself, so I'm not sure what the best way to
> fix this.  Maybe it's eshell/rm that needs fixing, maybe Eshell should
> change to use different name for its `sudo', or maybe the solution
> should be yet different.

The question is whether a command being an argument of "sudo" shall
still behave like other eshell commands. This is not only true for "rm"
(being `eshell/rm'), but for all commands which could be a valid Lisp
command.

>         Stefan

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.