Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas [EMAIL PROTECTED] wrote: On Wed, 15 Aug 2007, Jim Meyering wrote: Reuben Thomas [EMAIL PROTECTED] wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new option? In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. Bob Proulx presented a couple ways to do what you want. While adding a new rmdir option may look simple, there are larger implications that make it so you'd have to provide significant justification. What are they in this case? Seems to me that it's just printing a diagnostic on an already-existing code path (the one where the directory is unlinked), and hence has no major code burden. Of course there's the usual overhead of documentation c... If the functionality you want is easy enough to obtain through a small (portable) wrapper script, then there's little point in adding a new option. Even so, if the functionality is requested often enough, that may end up being sufficient. One down-side of adding a new option is that it provides a non-portable way of solving the problem (i.e., it works only with the GNU version of the tool), and it's available only if you have the very latest release of the coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas [EMAIL PROTECTED] writes: In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. $ find -type d -empty Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Andreas Schwab [EMAIL PROTECTED] wrote: Reuben Thomas [EMAIL PROTECTED] writes: In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. $ find -type d -empty Note that if you simply want to remove all empty directories (including e.g., those rendered empty by removing leaf dirs), you should also use -depth and -delete: find . -depth -type d -empty -delete Though, the -delete predicate is provided by GNU find, it is not specified by POSIX. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
On Thu, 16 Aug 2007, Jim Meyering wrote: Andreas Schwab [EMAIL PROTECTED] wrote: Reuben Thomas [EMAIL PROTECTED] writes: In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. $ find -type d -empty Note that if you simply want to remove all empty directories (including e.g., those rendered empty by removing leaf dirs), you should also use -depth and -delete: find . -depth -type d -empty -delete Thanks both of you, that's great. -- http://rrt.sc3d.org/ Kleineken: refreshes the dimensions other beers cannot reach ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Reuben Thomas on 8/16/2007 4:12 AM: Note that if you simply want to remove all empty directories (including e.g., those rendered empty by removing leaf dirs), you should also use -depth and -delete: find . -depth -type d -empty -delete Furthermore, you can combine this with -print to get a list of which directories were successfully deleted. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxR5a84KuGfSFAYARAvo5AJ9NhS8zKU1O8RWUXsg3nOO2w28ebACdEdAy LqEH9XMlx/l7e35bFNdCauc= =rFHK -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas [EMAIL PROTECTED] wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new option? While adding a new rmdir option may look simple, there are larger implications that make it so you'd have to provide significant justification. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11 $ rmdir -v 1 rmdir: removing directory, 1 rmdir: 1: Directory not empty $ echo $? 1 And this does not seem like the type of thing that needs to be optimized for keyboard use but sounds more like something in a script. In which case a little more verbose is okay. That leads me to this: for dir in *; do rmdir $dir echo removed: $dir # or whatever you want to do here done Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
On Wed, 15 Aug 2007, Bob Proulx wrote: Reuben Thomas wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11 $ rmdir -v 1 rmdir: removing directory, 1 rmdir: 1: Directory not empty $ echo $? 1 And this does not seem like the type of thing that needs to be optimized for keyboard use but sounds more like something in a script. In which case a little more verbose is okay. That leads me to this: for dir in *; do rmdir $dir echo removed: $dir # or whatever you want to do here done I wanted this for keyboard use, for multiple directories: rmdir [--magic-flag] * in fact. Maybe it's just not common enough a case? -- http://rrt.sc3d.org/ | maximiste, n. pessimiste (Roux) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
On Wed, 15 Aug 2007, Jim Meyering wrote: Reuben Thomas [EMAIL PROTECTED] wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new option? In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. While adding a new rmdir option may look simple, there are larger implications that make it so you'd have to provide significant justification. What are they in this case? Seems to me that it's just printing a diagnostic on an already-existing code path (the one where the directory is unlinked), and hence has no major code burden. Of course there's the usual overhead of documentation c... -- http://rrt.sc3d.org/ | perfect, a. unsatirizable ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas wrote:
I wanted this for keyboard use, for multiple directories:
rmdir [--magic-flag] *
Let me keep working the problem... How about this?
perl -le 'for my $i (@ARGV) { print $i if rmdir($i); };' *
That would be quite easy to turn into a script to reuse more often
such as on the command line.
#!/bin/sh
exec perl -le 'for my $i (@ARGV) { print $i if rmdir($i); };' $@
in fact. Maybe it's just not common enough a case?
It does seem pretty unusual to me to want to do something like that
and I have not wanted to do it before. In fact thinking about it a
little bit more and this seems to be actively bad to me. I think the
reverse information is really what I would want to see.
I am pretty pedantic about checking for errors. The reason I don't
like the above is that I can't tell the difference between a failure
to remove the directory and a failure to remove the directory. I mean
sure it is possible to print out which directories were removed and
that is fine for the directories that were actually removed. But what
if there is a problem? Already there is an expectation that some
directories won't get removed because of the error that they are not
empty. But what about other errors such as permissions and read-only
filesystems and I/O errors and other things? They are errors that I
would want to know about. I think it is better to perform actions
purposefully and to verify that the action did succeed.
But for some keyboard activities I am okay with being lazy. I have
often simply done 'rmdir *' and then looked to see what resulted. I
know that only empty directories will get removed and it will spew
errors for the others and I ignore that. But since I will look
immediately at the result and deal with the new state that seems
okay. If a directory that I think should have been removed was not I
can simply inspect it and 'rm -rf' it if needed.
So for me I would almost always want the reverse of this information.
I almost never want to know the names of the directories that I
removed. I would almost always want to know the names of the
directories that did *not* get removed. I assume that I am not alone
in this since this is also the behavior we currently have from the
commands for all of these years. The reverse information just does
not feel right to me.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
