bug#10915: 8.13: df -- overly long output lines are very hard to read

[Jim Meyering]

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?