Prev: Coloring stdin, stdout, stderr differently
Next: replace strings based on a dictionary
From: Stachu 'Dozzie' K. on 13 May 2010 19:02
On 2010-05-13, pk <pk(a)pk.invalid> wrote:
>>> The real problem here is to determine whether a directory is empty, which
>>> is generally not straightforward and subject to race conditions.
>>
>> What? O_o
>> I've always thought that rmdir() is atomic syscall.
>>
>> find . -type d | sort -r | xargs rmdir
>
> Well, if you do it like that you rely on rmdir failing, which does not have
> race conditions. While it may be a solution, I personally don't like having
> the screen cluttered with pointless error messages; at the same time, I
> don't want to redirect stderr to /dev/null because then I could miss real
> errors.

Erm.
find . -type d | sort -r | xargs rmdir 2>&1 | grep -v ': Directory not empty'

Or even better:
find . -type d | sort -r | perl -MPOSIX=ENOTEMPTY -nle '$_ eq "." || rmdir || $! == ENOTEMPTY || warn "rmdir($_): $!\n"'

> So I check for emptiness first, and then delete; this is a potential race.
> In practice, if you know that the directory tree isn't being modified, the
> race condition problem can be ingored.

And in practice, you often *can't* ignore race condition, because you
don't know in what ways and conditions your script will be used in the
future. Yet still, there are plenty shorter, more robust solutions than
yours.

--
Secunia non olet.
Stanislaw Klekot
From: pk on 13 May 2010 19:12
Stachu 'Dozzie' K. wrote:

> On 2010-05-13, pk <pk(a)pk.invalid> wrote:
>>>> The real problem here is to determine whether a directory is empty,
>>>> which is generally not straightforward and subject to race conditions.
>>>
>>> What? O_o
>>> I've always thought that rmdir() is atomic syscall.
>>>
>>> find . -type d | sort -r | xargs rmdir
>>
>> Well, if you do it like that you rely on rmdir failing, which does not
>> have race conditions. While it may be a solution, I personally don't like
>> having the screen cluttered with pointless error messages; at the same
>> time, I don't want to redirect stderr to /dev/null because then I could
>> miss real errors.
>
> Erm.
> find . -type d | sort -r | xargs rmdir 2>&1 | grep -v ': Directory not
> empty'
>
> Or even better:
> find . -type d | sort -r | perl -MPOSIX=ENOTEMPTY -nle '$_ eq "." || rmdir
> || $! == ENOTEMPTY || warn "rmdir($_): $!\n"'

You can save the sort -r by using "find -depth".

>> So I check for emptiness first, and then delete; this is a potential
>> race. In practice, if you know that the directory tree isn't being
>> modified, the race condition problem can be ingored.
>
> And in practice, you often *can't* ignore race condition, because you
> don't know in what ways and conditions your script will be used in the
> future. Yet still, there are plenty shorter, more robust solutions than
> yours.

For 90% of the scripts I write, I perfectly know where and when they will be
used;for the remaining 10%, I try to make them as robust as possible (and
this is an old debate I certainly don't want to reopen, so I won't reply
further on that). So your statement is not always true.

Regarding my solution, I think I've clearly stated the conditions under
which it is supposed to be run, and what are its limitations.

And since you claim that there are "plenty" of better solutions, I suppose
you won't mind showing at least two or three of them, so people can really
see if they are really robust, and if they don't have problems under certain
circumstances.

I wouldn't call any of the solutions you posted so far robust, nor short,
nor elegant. Looking forward for the better ones you'll certainly post.
From: Thomas 'PointedEars' Lahn on 13 May 2010 21:45
James wrote:

> In unix, how to do efficiently find and delete empty directories
> recursively
>
> If no regular files (or symlink) present, it is considered as empty.
> Directories with emtpy subdirectories are considered as empty also.

RTFM.


PointedEars
From: Laurianne Gardeux on 13 May 2010 21:56
James à écrit :

> In unix, how to do efficiently
> find and delete empty directories recursively
>
> If no regular files (or symlink) present, it is considered as empty.
> Directories with emtpy subdirectories are considered as empty also.
>
> TIA
> JL

What about

find . -type d -empty -delete

?
From: Stachu 'Dozzie' K. on 14 May 2010 02:29
On 2010-05-13, pk <pk(a)pk.invalid> wrote:
>>> So I check for emptiness first, and then delete; this is a potential
>>> race. In practice, if you know that the directory tree isn't being
>>> modified, the race condition problem can be ingored.
>>
>> And in practice, you often *can't* ignore race condition, because you
>> don't know in what ways and conditions your script will be used in the
>> future. Yet still, there are plenty shorter, more robust solutions than
>> yours.
>
> For 90% of the scripts I write, I perfectly know where and when they will be
> used;

....except that you still don't know where they will be used and what
for, and still you leave hidden problems. Great. "No, `make' tool will
be used just for compiling programs. I know that and I can assure you."
And I've seen

> for the remaining 10%, I try to make them as robust as possible (and
> this is an old debate I certainly don't want to reopen, so I won't reply
> further on that). So your statement is not always true.

It's always true. You don't know who will use your scripts and what for.
All scripts, where it's not too much work (like here, or even more, here
you add much work just to break the script), should be
stupid-input-proof.

> And since you claim that there are "plenty" of better solutions, I suppose
> you won't mind showing at least two or three of them,

I did in <hsi0f0$lec$2(a)solani.org> (my previous post), if you haven't
noticed.

> so people can really
> see if they are really robust, and if they don't have problems under certain
> circumstances.

Except for common xargs problem (whitespace splitting), they're better
and much shorter than your multi-script solution.

> I wouldn't call any of the solutions you posted so far robust, nor short,
> nor elegant.

And yours:
* Is it robust? Nope.
* Is it short? Hell no! Two scripts to maintain?
* Is it elegant? In no way.

--
Secunia non olet.
Stanislaw Klekot
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Coloring stdin, stdout, stderr differently
Next: replace strings based on a dictionary