[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10915: 8.13: df -- overly long output lines are very hard to read
From: |
Jim Meyering |
Subject: |
bug#10915: 8.13: df -- overly long output lines are very hard to read |
Date: |
Thu, 01 Mar 2012 11:37:32 +0100 |
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?
bug#10915: 8.13: df -- overly long output lines are very hard to read, Pádraig Brady, 2012/03/01