in reply to UNIX command - remove 0 byte file

Or do you mean all files in a tree with 0 bytes? And then there is the question of whether hidden files (.something) should be included in the search. The unix way is the tersest (this example includes hidden files) 
find /whatever/path/ -size 0 -exec rm {} \;

[download]
And the perl way, with hidden files filtered out this time: 
Purge( '/whatever/path' );
sub Purge {
    my $dir = shift;
    open my $dh or die "$!, for $dir";
    for my $file ( grep !/^\./, readdir $dh ) {
        my $path = "$dir/$file";
        if ( -d $path ) {
            Purge( $path );
        }
        else {
            ( -z $path ) and unlink $path;
        }
    }
    close $dh or die "$!, for $dir";
}

[download]

-M

Free your mind

Replies are listed 'Best First'.
Re^2: UNIX command - remove 0 byte file
by thor (Priest) on Sep 23, 2005 at 11:28 UTC
    find /whatever/path/ -size 0 -exec rm {} \;
    One comment. "-exec" is generally not the best idea unless you care that your command is executed on exactly one file at a time. The problem with exec is that it spawns a new process for every file that it finds. Which isn't bad if the process takes a long time; the tiem spent in starting a new process is shadowed by the run time of the executable. However, in the case of rm, the operation is very quick, so the converse is true.

    In this case, we have a couple of options. In looking at my local find man page, I see that find has a -delete option. This may be a Linux-ism though, as I don't seem to remember this on Solaris. Failing that, we always have xargs. And so, your invocation becomes either find . -size 0 -delete or find . -size 0 | xargs rm. I've seen the xargs version speed up an invocation of find by roughly an order of magnitude. YMMV.

    thor

    Feel the white light, the light within
    Be your own disciple, fan the sparks of will
    For all of us waiting, your kingdom will come

[reply]
[d/l]
[select]
      -delete is indeed a linuxism as opposed to a unix option of find, but xargs is indeed available under e.g. Solaris.

      A potential problem with using xargs is that although it means only one execution of rm which bodes better performance, it also converts everything read in from the pipe into a single argument list, which above a certain limit will cause rm to Segmentation Fault, whereas -exec is guaranteed to work for an unlimited number of files. The choice therefore depends on the particular environment it is being applied to.

      -M

      Free your mind

[reply]
        Actually, xargs is supposed to handle that. It will break the command line when it gets too long (1024 words, I think) and run the command again.

        But the most annoying thing with xargs is that it doesn't handle spaces or other special characters well: 

        server:~> ls
a file
server:~> ls | xargs rm
a: No such file or directory
file: No such file or directory

        [download]
        You're forced to do tricks with sed (or perl -e) to get this to work.
[reply]
[d/l]
        A potential problem with using xargs is that although it means only one execution of rm which bodes better performance, it also converts everything read in from the pipe into a single argument list

        No, it doesn't. xargs is smart enough that it knows the system limits, and splits of the task into several processes if needed. That's the beauty of xargs. 

        $ find /opt/perl -print0 2> /dev/null | xargs -0 | wc -l
     42
$

        [download]
        Split up into 42 calls to /bin/echo (the default for xargs). Note also the use of -print0 and -0, that eliminates problems with filenames containing whitespace.
[reply]
[d/l]

In Section Seekers of Perl Wisdom