Missing --human-readable option and maybe --one-file-system. And also --block-size....

This is the neatest piece of code I've seen in months

2 members found this post helpful.

You're going to make me blush. I'm glad you appreciate it. And thank you for the suggestions.

Yes, and I'm looking at this for a future release, plus more.

First, dtt installers should have the option to configure the default unit to match the df/du on the target platform.
In the case of Slackware 15.0 that runs Gnu df/du, that would be the customary kilobyte (1024 bytes).
In the case of a system that follows the Unix standard, for example FreeBSD, that would be the customary block (512 bytes).

And dtt should offer the option to override the default unit just as you suggest.
It should support -b, -k, -m, --block-size|-B, and --human-readable|-h.

Easy comparison between the outputs of df, du, and dtt was an early important design feature.
dtt was originally written over ten years ago for a non-Linux Unix.
Historically, one block was equivalent to the near-universal 512-byte disk sector.
Consequently, Unix df/du report in 512-byte units.
So this explains why dtt reports in 512-byte units.
Gnu df/du were intentionally made incompatible with Unix in that regard.

Reporting in filesystem block units is another option I want to support.
It's crazy that neither Unix df/du nor Gnu df/du report disk space using the block size.
Suppose your blocksize is 4096 bytes, and there is 1 block free.
To report you have 4 free customary kilobytes or 8 free customary blocks is misleading.
It's more meaningful to report you have 1 free filesystem block.
Because you don't actually have 4 more, or 8 more, blocks available for allocation.
You have 1, and the next tiny file you create will allocate it.

As it stands, dtt does not cross filesystem boundaries.
In a future release I'd like to lift that restriction.
At that point it would make sense to consider which mode will be the default, and offer an override option.

Thanks for the clarification Ed. I figured that out after posting but left it up to get the full explanation from you anyway so thanks for that.

As others have mentioned, a "human readable" option would be nice. Also perhaps exiting on an "unknown option" would be better, rather than continuing to search the current directory for the top ten files after spitting out the error. Just a thought.

Thanks for sharing. Always nice to see interesting solutions for age old problems.

1 members found this post helpful.

Thank you, I will consider it. I tend to follow the Robustness Principle when accepting input: "be conservative in what you do, be liberal in what you accept from others." (J. Postel)

I would prefer a default of not to cross filesystem boundaries.

this can be easily solved by a .rc file, which [may] contain personalized defaults for this and for any other settings.

I am pretty certain @metaed was referring to possibly adding program options to dtt. He asked for preferences, I responded with mine. Which ever @metaed decides as the default (currently not to cross filesystem boundaries) adding an option to cross (or not to) filesystem boundaries is a nice idea.

One could also use an alias, once the option exist, which it currently does not.

Version 1.1a released at: https://metaed.com/papers/dtt/

This is a bugfix, performance, and refactoring release. It prepares the code for future release of features we've been talking about.

Minor functional differences:
* Return success code when --help requested
* Reduce wasted CPU

The biggest change is mostly invisible, unless you looked at the technical paper for version 1.0: breaking up the monolithic lookup phase using Literate Programming techniques. This is what saved some CPU ticks, but the main reason for the refactor was to make it much easier to add new features.

Also in this release:
* Test all counting methods
* Clean up documentation
* Add roadmap
* Add changelog
* Add acknowledgements

2 members found this post helpful.

Personally, so would I. But that’s a conflict with the requests I’m seeing to make dtt options work like du and df options. Unix df has the x option, and Gnu df has the --one-file-system|x option, because du crosses file system boundaries by default. So I’m leaning toward making dtt cross file system boundaries by default, and offering the --one-file-system|x option. You and I would use an alias to correct the behavior to our personal preference.

What's your reaction?

If you want to make a general tool you need have a lot of options to make it really general and configurable and also you need to make a conf file (or something similar) to be able to define user specific defaults. That is the usual way. As you have already made it check du, ncdu, df, free and probably other tools, pick the flags you [may] find useful and adopt them.
Don't forget that your personal preferences are not necessarily important to others.

Well your the author. Since you asked I like the current default. Your unique masterpiece is dtt, it doesn't have to mirror the behavior of other programs such as du and df, both of which I use. Of course you are the author so I will I'm good with whatever you decide. Great program by the way, I like to what dtt brings to the mix. Both du and df are useful utilities now we have another useful utility that present the info in a different way. Always nice to have alternatives.

Thank you again to everyone who posted comments.

I've posted version 2 at: https://metaed.com/papers/dtt

Summary from the changelog:

• eliminate the one-filesystem limitation
• backport all the way to Perl 5.6.1
• make command-line options compatible with Unix df/du and Gnu df/du where practical
• let user customize the reporting blocksize using an environment variable
• let user scale output by native filesystem blocksize in addition to classic metric and SI units
• much copyediting to make the manual clearer

Please, if you can, smoke-test it. If it seems to work, I'll re-release as a beta and post a wider release announcement.

1 members found this post helpful.

This is interesting, my own favourite way is to use this:

I've tried dtt and it's different but not sure how - du -hax (reversed to be able to compare it to dtt):

dtt:
So dtt excludes "/usr/lib64" "/usr/local" etc. because everything under those is supposed to be accounted for in deeper paths, is that correct? However, I'm not sure it's working properly, as I have I have 1.4GB of files in /usr/lib64:

and I think I'd expect that to show up above /usr/share/locale.

Thank you for giving it a test drive, and for your helpful comments!

This looks like dtt doing what it's really good at: elevating deep subtrees that make a disproportionally large contribution to the total. From the manual:

If any directory would be in the top ten list along with one or more of its descendant objects, the descendant objects are reported, not the directory.

What you're finding is that /usr/lib64/libreoffice/program is so large on its own that it merits being listed as one of the top ten objects, and so disproportionally large compared to other objects in /usr/lib64 that it's the only one that made the grade.

You could of course re-run dtt starting from /usr/lib64 to see what the other outliers are just in that subtree. Or, if you were going to alias this particular search and reuse it, it might be helpful if you could exclude /usr/lib64/libreoffice. Not something I've needed, so I haven't thought about implementing --exclude or --exclude-from. Until now, that is.

Announcement is here.