jaalto wrote: > On 2012-03-01 09:05, Jim Meyering wrote: > | > /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627 6.0G > | > 4.1G 1.7G 72% / > > | That has been addressed: > | Lots of discussion: > | http://thread.gmane.org/gmane.comp.gnu.coreutils.general/2026 > | Here's the commit that fixed it: > | http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=1e18d8416f9ef43bf0 > | > | Thanks for the suggestions. > | > | Adding --exclude is another way to work around the duplicate > | entry problem, but I'd prefer to wait a (possibly long) while, > | for a solution that fixes the underlying problem. > > I'm glad to hear that next release addresses the problem somewhat. > > However, from the commit it looks like it is only tackling the "uuid" > issue and not a general problem where: > > - Any mounted directory could be verly long > > Although my bug report was primarily triggered by seeing the uuid > paths, I'd like to propose these options (-X, -r) to tackle a more > generic problem of: > > path first, calculations next on the same line > > An example. I have other mounted directories that are *very* long: > > /mnt/extent/development/src/project/ ... > > It's just not the "uuid" lines that are problematic. > > Especially the --reverse option would solve lot of these long path > issues. > > | > SUGGESTIONS > | > > | > (1) Add exclude to option to filter out items from the display, thus > | > calculating the line-up column better. ... > | > (2) Also add option to reverse the output to see the values first (most > | > important) in a full display: > | > > | > -r, --reverse > | > > | > $ df -Hlr > | > > | > Size Used Avail Use% Mounted-on Filesystem > | > 6.0G 4.1G 1.7G 72% / rootfs > | > 192M 0 192M 0% /dev udev > | > 40M 1.5M 38M 4% /run tmpfs > | > 6.0G 4.1G 1.7G 72% / > /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627 > | > 5.3M 0 5.3M 0% /run/lock tmpfs > | > 79M 7.9M 71M 10% /tmp tmpfs > | > 79M 0 79M 0% /run/shm tmpfs > | > 6.0G 4.1G 1.7G 72% /srv/cante.src > /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627 > | > 6.0G 4.1G 1.7G 72% /srv/cante.tmp > /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627 > | > 18G 8.1G 8.3G 50% /mnt/extent /dev/sdb1 > | > 18G 8.1G 8.3G 50% /usr/src /dev/sdb1 > | > 18G 8.1G 8.3G 50% /root/vc /dev/sdb1
I agree that your --reverse (but without the short-named '-r') would be a useful improvement, regardless. That sounds reasonable for 8.16 is someone writes the patch. Even without the -r, you could still abbreviate the long name to "--r". Regarding --exclude, its name is problematic since there's already an --exclude-type option. Adding a new --exclude option would render invalid any existing use of the perfectly valid abbreviation, --exclude=$FS_TYPE And then some would probably want an --include option to go along with it. This makes me wonder about different semantics, say --filter=[-+]REGEXP where --filter=-EXCLUDE_RE and --filter=+INCLUDE_RE. Or maybe even encode more. What if you want to filter based on the "Mounted-on" name and I want to filter based on the "Filesystem" column?
