[EMAIL PROTECTED] (Manoj Srivastava) wrote on 16.02.98 in <[EMAIL PROTECTED]>:
> >>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
>
> Charles> The tools to exploit this information aren't here yet, but I
> Charles> -have- put a fair amount of thought into it, and I'm
> Charles> convinced that this is data which a future tool could make
> Charles> very good use of.
>
> Impleent first, design later only leads one into a strait
> jacket with very limited available courses of action. As I said
> before:
>
> Manoj> Until we have a tool, I do not think we can determine the input
> Manoj> format for such a tool. Packaging files that could possibly be
> Manoj> the input for an as yet unwritten tool (we are not clairvoyant,
> Manoj> are we now?) is slightly silly.
I just tried to write a quich checker in Perl, and discovered that the
data is indeed in a suboptimal format.
This is what I currently have:
checkdu.pl:
#! /usr/bin/perl -w
use strict;
my %need;
my ($lbs, $lpn) = (0, "");
while (<>) {
my ($bs, $pn) = split /\s+/, $_;
my $fs = (stat("/$pn"))[0];
print "$fs:$bs:$pn\n";
$need{$fs} = 0 unless defined $need{$fs};
$need{$fs} += $bs;
}
open DF, "df |";
while (<DF>) {
m:/dev.*\s(/\S*): or next;
my $dir = $1;
my $fs = (stat($dir))[0];
printf "%10d %s\n", $need{$fs}, $dir if defined $need{$fs};
}
close DF;
Easy, huh? Except for one problem. The typical du output has the outer
directories include the space already mentioned for the inner ones.
So I need to subtract those.
Now, while that's easy for a human, I'd expect it to at least double the
size of this script. Much better if the size came pre-subtracted.
Fortunately, that's easy to do. Use du -S instead of plain du.
Ok, Manoj. Now we have both a tool and a file format for that tool. Now
what?
MfG Kai
