dired mode recursive delete

dired mode recursive delete

[Neal Becker]

marking a directory D doesn't work in dired. (The xemacs version does)

Re: dired mode recursive delete

[Stephen Berman]

On Wed, 30 May 2007 13:36:03 -0400 Neal Becker <ndbecker2@gmail.com> wrote:

> marking a directory D doesn't work in dired. (The xemacs version does)

Do you have dired-recursive-deletes set to nil?

Steve Berman

Re: dired mode recursive delete

[David Kastrup]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Wed, 30 May 2007 13:36:03 -0400 Neal Becker <ndbecker2@gmail.com> wrote:
>
>> marking a directory D doesn't work in dired. (The xemacs version does)
>
> Do you have dired-recursive-deletes set to nil?

Actually, I would argue that nil is not a useful default for this
option: it keeps people unaware that there is a way to bypass the
default behavior of single-minded failure.

Setting it to t instead will not cause _any_ action without asking for
individual confirmation for every non-empty directory.  It seems like
quite a safe setting (whereas the original setting is not helpful in
any situation I can think of).

My personal setting is 'top which is certainly more convenient than t
but might be considered too drastic as a default setting by some.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: dired mode recursive delete

[Richard Stallman]

    Setting it to t instead will not cause _any_ action without asking for
    individual confirmation for every non-empty directory.  It seems like
    quite a safe setting (whereas the original setting is not helpful in
    any situation I can think of).

    My personal setting is 'top which is certainly more convenient than t
    but might be considered too drastic as a default setting by some.

I think that `top' would be an ok default.
Let's change the default in the trunk.

Re: dired mode recursive delete

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Setting it to t instead will not cause _any_ action without asking for
>     individual confirmation for every non-empty directory.  It seems like
>     quite a safe setting (whereas the original setting is not helpful in
>     any situation I can think of).
>
>     My personal setting is 'top which is certainly more convenient than t
>     but might be considered too drastic as a default setting by some.
>
> I think that `top' would be an ok default.
> Let's change the default in the trunk.

Done.  Also for dired-recursive-copies (it seems pointless to have
that setting more timid than that for deletion).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: dired mode recursive delete

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

> Done.  Also for dired-recursive-copies (it seems pointless to have
> that setting more timid than that for deletion).

The problem with this setting is that it emphasizes the fact that
Emacs doesn't support cross-device recursive copies.  But it's a
start.

Re: dired mode recursive delete

[Romain Francoise]

Romain Francoise <romain@orebokech.com> writes:

> The problem with this setting is that it emphasizes the fact that
> Emacs doesn't support cross-device recursive copies.
                                               ^^^^^^
I meant `renames' of course.  Copies will now work recursively by
default, renames will as well, unless the destination is on another
device.

Re: dired mode recursive delete

[Juri Linkov]

>> The problem with this setting is that it emphasizes the fact that
>> Emacs doesn't support cross-device recursive copies.
>                                                ^^^^^^
> I meant `renames' of course.  Copies will now work recursively by
> default, renames will as well, unless the destination is on another
> device.

Could we eliminate this restriction in dired since now coreutils supports
cross-partition recursive directory renames.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> The problem with this setting is that it emphasizes the fact that
>>> Emacs doesn't support cross-device recursive copies.
>>                                                ^^^^^^
>> I meant `renames' of course.  Copies will now work recursively by
>> default, renames will as well, unless the destination is on another
>> device.
>
> Could we eliminate this restriction in dired since now coreutils supports
> cross-partition recursive directory renames.

What has coreutils to do with it?

-- 
David Kastrup

Re: dired mode recursive delete

[Juri Linkov]

>>>> The problem with this setting is that it emphasizes the fact that
>>>> Emacs doesn't support cross-device recursive copies.
>>>                                                ^^^^^^
>>> I meant `renames' of course.  Copies will now work recursively by
>>> default, renames will as well, unless the destination is on another
>>> device.
>>
>> Could we eliminate this restriction in dired since now coreutils supports
>> cross-partition recursive directory renames.
>
> What has coreutils to do with it?

Coreutils contains the command `mv' which starting from the version 4.0
(when it was part of Fileutils, later combined into Coreutils with
Shellutils and Textutils) can move a entire directory hierarchy
between partitions.

Here is what the node (info "(coreutils)mv invocation") says about this:

       `mv' can move any type of file from one file system to another.
    Prior to version `4.0' of the fileutils, `mv' could move only regular
    files between file systems.  For example, now `mv' can move an entire
    directory hierarchy including special device files from one partition
    to another.  It first uses some of the same code that's used by `cp -a'
    to copy the requested directories and files, then (assuming the copy
    succeeded) it removes the originals.  If the copy fails, then the part
    that was copied to the destination partition is removed.  If you were
    to copy three directories from one partition to another and the copy of
    the first directory succeeded, but the second didn't, the first would
    be left on the destination partition and the second and third would be
    left on the original partition.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[Dieter Wilhelm]

