GNU bug report logs -
#9950
rm -r partial failure
Previous Next
Reported by: Graham Lawrence <gl00637 <at> gmail.com>
Date: Fri, 4 Nov 2011 16:20:01 UTC
Severity: normal
Tags: notabug
Done: Bob Proulx <bob <at> proulx.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9950 in the body.
You can then email your comments to 9950 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#9950
; Package
coreutils
.
(Fri, 04 Nov 2011 16:20:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Graham Lawrence <gl00637 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 04 Nov 2011 16:20:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
By my understanding of rm -r the files listed by find below should
have been removed by the first rm. But it took only some of them.
Vim was not running during this process.
~ $pwd
/home/g
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *.swp
~ $find /home -name *swp
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *swp
~ $find /home -name *swp
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -f /home/g/.vim/Notes.swp
~ $rm /home/g/.vim/backup.sh.swp
~ $rm /home/g/.vim/.vimrc.swp
~ $rm /home/g/Scripts/.reseq.awk.swp
~ $rm /home/g/.fluxbox/.menu.swp
~ $find /home -name *swp
~ $
Added tag(s) notabug.
Request was from
Bob Proulx <bob <at> proulx.com>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Nov 2011 16:36:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Bob Proulx <bob <at> proulx.com>
:
You have taken responsibility.
(Fri, 04 Nov 2011 16:36:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Graham Lawrence <gl00637 <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 04 Nov 2011 16:36:02 GMT)
Full text and
rfc822 format available.
Message #12 received at 9950-done <at> debbugs.gnu.org (full text, mbox):
tags 9950 + notabug
thanks
Graham Lawrence wrote:
> By my understanding of rm -r the files listed by find below should
> have been removed by the first rm. But it took only some of them.
> Vim was not running during this process.
Thank you for your bug report. However this is simply a
misunderstanding of the shell file glob expansion of your shell and
not a bug in rm.
> ~ $pwd
> /home/g
You are in your home directory.
> ~ $find /home -name *swp
> /home/g/.vim/config.swp
> /home/g/.vim/Notes.swp
> /home/g/.vim/nzb.sh.swp
> /home/g/.vim/makesess.vim.swp
> /home/g/.vim/backup.sh.swp
> /home/g/.vim/.vimrc.swp
> /home/g/.vim/.bashrc.swp
> /home/g/.vim/renamer.sh.swp
> /home/g/.vim/vimcht.swp
> /home/g/.vim/grepnotes.sh.swp
> /home/g/Scripts/.reseq.awk.swp
> /home/g/.fluxbox/.menu.swp
There are twelve .swp files in subdirectories. There are none in the
current directory.
> ~ $rm -rf *.swp
That will not match any files. No files will be deleted.
You can verify that no files are matched by using the 'echo' command.
I will assume 'bash' for the following examples.
$ echo ls -ldog *.swp
ls -ldog *.swp
See? No files are matched by the "*.swp" file glob. The shell could
not find any and so the option argument was left unchanged. If it had
matched files then the actual files would have been replaced on that
option argument. For example:
$ touch file1.test
$ echo ls -ldog *.test
ls -ldog file1.test
See how the file glob is replaced *by the shell* with the matching
files. At this point your problem should be clear. The file glob is
not matching any files and therefore rm isn't removing any. rm isn't
complaining because the rm -f option tells it not to complain about
files that do not exist. The string "*.swp" is a file that does not
exist.
> ~ $rm -f /home/g/.vim/Notes.swp
> ~ $rm /home/g/.vim/backup.sh.swp
> ~ $rm /home/g/.vim/.vimrc.swp
> ~ $rm /home/g/Scripts/.reseq.awk.swp
> ~ $rm /home/g/.fluxbox/.menu.swp
> ~ $find /home -name *swp
> ~ $
Right. Here you have told rm to remove the files individually. So of
course that works.
If you want to find files and then remove them you should use find.
And you are *already* using find. So this should be natural.
$ find /home -name '*.swp' -ls
...verify your file list...
$ find /home -name '*.swp' -delete
Using -delete is a new option. The traditional method would be to use
the rm command with find.
$ find /home -name '*.swp' -exec rm -f {} +
Using find provides a powerful file finding mechanism that works with
all of the rest of the utilities. It is a general solution.
Please also see this reference for more information:
http://www.gnu.org/software/coreutils/faq/#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
And also this one too:
http://www.gnu.org/software/coreutils/faq/#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
Bob
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9950
; Package
coreutils
.
(Fri, 04 Nov 2011 19:38:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 9950 <at> debbugs.gnu.org (full text, mbox):
I appreciate the detailed response from Bob Proulx, but I do not think
it addressed the question I raised. I had expected "rm -rf *.swp" to
remove all the files listed by find, Mr Proulx informed me that it
would have removed none of them, but in fact what it did was remove
SOME of them.
~ $find /home -name *swp ................the original list delivered by find
/home/g/.vim/config.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *.swp ...............................the doubtful rm command
~ $find /home -name *swp ..............the same find command, showing
some deleted, and some not
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *swp
For example, why did it remove
/home/g/.vim/renamer.sh.swp
but ignore
/home/g/.vim/backup.sh.swp
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9950
; Package
coreutils
.
(Fri, 04 Nov 2011 20:30:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 9950 <at> debbugs.gnu.org (full text, mbox):
Graham Lawrence wrote:
> I appreciate the detailed response from Bob Proulx, but I do not think
> it addressed the question I raised.
Please keep the discussion going until we have reached consensus.
> I had expected "rm -rf *.swp" to remove all the files listed by
> find, Mr Proulx informed me that it would have removed none of them,
Not given the information discussed so far. :-)
> but in fact what it did was remove SOME of them.
What? That is very unexpected behavior! Please show us the result of
these commands:
echo *.swp
ls -ldog *.swp
What shell are you using?
echo $0
echo $SHELL
If that happens to turn out to be /bin/sh then please follow up by
figuring out if /bin/sh is a symlink to a different shell. And if it
isn't a symlink try to find out what shell it is really.
ls -ldog /bin/sh
Expansion of the '*.swp' is a function of your shell. So finding that
information is critical to understanding the behavior. I am using
bash. If you are using a different shell then the behavior could be
quite different. But it would still be a function of the shell.
What filesystem are you operating upon? Is it a local filesystem or
a network mounted filesystem such as NFS or Samba? 'find' can print
this information.
find . -name '*.swp' -printf '%F %p\n'
> For example, why did it remove
> /home/g/.vim/renamer.sh.swp
> but ignore
> /home/g/.vim/backup.sh.swp
I am unable to reproduce your results. I used the following setup
actions to recreate your test case:
mkdir g
mkdir g/.vim
touch g/.vim/config.swp
touch g/.vim/Notes.swp
touch g/.vim/nzb.sh.swp
touch g/.vim/makesess.vim.swp
touch g/.vim/backup.sh.swp
touch g/.vim/.vimrc.swp
touch g/.vim/.bashrc.swp
touch g/.vim/renamer.sh.swp
touch g/.vim/vimcht.swp
touch g/.vim/grepnotes.sh.swp
mkdir g/Scripts
touch g/Scripts/.reseq.awk.swp
mkdir g/.fluxbox
touch g/.fluxbox/.menu.swp
$ cd g
$ find . -name '*.swp'
./.vim/.vimrc.swp
./.vim/vimcht.swp
./.vim/nzb.sh.swp
./.vim/Notes.swp
./.vim/config.swp
./.vim/makesess.vim.swp
./.vim/renamer.sh.swp
./.vim/backup.sh.swp
./.vim/.bashrc.swp
./.vim/grepnotes.sh.swp
./Scripts/.reseq.awk.swp
./.fluxbox/.menu.swp
$ find . -name '*.swp' | wc -l
12
$ echo *.swp
*.swp
$ ls -ldog *.swp
ls: cannot access *.swp: No such file or directory
$ rm -rf *.swp
$ find . -name '*.swp' | wc -l
12
Bob
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9950
; Package
coreutils
.
(Fri, 04 Nov 2011 23:33:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 9950 <at> debbugs.gnu.org (full text, mbox):
The system is stock slackware 13.37 on my vanilla home desktop pc, of
which I am the sole user.
Here is the data you requested. With this new set of swp files
behavior is exactly as you said it should be. Is there any way I can
recover the original set of swp files that I removed, or is rm for
keeps?
~ $echo *.swp
*.swp
~ $ls -ldog *.swp
ls: cannot access *.swp: No such file or directory
~ $echo $0
bash
~ $echo $SHELL
/bin/bash
~ $ls -ldog /bin/sh
lrwxrwxrwx 1 4 Oct 22 04:56 /bin/sh -> bash
~ $find . -name '*.swp' -printf '%F %p\n'
ext4 ./.vim/config.swp
ext4 ./.vim/music.sh.swp
ext4 ./.vim/freedom.swp
ext4 ./.vim/Notes.swp
ext4 ./.vim/nzb.sh.swp
ext4 ./.vim/makesess.vim.swp
ext4 ./.vim/.vimrc.swp
ext4 ./.vim/.bashrc.swp
ext4 ./.vim/renamer.sh.swp
ext4 ./.vim/vimcht.swp
ext4 ./.vim/grepnotes.sh.swp
~ $find . -name '*.swp' | wc -l
11
~ $echo *.swp
*.swp
~ $ls -ldog *.swp
ls: cannot access *.swp: No such file or directory
~ $rm -rf *.swp
~ $find . -name '*.swp' | wc -l
11
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/music.sh.swp
/home/g/.vim/freedom.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
~ $rm -rf *.swp
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/music.sh.swp
/home/g/.vim/freedom.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
~ $
On Fri, Nov 4, 2011 at 1:26 PM, Bob Proulx <bob <at> proulx.com> wrote:
> Graham Lawrence wrote:
>> I appreciate the detailed response from Bob Proulx, but I do not think
>> it addressed the question I raised.
>
> Please keep the discussion going until we have reached consensus.
>
>> I had expected "rm -rf *.swp" to remove all the files listed by
>> find, Mr Proulx informed me that it would have removed none of them,
>
> Not given the information discussed so far. :-)
>
>> but in fact what it did was remove SOME of them.
>
> What? That is very unexpected behavior! Please show us the result of
> these commands:
>
> echo *.swp
>
> ls -ldog *.swp
>
> What shell are you using?
>
> echo $0
>
> echo $SHELL
>
> If that happens to turn out to be /bin/sh then please follow up by
> figuring out if /bin/sh is a symlink to a different shell. And if it
> isn't a symlink try to find out what shell it is really.
>
> ls -ldog /bin/sh
>
> Expansion of the '*.swp' is a function of your shell. So finding that
> information is critical to understanding the behavior. I am using
> bash. If you are using a different shell then the behavior could be
> quite different. But it would still be a function of the shell.
>
> What filesystem are you operating upon? Is it a local filesystem or
> a network mounted filesystem such as NFS or Samba? 'find' can print
> this information.
>
> find . -name '*.swp' -printf '%F %p\n'
>
>> For example, why did it remove
>> /home/g/.vim/renamer.sh.swp
>> but ignore
>> /home/g/.vim/backup.sh.swp
>
> I am unable to reproduce your results. I used the following setup
> actions to recreate your test case:
>
> mkdir g
> mkdir g/.vim
> touch g/.vim/config.swp
> touch g/.vim/Notes.swp
> touch g/.vim/nzb.sh.swp
> touch g/.vim/makesess.vim.swp
> touch g/.vim/backup.sh.swp
> touch g/.vim/.vimrc.swp
> touch g/.vim/.bashrc.swp
> touch g/.vim/renamer.sh.swp
> touch g/.vim/vimcht.swp
> touch g/.vim/grepnotes.sh.swp
> mkdir g/Scripts
> touch g/Scripts/.reseq.awk.swp
> mkdir g/.fluxbox
> touch g/.fluxbox/.menu.swp
>
> $ cd g
>
> $ find . -name '*.swp'
> ./.vim/.vimrc.swp
> ./.vim/vimcht.swp
> ./.vim/nzb.sh.swp
> ./.vim/Notes.swp
> ./.vim/config.swp
> ./.vim/makesess.vim.swp
> ./.vim/renamer.sh.swp
> ./.vim/backup.sh.swp
> ./.vim/.bashrc.swp
> ./.vim/grepnotes.sh.swp
> ./Scripts/.reseq.awk.swp
> ./.fluxbox/.menu.swp
>
> $ find . -name '*.swp' | wc -l
> 12
>
> $ echo *.swp
> *.swp
>
> $ ls -ldog *.swp
> ls: cannot access *.swp: No such file or directory
>
> $ rm -rf *.swp
> $ find . -name '*.swp' | wc -l
> 12
>
> Bob
>
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#9950
; Package
coreutils
.
(Sat, 05 Nov 2011 06:12:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 9950 <at> debbugs.gnu.org (full text, mbox):
> The system is stock slackware 13.37 on my vanilla home desktop pc, of
> which I am the sole user.
Should be okay. I was worried that it was some cross compiled program
on a system that was not unix-like.
> Here is the data you requested.
ext4 seems reasonable. I was worried it was some strange network
filesystem and so had unusual behavior.
> With this new set of swp files behavior is exactly as you said it
> should be.
Good! :-)
> Is there any way I can recover the original set of swp files that I
> removed, or is rm for keeps?
Not usually. Especially on journaled filesystems the data is
reclaimed quickly.
> ~ $echo *.swp
> *.swp
No matches.
> ~ $ls -ldog *.swp
> ls: cannot access *.swp: No such file or directory
No files matched. So if you were using 'rm *.swp' then rm wouldn't
have any files to remove either.
> ~ $echo $0
> bash
Bash should behave normally. Was worried that it was some other
different shell that had interesting behavior. zsh for example can
have some interesting behavior if given **/*.swp.
> ~ $ls -ldog /bin/sh
> lrwxrwxrwx 1 4 Oct 22 04:56 /bin/sh -> bash
I was only concerned about /bin/sh if $0 happened to be /bin/sh.
Since it is bash then we can stop there.
I really think that now that you know what is going on that you won't
be able to recreate any test cases where 'rm -rf *.swp' removes any
files that are not in the current directory.
Bob
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 03 Dec 2011 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 199 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.