bugfix eshell/rm

bugfix eshell/rm

[Thierry Volpiatto]

Hi all,
`eshell-remove-entries' use a not bound 'verbose' variable, and fail.
To reproduce bug, try "rm -rf /some/directory" in eshell.
 

This patch fix it.
however there is maybe other calls to `eshell-remove-entries' to fix.

This is on emacs-23.3

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/eshell/em-unix.el b/lisp/eshell/em-unix.el
index 8f61270..0a79e80 100644
--- a/lisp/eshell/em-unix.el
+++ b/lisp/eshell/em-unix.el
@@ -194,7 +194,7 @@ Otherwise, Emacs will attempt to use rsh to invoke du on the remote machine."
       (Info-menu (car args))
       (setq args (cdr args)))))
 
-(defun eshell-remove-entries (path files &optional top-level)
+(defun eshell-remove-entries (path files &optional top-level verbose)
   "From PATH, remove all of the given FILES, perhaps interactively."
   (while files
     (if (string-match "\\`\\.\\.?\\'"
@@ -298,7 +298,7 @@ Remove (unlink) the FILE(s).")
 			 (y-or-n-p
 			  (format "rm: descend into directory `%s'? "
 				  entry)))
-		     (eshell-remove-entries nil (list entry) t))
+		     (eshell-remove-entries nil (list entry) t nil))
 	       (eshell-error (format "rm: %s: is a directory\n" entry)))
 	   (eshell-remove-entries nil (list entry) t)))))
      (setq args (cdr args)))
--8<---------------cut here---------------end--------------->8---

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

Re: bugfix eshell/rm

[Glenn Morris]

Thierry Volpiatto wrote:

> `eshell-remove-entries' use a not bound 'verbose' variable, and fail.

It's dynamically bound in eshell/rm via eshell-eval-using-options.

> To reproduce bug, try "rm -rf /some/directory" in eshell.

Works fine for me.

(Please report bugs to the bug list.)

Re: bugfix eshell/rm

[Thierry Volpiatto]

Glenn Morris <rgm@gnu.org> writes:

> Thierry Volpiatto wrote:
>
>> `eshell-remove-entries' use a not bound 'verbose' variable, and fail.
>
> It's dynamically bound in eshell/rm via eshell-eval-using-options.

Ok i see.

>> To reproduce bug, try "rm -rf /some/directory" in eshell.
>
> Works fine for me.
Thanks to verify, works fine for me too, i have removed a old eshell.elc
that load all eshell files.
Sorry.

BTW, what's the best way to load eshell?
I would like to use some eshell functions at startup but require have no
effect.
I tried also some autoloads without success.
Actually i must start once eshell or eshell-command.


> (Please report bugs to the bug list.)
Sorry, but i have (too) many No--Reply to bugs i sent there, so now i send to
emacs-dev.

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

Re: bugfix eshell/rm

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Fri, 11 Mar 2011 10:08:48 +0100
> 
> BTW, what's the best way to load eshell?

"M-x eshell RET", of course ;-)

> I would like to use some eshell functions at startup

Which ones?

Basically, since eshell uses Lisp primitives, you should have
everything at your fingertips already.  Perhaps we need some wrappers
outside of eshell, but it's hard to know unless you tell what you
need.

Re: bugfix eshell/rm

[Thierry Volpiatto]

Thanks Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Fri, 11 Mar 2011 10:08:48 +0100
>> 
>> BTW, what's the best way to load eshell?
>
> "M-x eshell RET", of course ;-)
>
>> I would like to use some eshell functions at startup
>
> Which ones?
fn:
eshell-command
eshell-send-input
eshell-read-aliases-list

var:
eshell-command-aliases-list

> Basically, since eshell uses Lisp primitives, you should have
> everything at your fingertips already.  Perhaps we need some wrappers
> outside of eshell, but it's hard to know unless you tell what you
> need.

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

Re: bugfix eshell/rm

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 11 Mar 2011 13:17:05 +0100
> 
> >> I would like to use some eshell functions at startup
> >
> > Which ones?
> fn:
> eshell-command
> eshell-send-input
> eshell-read-aliases-list
> 
> var:
> eshell-command-aliases-list