Hi

Juri Linkov <juri@jurta.org> writes:
>>> Could we eliminate this restriction in dired since now coreutils supports
>>> cross-partition recursive directory renames.

It would be great if dired had also a way of updating directory trees
similar to 'cp -u' or 'midnight-commander'.

The only workaround I found so far is to 'dired-compare-directories'
for every subdirectory.

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: dired mode recursive delete

[Juri Linkov]

>>>> Could we eliminate this restriction in dired since now coreutils supports
>>>> cross-partition recursive directory renames.
>
> It would be great if dired had also a way of updating directory trees
> similar to 'cp -u' or 'midnight-commander'.

I wonder what would be the best way to implement this in dired: get code
from coreutils (that updates directories like `cp -u', moves directories
between partitions etc.), or make dired commands to run coreutils commands
like `cp' and `mv' directly with appropriate switches.  It seems strange
that dired uses external commands like `ls', and doesn't use `cp' and `mv'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[martin rudalics]

> I wonder what would be the best way to implement this in dired: get code
>>from coreutils (that updates directories like `cp -u', moves directories
> between partitions etc.), or make dired commands to run coreutils commands
> like `cp' and `mv' directly with appropriate switches.  It seems strange
> that dired uses external commands like `ls', and doesn't use `cp' and `mv'.

Because no one wrote the emulators cp-lisp.el and mv-lisp.el yet?

Re: dired mode recursive delete

[Juri Linkov]

>> I wonder what would be the best way to implement this in dired: get code
>>>from coreutils (that updates directories like `cp -u', moves directories
>> between partitions etc.), or make dired commands to run coreutils commands
>> like `cp' and `mv' directly with appropriate switches.  It seems strange
>> that dired uses external commands like `ls', and doesn't use `cp' and `mv'.
>
> Because no one wrote the emulators cp-lisp.el and mv-lisp.el yet?

Like that, yes, but the other way around :)

>From the beginning Emacs uses external commands, and later ls-lisp.el
and find-lisp.el were added for the systems without necessary external
commands.  In case of cp and mv, currently Emacs uses their "emulations",
but it would be good to use external commands directly.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 03 Jun 2007 21:43:57 +0300
> Cc: dieter@duenenhof-wilhelm.de, Stephen.Berman@gmx.net, emacs-devel@gnu.org
> 
> In case of cp and mv, currently Emacs uses their "emulations",
> but it would be good to use external commands directly.

Why would it be good?  It will certainly be slower.

Re: dired mode recursive delete

[Juri Linkov]

>> In case of cp and mv, currently Emacs uses their "emulations",
>> but it would be good to use external commands directly.
>
> Why would it be good?  It will certainly be slower.

Not necessarily slower: coreutils has fast implementation (maybe, even
faster that Emacs' own), and calling external process causes no big overhead.

But advantages of using external commands are numerous: they are rich of
features whose reimplementation in Emacs doesn't sound reasonable.

Please note that I don't propose replacing existing Emacs implementation
of basic copy and move operations by external commands.  I propose using
external commands only for functionality not available in Emacs, like
cross-partition move or `cp -u'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> In case of cp and mv, currently Emacs uses their "emulations",
>>> but it would be good to use external commands directly.
>>
>> Why would it be good?  It will certainly be slower.
>
> Not necessarily slower: coreutils has fast implementation (maybe, even
> faster that Emacs' own), and calling external process causes no big overhead.
>
> But advantages of using external commands are numerous: they are
> rich of features whose reimplementation in Emacs doesn't sound
> reasonable.

What use are numerous features in external commands when there is no
interface from Emacs to them?

I can call external programs as much as I like for solving some
Emacs-internal task, but the number of options that I am not going to
use is not relevant at all.

-- 
David Kastrup

Re: dired mode recursive delete

[Juri Linkov]

>> But advantages of using external commands are numerous: they are
>> rich of features whose reimplementation in Emacs doesn't sound
>> reasonable.
>
> What use are numerous features in external commands when there is no
> interface from Emacs to them?
>
> I can call external programs as much as I like for solving some
> Emacs-internal task, but the number of options that I am not going to
> use is not relevant at all.

Designing a good interface for using them is a good goal.  For example,
I imagine that just like some dired commands, when invoked with the prefix
key, ask for the command switches (`C-u =' asks for diff switches and `C-u s'
asks for ls switches), in the same way `C-u C' and `C-u R' could ask
for cp and mv switches and call these commands.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> But advantages of using external commands are numerous: they are
>>> rich of features whose reimplementation in Emacs doesn't sound
>>> reasonable.
>>
>> What use are numerous features in external commands when there is no
>> interface from Emacs to them?
>>
>> I can call external programs as much as I like for solving some
>> Emacs-internal task, but the number of options that I am not going to
>> use is not relevant at all.
>
> Designing a good interface for using them is a good goal.  For example,
> I imagine that just like some dired commands, when invoked with the prefix
> key, ask for the command switches (`C-u =' asks for diff switches and `C-u s'
> asks for ls switches), in the same way `C-u C' and `C-u R' could ask
> for cp and mv switches and call these commands.

But Emacs can't use external commands for moving and copying non-local
files, anyway, so there is no point in asking for command line options
which Emacs itself does not understand when Emacs will likely not be
able to use a command line.

-- 
David Kastrup

Re: dired mode recursive delete

[Juri Linkov]

>> Designing a good interface for using them is a good goal.  For example,
>> I imagine that just like some dired commands, when invoked with the prefix
>> key, ask for the command switches (`C-u =' asks for diff switches and `C-u s'
>> asks for ls switches), in the same way `C-u C' and `C-u R' could ask
>> for cp and mv switches and call these commands.
>
> But Emacs can't use external commands for moving and copying non-local
> files, anyway, so there is no point in asking for command line options
> which Emacs itself does not understand when Emacs will likely not be
> able to use a command line.

It could ask for options specific to the program used to transfer files
between hosts, like `rsync' which supports a lot of useful options.
Or not ask for options at all when they make no sense for non-local transfer.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>>>> The problem with this setting is that it emphasizes the fact that
>>>>> Emacs doesn't support cross-device recursive copies.
>>>>                                                ^^^^^^
>>>> I meant `renames' of course.  Copies will now work recursively by
>>>> default, renames will as well, unless the destination is on another
>>>> device.
>>>
>>> Could we eliminate this restriction in dired since now coreutils supports
>>> cross-partition recursive directory renames.
>>
>> What has coreutils to do with it?
>
> Coreutils contains the command `mv' which starting from the version
> 4.0 [...]

You did not answer my question.  I know coreutils and that it has a mv
command that will move across file systems.

But what has coreutils to do with how Emacs moves files?

-- 
David Kastrup

Re: dired mode recursive delete

[Juri Linkov]

> You did not answer my question.  I know coreutils and that it has a mv
> command that will move across file systems.

Sorry, I didn't answer your question explicitly.  I only did that in my
reply to Dieter.

> But what has coreutils to do with how Emacs moves files?

To implement cross-partition move in Emacs we could either use the same code as
implemented in coreutils, or rely on calling `mv' as the external command.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> You did not answer my question.  I know coreutils and that it has a mv
>> command that will move across file systems.
>
> Sorry, I didn't answer your question explicitly.  I only did that in my
> reply to Dieter.
>
>> But what has coreutils to do with how Emacs moves files?
>
> To implement cross-partition move in Emacs we could either use the
> same code as implemented in coreutils,

No, see below.

> or rely on calling `mv' as the external command.

No, since that does not work with external files accessed with
ange-ftp or tramp.

-- 
David Kastrup

Re: dired mode recursive delete

[Juri Linkov]

>> To implement cross-partition move in Emacs we could either use the
>> same code as implemented in coreutils,
>
> No, see below.
>
>> or rely on calling `mv' as the external command.
>
> No, since that does not work with external files accessed with
> ange-ftp or tramp.

We are talking about cross-partition operations, not cross-machine, right?
Ange-ftp and tramp use quite different facilities for copying and moving
files between machines.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[Dieter Wilhelm]

Juri Linkov <juri@jurta.org> writes:

>> No, since that does not work with external files accessed with
>> ange-ftp or tramp.
>
> We are talking about cross-partition operations, not cross-machine, right?
> Ange-ftp and tramp use quite different facilities for copying and moving
> files between machines.

Right, cp -u is only working locally but I also had ssh and ftp
connections in mind.  It would be fantastic when dired had such a
transparent handling of files and directories.

I also forgot to mention that the problem of updating subdirectories
can be somewhat mitigated when one includes the subdirectories with
the i switch into the respective dired buffers, but it's still a pain
in the ...

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: dired mode recursive delete

[Giorgos Keramidas]

On 2007-06-03 02:28, Juri Linkov <juri@jurta.org> wrote:
>>> The problem with this setting is that it emphasizes the fact that
>>> Emacs doesn't support cross-device recursive copies.
>>                                                ^^^^^^
>> I meant `renames' of course.  Copies will now work recursively by
>> default, renames will as well, unless the destination is on another
>> device.
> 
> Could we eliminate this restriction in dired since now coreutils supports
> cross-partition recursive directory renames.

Emacs runs on platforms where coreutils is not installed, though
(typical examples of this are BSD / Solaris workstations) :-/

Re: dired mode recursive delete

[Juri Linkov]

>> Could we eliminate this restriction in dired since now coreutils supports
>> cross-partition recursive directory renames.
>
> Emacs runs on platforms where coreutils is not installed, though
> (typical examples of this are BSD / Solaris workstations) :-/

Then this functionality won't available on these platforms, and move
will simply fail with the same error message as it currently fails.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[Richard Stallman]

    Done.  Also for dired-recursive-copies (it seems pointless to have
    that setting more timid than that for deletion).

Good idea.

Re: dired mode recursive delete

[Juri Linkov]

>> I think that `top' would be an ok default.
>> Let's change the default in the trunk.
>
> Done.  Also for dired-recursive-copies (it seems pointless to have
> that setting more timid than that for deletion).

As for dired-recursive-copies, one could argue even in favor of using 'always
as the default value since this operation is not as dangerous as deletion.

If this is not desirable, I think even `top' is much better than nil.
Please don't forget that the documentation of these options still mention
old defaults.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired mode recursive delete

[Kevin Rodgers]

Richard Stallman wrote:
>     Setting it to t instead will not cause _any_ action without asking for
>     individual confirmation for every non-empty directory.  It seems like
>     quite a safe setting (whereas the original setting is not helpful in
>     any situation I can think of).
> 
>     My personal setting is 'top which is certainly more convenient than t
>     but might be considered too drastic as a default setting by some.
> 
> I think that `top' would be an ok default.
> Let's change the default in the trunk.

I'm uneasy about `top' vs. t as the default: when I'm prompted 
"Recursive delete of SUBDIR? ", I expect that if I answer "yes"
that I'll be prompted for SUBDIR's subdirectories as well.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: dired mode recursive delete

[David Kastrup]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> Richard Stallman wrote:
>>     Setting it to t instead will not cause _any_ action without asking for
>>     individual confirmation for every non-empty directory.  It seems like
>>     quite a safe setting (whereas the original setting is not helpful in
>>     any situation I can think of).
>>
>>     My personal setting is 'top which is certainly more convenient than t
>>     but might be considered too drastic as a default setting by some.
>>
>> I think that `top' would be an ok default.
>> Let's change the default in the trunk.
>
> I'm uneasy about `top' vs. t as the default: when I'm prompted
> "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
> that I'll be prompted for SUBDIR's subdirectories as well.

That is not taking issue with the default but rather with the prompt.
What kind of prompt would make you expect the right thing?

-- 
David Kastrup

Re: dired mode recursive delete

[Kevin Rodgers]

David Kastrup wrote:
> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> 
>> Richard Stallman wrote:
>>>     Setting it to t instead will not cause _any_ action without asking for
>>>     individual confirmation for every non-empty directory.  It seems like
>>>     quite a safe setting (whereas the original setting is not helpful in
>>>     any situation I can think of).
>>>
>>>     My personal setting is 'top which is certainly more convenient than t
>>>     but might be considered too drastic as a default setting by some.
>>>
>>> I think that `top' would be an ok default.
>>> Let's change the default in the trunk.
>> I'm uneasy about `top' vs. t as the default: when I'm prompted
>> "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
>> that I'll be prompted for SUBDIR's subdirectories as well.
> 
> That is not taking issue with the default but rather with the prompt.
> What kind of prompt would make you expect the right thing?

Recursive delete of SUBDIR (unconditionally)?
Recursive delete of SUBDIR (without confirmation)?

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: dired mode recursive delete

[David Kastrup]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> David Kastrup wrote:
>> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
>>
>>> Richard Stallman wrote:
>>>>     Setting it to t instead will not cause _any_ action without asking for
>>>>     individual confirmation for every non-empty directory.  It seems like
>>>>     quite a safe setting (whereas the original setting is not helpful in
>>>>     any situation I can think of).
>>>>
>>>>     My personal setting is 'top which is certainly more convenient than t
>>>>     but might be considered too drastic as a default setting by some.
>>>>
>>>> I think that `top' would be an ok default.
>>>> Let's change the default in the trunk.
>>> I'm uneasy about `top' vs. t as the default: when I'm prompted
>>> "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
>>> that I'll be prompted for SUBDIR's subdirectories as well.
>>
>> That is not taking issue with the default but rather with the prompt.
>> What kind of prompt would make you expect the right thing?
>
> Recursive delete of SUBDIR (unconditionally)?
> Recursive delete of SUBDIR (without confirmation)?

How about like

Completely delete SUBDIR?

I think it would be clear enough that this would ask no further
(=recursive) questions and include subdirectories.  It has the
advantage of being less verbose, leaving more space for the directory
name.

-- 
David Kastrup

Re: dired mode recursive delete

[Stephen Leake]

David Kastrup <dak@gnu.org> writes:

> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
>
>> David Kastrup wrote:
>>> Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
>>>
>>>> Richard Stallman wrote:
>>>>>     Setting it to t instead will not cause _any_ action without asking for
>>>>>     individual confirmation for every non-empty directory.  It seems like
>>>>>     quite a safe setting (whereas the original setting is not helpful in
>>>>>     any situation I can think of).
>>>>>
>>>>>     My personal setting is 'top which is certainly more convenient than t
>>>>>     but might be considered too drastic as a default setting by some.
>>>>>
>>>>> I think that `top' would be an ok default.
>>>>> Let's change the default in the trunk.
>>>> I'm uneasy about `top' vs. t as the default: when I'm prompted
>>>> "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
>>>> that I'll be prompted for SUBDIR's subdirectories as well.
>>>
>>> That is not taking issue with the default but rather with the prompt.
>>> What kind of prompt would make you expect the right thing?
>>
>> Recursive delete of SUBDIR (unconditionally)?
>> Recursive delete of SUBDIR (without confirmation)?
>
> How about like
>
> Completely delete SUBDIR?
>
> I think it would be clear enough that this would ask no further
> (=recursive) questions and include subdirectories.  It has the
> advantage of being less verbose, leaving more space for the directory
> name.

One approach to this that other systems use is to provide response
buttons that are "yes" and "yes to all".

In Emacs, that would typically be "y" and "!".

Then the question could just be 

Delete SUBDIR (y, n, !)?

-- 
-- Stephe

Re: dired mode recursive delete

[David Kastrup]

Stephen Leake <stephen_leake@member.fsf.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> How about like
>>
>> Completely delete SUBDIR?
>>
>> I think it would be clear enough that this would ask no further
>> (=recursive) questions and include subdirectories.  It has the
>> advantage of being less verbose, leaving more space for the directory
>> name.
>
> One approach to this that other systems use is to provide response
> buttons that are "yes" and "yes to all".
>
> In Emacs, that would typically be "y" and "!".
>
> Then the question could just be 
>
> Delete SUBDIR (y, n, !)?

Not really.  "yes to all" does not mean "yes to all recursive
directories", but rather "yes to all future questions in this
command".

In particular, it will delete marked _siblings_ of the SUBDIR without
further questions.

-- 
David Kastrup

Re: dired mode recursive delete

[Richard Stallman]

    I'm uneasy about `top' vs. t as the default: when I'm prompted 
    "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
    that I'll be prompted for SUBDIR's subdirectories as well.

It asks about recursively deleting the directory's contents.
So I think it is clear that you're saying yes to all the levels.

Re: dired mode recursive delete

[Kevin Rodgers]

Richard Stallman wrote:
>     I'm uneasy about `top' vs. t as the default: when I'm prompted 
>     "Recursive delete of SUBDIR? ", I expect that if I answer "yes"
>     that I'll be prompted for SUBDIR's subdirectories as well.
> 
> It asks about recursively deleting the directory's contents.

I interpret "recursive" as an explanation of why I'm being prompted: the
directory has a subdirectory, and deleting the directory in toto is
therefore a recursive operation.

> So I think it is clear that you're saying yes to all the levels.

But my experience with the Unix rm command leads me to expect that
when I respond affirmatively that I am only saying yes to this level:

-bash-2.05b$ mkdir -p /tmp/foo/bar
-bash-2.05b$ touch /tmp/foo/bar/baz
-bash-2.05b$ \rm -ri /tmp/foo
examine files in directory /tmp/foo? y
examine files in directory /tmp/foo/bar? y
remove /tmp/foo/bar/baz? y
remove /tmp/foo/bar? y
remove /tmp/foo? y
-bash-2.05b$

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: dired mode recursive delete

[Richard Stallman]

I put something in the doc string explaining the parameter that
controls this.