And you need these because...?

Re: bugfix eshell/rm

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 11 Mar 2011 13:17:05 +0100
>> 
>> >> I would like to use some eshell functions at startup
>> >
>> > Which ones?
>> fn:
>> eshell-command
>> eshell-send-input
>> eshell-read-aliases-list
>> 
>> var:
>> eshell-command-aliases-list
>
> And you need these because...?
anything-find-files have an action that allow to run eshell commands on
files with completion on all aliases ending with $1.
This allow to create and use personal commands for files.
When i start emacs and anything, this aliases list is available only
after M-x eshell or eshell-command.
In this case i must run a y-or-n-p to ask if user want to first load
eshell manually and restart C-x C-f, or to run a command without
completion (i.e need to write it).


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

Re: bugfix eshell/rm

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 11 Mar 2011 13:50:16 +0100
> 
> >> eshell-command
> >> eshell-send-input
> >> eshell-read-aliases-list
> >> 
> >> var:
> >> eshell-command-aliases-list
> >
> > And you need these because...?
> anything-find-files have an action that allow to run eshell commands on
> files with completion on all aliases ending with $1.
> This allow to create and use personal commands for files.
> When i start emacs and anything, this aliases list is available only
> after M-x eshell or eshell-command.
> In this case i must run a y-or-n-p to ask if user want to first load
> eshell manually and restart C-x C-f, or to run a command without
> completion (i.e need to write it).

Looks like

  (require 'esh-mode)
  (require 'em-alias)

should do the trick for you.

Re: bugfix eshell/rm

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 11 Mar 2011 13:50:16 +0100
>> 
>> >> eshell-command
>> >> eshell-send-input
>> >> eshell-read-aliases-list
>> >> 
>> >> var:
>> >> eshell-command-aliases-list
>> >
>> > And you need these because...?
>> anything-find-files have an action that allow to run eshell commands on
>> files with completion on all aliases ending with $1.
>> This allow to create and use personal commands for files.
>> When i start emacs and anything, this aliases list is available only
>> after M-x eshell or eshell-command.
>> In this case i must run a y-or-n-p to ask if user want to first load
>> eshell manually and restart C-x C-f, or to run a command without
>> completion (i.e need to write it).
>
> Looks like
>
>   (require 'esh-mode)
>   (require 'em-alias)
>
> should do the trick for you.
Thanks, of course it's the first thing i tried...
but that doesn't work, even worst, all eshell functionalities are not
loaded (even if you run once M-x eshell) when you do some requires on
any eshell files at startup.

For example if you put in .emacs:

(require 'esh-mode)
(require 'em-alias)

then start emacs.

M-x eshell

alias RET

give nothing.(assume you have aliases in your .eshell/alias)

even if you require eshell directly and take care of setting
`eshell-directory-name'.

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

Re: bugfix eshell/rm

[Thierry Volpiatto]

Glenn Morris <rgm@gnu.org> writes:

> Thierry Volpiatto wrote:
>
>> `eshell-remove-entries' use a not bound 'verbose' variable, and fail.
>
> It's dynamically bound in eshell/rm via eshell-eval-using-options.
>
>> To reproduce bug, try "rm -rf /some/directory" in eshell.
>
> Works fine for me.
Sorry to insist, but something is wrong here.
On emacs-23.3, if you turn on `delete-by-moving-to-trash',
rm -rf hang forever.
This is because in `eshell-remove-entries', `delete-directory' and
`delete-file' take respectively 3 and 2 arguments.
This is correct for emacs24 but not for emacs23.

Use a consequent directory to test, i.e not a too small directory.

So of course in emacs24 this is working fine.

Maybe some changes in em-unix.el for emacs24 have been merged in
emacs-23 branch without appropriate modifications?


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

Re: bugfix eshell/rm

[Thierry Volpiatto]

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

> Glenn Morris <rgm@gnu.org> writes:
>
>> Thierry Volpiatto wrote:
>>
>>> `eshell-remove-entries' use a not bound 'verbose' variable, and fail.
>>
>> It's dynamically bound in eshell/rm via eshell-eval-using-options.
>>
>>> To reproduce bug, try "rm -rf /some/directory" in eshell.
>>
>> Works fine for me.
> Sorry to insist, but something is wrong here.
> On emacs-23.3, if you turn on `delete-by-moving-to-trash',
> rm -rf hang forever.
> This is because in `eshell-remove-entries', `delete-directory' and
> `delete-file' take respectively 3 and 2 arguments.
> This is correct for emacs24 but not for emacs23.
>
> Use a consequent directory to test, i.e not a too small directory.
>
> So of course in emacs24 this is working fine.
>
> Maybe some changes in em-unix.el for emacs24 have been merged in
> emacs-23 branch without appropriate modifications?

So now back in emacs23, if i remove the 3 and 2 arguments to
delete-directory and delete-file, reeval eshell-remove-entries and
eshell/rm, all work fine.

--8<---------------cut here---------------start------------->8---
(eshell-funcalln 'delete-directory (car files) t t)
                                                 ^ removed
(eshell-funcalln 'delete-file (car files) t)
                                          ^ removed
--8<---------------cut here---------------end--------------->8---

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

Re: bugfix eshell/rm

[Glenn Morris]

Thierry Volpiatto wrote:

>> (Please report bugs to the bug list.)
> Sorry, but i have (too) many No--Reply to bugs i sent there, so now i send to
> emacs-dev.

I can only say that I think you're making the wrong decision here, and
encourage you to please reconsider. The obvious thing is to think about
what would happen if everyone followed your example. We have separate
mailing lists for a reason.

bug and dev mailing lists [was: bugfix eshell/rm]

[Drew Adams]

> From: Glenn Morris
>
> We have separate mailing lists for a reason.

Amen.  So why have some taken to cross-posting from the bugs list to the dev
list lately?

E.g. bug 8219.  In this case it was Eli who cross-posted to emacs-devel, but I
think he's not the only one who has done this.

I'm all for moving a discussion to emacs-devel if that is appropriate.  Or
creating a separate development discussion thread there.  But cross-posting from
the bug list to the dev list should be a no-no, IMO.

Nothing prevents one from updating a bug thread with some conclusion or
occasional input from a related dev thread - or vice versa.  But simply cc'ing
the other thread as a mirror is a bad idea.

Re: bug and dev mailing lists [was: bugfix eshell/rm]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 12 Mar 2011 12:12:47 -0800
> 
> > From: Glenn Morris
> >
> > We have separate mailing lists for a reason.
> 
> Amen.  So why have some taken to cross-posting from the bugs list to the dev
> list lately?
> 
> E.g. bug 8219.  In this case it was Eli who cross-posted to emacs-devel

Please check your facts: it was Chong who posted the message that
started that thread, and it was posted to both lists.

RE: bug and dev mailing lists [was: bugfix eshell/rm]

[Drew Adams]

> > E.g. bug 8219.  In this case it was Eli who cross-posted to 
> > emacs-devel
> 
> Please check your facts: it was Chong who posted the message that
> started that thread, and it was posted to both lists.

As a matter of fact, FWIW, I did check - precisely so that I wouldn't
misattribute the cross-posting.  I checked on the bug web site.

Apparently I did not check well enough, however.  Mille excuses.  Yes, Yidong
first cross-posted it, not you Eli.  That was the first message of the thread
after the merge of 8219 and 1242 (first message of 8219).

I scanned the mail headers from the top of the web page (where there were only
messages for bug 1242 and no cross-posting).  I apparently missed the first 8219
post and mistook your reply to that one as the first cross-posting to
emacs-devel.  It was an honest mistake on my part.

Apologies to you, Eli, in any case.

But who did the cross-posting was not really the point (not my point, anyway).
The reference was meant only as a (recent) _example_ of such cross-posting.
Anyone, including me, could have cross-posted to emacs-devel.

The point is that IMHO we should try to avoid such cross-posting.  As Glenn
said, there is a reason there are two lists.