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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10915 in the body.
You can then email your comments to 10915 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jari Aalto <jari.aalto <at> cante.net>
To: bug-coreutils <at> gnu.org
Subject: 8.13: df -- overly long output lines are very hard to read
Date: Thu, 01 Mar 2012 01:41:18 -0500

With long path names, the output is very hard to read because each line is
so long:

    $ df -Hl

    Filesystem                                              Size  Used Avail Use% Mounted on
    rootfs                                                  6.0G  4.1G  1.7G  72% /
    udev                                                    192M     0  192M   0% /dev
    tmpfs                                                    40M  1.5M   38M   4% /run
    /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /
    tmpfs                                                   5.3M     0  5.3M   0% /run/lock
    tmpfs                                                    79M  7.9M   71M  10% /tmp
    tmpfs                                                    79M     0   79M   0% /run/shm
    /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  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/sdb1                                                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

In a smaller terminal the lines wrap, which makes it even harder:

    Filesystem                                              Size  Used Avail Use% M\
    ounted on
    rootfs                                                  6.0G  4.1G  1.7G  72% /
    udev                                                    192M     0  192M   0% /d\
    ev
    tmpfs                                                    40M  1.5M   38M   4% /r\
    un
    /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /
    tmpfs                                                   5.3M     0  5.3M   0% /r\
    un/lock
    tmpfs                                                    79M  7.9M   71M  10% /t\
    mp
    tmpfs                                                    79M     0   79M   0% /r\
    un/shm
    /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /s\
    rv/cante.src
    /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /s\
    rv/cante.tmp
    /dev/sdb1                                                18G  8.1G  8.3G  50% /m\
    nt/extent
    /dev/sdb1                                                18G  8.1G  8.3G  50% /u\
    sr/src
    /dev/sdb1                                                18G  8.1G  8.3G  50% /r\
    oot/vc

SUGGESTIONS

(1) Add exclude to option to filter out items from the display, thus
calculating the line-up column better.

        -X, --exclude PATTERN

    Where patterns could be preferably EREGEXP (best), or in the initial
    implementation a simple STRING to match.

    df -HlX by-uuid

    $ df -Hl

    Filesystem      Size  Used Avail Use% Mounted on
    rootfs          6.0G  4.1G  1.7G  72% /
    udev            192M     0  192M   0% /dev
    tmpfs            40M  1.5M   38M   4% /run
    tmpfs           5.3M     0  5.3M   0% /run/lock
    tmpfs            79M  7.9M   71M  10% /tmp
    tmpfs            79M     0   79M   0% /run/shm
    /dev/sdb1        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

(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

Message #8 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Thu, 01 Mar 2012 09:05:01 +0100

Jari Aalto wrote:
> With long path names, the output is very hard to read because each line is
> so long:
>
>     $ df -Hl
>
>     Filesystem                                              Size  Used Avail Use% Mounted on
>     rootfs                                                  6.0G  4.1G  1.7G  72% /
>     udev                                                    192M     0  192M   0% /dev
>     tmpfs                                                    40M  1.5M   38M   4% /run
>     /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /
...

Thank you for the report and suggestions.
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

> SUGGESTIONS
>
> (1) Add exclude to option to filter out items from the display, thus
> calculating the line-up column better.
>
>         -X, --exclude PATTERN
>
>     Where patterns could be preferably EREGEXP (best), or in the initial
>     implementation a simple STRING to match.
>
>     df -HlX by-uuid
>
>     $ df -Hl
>
>     Filesystem      Size  Used Avail Use% Mounted on
>     rootfs          6.0G  4.1G  1.7G  72% /
>     udev            192M     0  192M   0% /dev
>     tmpfs            40M  1.5M   38M   4% /run
>     tmpfs           5.3M     0  5.3M   0% /run/lock
>     tmpfs            79M  7.9M   71M  10% /tmp
>     tmpfs            79M     0   79M   0% /run/shm
>     /dev/sdb1        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
>
> (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

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.

Message #11 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: jaalto <jari.aalto <at> cante.net>
To: Jim Meyering <jim <at> meyering.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Thu, 1 Mar 2012 10:20:29 +0200

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.
| >
| >         -X, --exclude PATTERN
| >
| >     Where patterns could be preferably EREGEXP (best), or in the initial
| >     implementation a simple STRING to match.
| >
| >     df -HlX by-uuid
| >
| >     $ df -Hl
| >
| >     Filesystem      Size  Used Avail Use% Mounted on
| >     rootfs          6.0G  4.1G  1.7G  72% /
| >     udev            192M     0  192M   0% /dev
| >     tmpfs            40M  1.5M   38M   4% /run
| >     tmpfs           5.3M     0  5.3M   0% /run/lock
| >     tmpfs            79M  7.9M   71M  10% /tmp
| >     tmpfs            79M     0   79M   0% /run/shm
| >     /dev/sdb1        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
| >
| > (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

Message #14 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jaalto <jari.aalto <at> cante.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: 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?

Message #17 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 01 Mar 2012 10:38:01 +0000

On 03/01/2012 06:41 AM, Jari Aalto wrote:
> 
> With long path names, the output is very hard to read because each line is
> so long:
> 
>     $ df -Hl
> 
>     Filesystem                                              Size  Used Avail Use% Mounted on
>     rootfs                                                  6.0G  4.1G  1.7G  72% /
>     udev                                                    192M     0  192M   0% /dev
>     tmpfs                                                    40M  1.5M   38M   4% /run
>     /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /
>     tmpfs                                                   5.3M     0  5.3M   0% /run/lock
>     tmpfs                                                    79M  7.9M   71M  10% /tmp
>     tmpfs                                                    79M     0   79M   0% /run/shm
>     /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  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/sdb1                                                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

I wouldn't say that's very hard to read at all.
We've addressed the specific uuid case above anyway.

> 
> In a smaller terminal the lines wrap, which makes it even harder:

Well that's not the common case, nor is it common to have
naturally long "Filesystem" items.
For these uncommon cases you could just use a pager like:

  df | less -S

> SUGGESTIONS
> 
> (1) Add exclude to option to filter out items from the display, thus
> calculating the line-up column better.
> 
>         -X, --exclude PATTERN
> 
>     Where patterns could be preferably EREGEXP (best), or in the initial
>     implementation a simple STRING to match.

> (2) Also add option to reverse the output to see the values first (most
> important) in a full display:
> 
>         -r, --reverse

I'm not that enthusiastic about these new options.

cheers,
Pádraig.

Message #20 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: jaalto <jari.aalto <at> cante.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Thu, 01 Mar 2012 11:47:55 +0100

Jim Meyering wrote:
...
> 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?

Besides, once the columns are reordered, you can filter
just fine using grep.

Message #23 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Jim Meyering <jim <at> meyering.net>, jaalto <jari.aalto <at> cante.net>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>
Subject: RE: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 1 Mar 2012 11:56:37 +0100

Jim Meyering wrote:
> jaalto wrote:

> | >         -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".

What about a more general --fmt (or --format) option to
just get the columns you want in the order you want?
E.g.

  df --format=size,free%,mnt,fs
or
  df --format=size-h,mnt  # <column name>-h or 
  df --format=Size,mnt    # uppercase Size meaning -h

Have a nice day,
Berny

Message #26 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: "Voelker\, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Thu, 01 Mar 2012 12:07:14 +0100

Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> jaalto wrote:
>
>> | >         -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".
>
> What about a more general --fmt (or --format) option to
> just get the columns you want in the order you want?
> E.g.
>
>   df --format=size,free%,mnt,fs
> or
>   df --format=size-h,mnt  # <column name>-h or
>   df --format=Size,mnt    # uppercase Size meaning -h

Good point about the name.
However, a --format=SPEC normally contains %-directives
(find, stat, and of course printf), which would make it a bigger change.
That sounds like the right course, but now, probably better to target 8.17.

Message #29 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jari Aalto <jari.aalto <at> cante.net>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 01 Mar 2012 11:27:59 +0000

On 03/01/2012 10:38 AM, Pádraig Brady wrote:
> On 03/01/2012 06:41 AM, Jari Aalto wrote:
>>
>> With long path names, the output is very hard to read because each line is
>> so long:
>>
>>     $ df -Hl
>>
>>     Filesystem                                              Size  Used Avail Use% Mounted on
>>     rootfs                                                  6.0G  4.1G  1.7G  72% /
>>     udev                                                    192M     0  192M   0% /dev
>>     tmpfs                                                    40M  1.5M   38M   4% /run
>>     /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  6.0G  4.1G  1.7G  72% /
>>     tmpfs                                                   5.3M     0  5.3M   0% /run/lock
>>     tmpfs                                                    79M  7.9M   71M  10% /tmp
>>     tmpfs                                                    79M     0   79M   0% /run/shm
>>     /dev/disk/by-uuid/492764a5-7506-4489-8fd0-82d0d284d627  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/sdb1                                                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
> 
> I wouldn't say that's very hard to read at all.
> We've addressed the specific uuid case above anyway.
> 
>>
>> In a smaller terminal the lines wrap, which makes it even harder:
> 
> Well that's not the common case, nor is it common to have
> naturally long "Filesystem" items.
> For these uncommon cases you could just use a pager like:
> 
>   df | less -S
> 
>> SUGGESTIONS
>>
>> (1) Add exclude to option to filter out items from the display, thus
>> calculating the line-up column better.
>>
>>         -X, --exclude PATTERN
>>
>>     Where patterns could be preferably EREGEXP (best), or in the initial
>>     implementation a simple STRING to match.
> 
>> (2) Also add option to reverse the output to see the values first (most
>> important) in a full display:
>>
>>         -r, --reverse
> 
> I'm not that enthusiastic about these new options.

To expand a bit on why I'm not enthusiastic.

Well mainly I don't see a pressing need for them.
Generally one has large terminals these days,
and with `less -S` you can scroll left/right anyway.

If we were adding this option I wouldn't call it --reverse,
since it might be confused with item order, rather than field order.
Also the field order isn't even reversed, just the first and last swapped.
I can't think of a good name, maybe --paths-last or something.
Bernard's --format would be more generally useful and I'd be
happier with something like that. Again it's borderline though.

Also just swapping the fields doesn't address the line wrapping
issue which is by far the most problematic issue for readability.
Well one advantage to putting paths at the end, is the wrapping would
be minimised to just long lines rather than all lines.
For me this is much the same though, as once I see any wrapping I rerun
through a pager or whatever.

cheers,
Pádraig.

Message #32 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jari Aalto <jari.aalto <at> cante.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10915 <at> debbugs.gnu.org, Jari Aalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Thu, 01 Mar 2012 07:03:14 -0500

2012-03-01 06:27 Pádraig Brady <P <at> draigBrady.com>:
| On 03/01/2012 10:38 AM, Pádraig Brady wrote:
|
| To expand a bit on why I'm not enthusiastic.
|
| Well mainly I don't see a pressing need for them.
| Generally one has large terminals these days,

It is still a problem. Keep i ming that people don't all keep "one big
terminal open", but it is posisble to have large number of applications
tightly next each other for ease of use and fast switching between them
(autoraise...)

The length of the available space is not very long. E.g I use typical setup
with 50 applications open simultaneously with:

     +----------+
  +--|          |--+
  |  |          |  |
  |  |          |  |---+
  |  |          |  |   |--+
  |  |          |  |   |  |

  ......................

  |  |          |  |---+
  +--|          |--+
     +----------+

The effective space for "terminals" in this kind setup is typicall 80..100
character. If yu widen windows, you start loosing effective screen space
from other applications.

Jari

Message #35 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10915 <at> debbugs.gnu.org
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 01 Mar 2012 07:53:41 -0800

On 03/01/2012 03:27 AM, Pádraig Brady wrote:
> Well mainly I don't see a pressing need for them.

I far prefer putting the file name last, as this
greatly improves readability.  This is a place
where 'ls' did it right.  I would favor a gradual
transition where 'df' eventually puts the file name last
by default.  POSIX permits this, and it'd make 'df'
much nicer.

Message #38 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 26 Jul 2012 15:23:46 +0100

On 03/01/2012 10:56 AM, Voelker, Bernhard wrote:
> Jim Meyering wrote:
>> jaalto wrote:
> 
>> | >         -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".
> 
> What about a more general --fmt (or --format) option to
> just get the columns you want in the order you want?
> E.g.
> 
>   df --format=size,free%,mnt,fs
> or
>   df --format=size-h,mnt  # <column name>-h or 
>   df --format=Size,mnt    # uppercase Size meaning -h

This is a border line feature, but I'm 60:40 for implementing it.

Note something similar I noticed is:

  findmnt -l -o FSTYPE,SOURCE,TARGET

It would make sense to align as closely to that as possible.
So a full --output list supported by df could be
FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT

It's probably sufficient to use this to just order fields,
and leave other formatting to existing modifiers.

cheers,
Pádraig.

Message #41 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 26 Jul 2012 17:43:22 +0200

On 07/26/2012 04:23 PM, Pádraig Brady wrote:
> On 03/01/2012 10:56 AM, Voelker, Bernhard wrote:
>>
>> What about a more general --fmt (or --format) option to
>> just get the columns you want in the order you want?
>> E.g.
>>
>>   df --format=size,free%,mnt,fs
>> or
>>   df --format=size-h,mnt  # <column name>-h or 
>>   df --format=Size,mnt    # uppercase Size meaning -h
> 
> This is a border line feature, but I'm 60:40 for implementing it.
> 
> Note something similar I noticed is:
> 
>   findmnt -l -o FSTYPE,SOURCE,TARGET
> 
> It would make sense to align as closely to that as possible.
> So a full --output list supported by df could be
> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT
> 
> It's probably sufficient to use this to just order fields,
> and leave other formatting to existing modifiers.

Implementing --output=<field-list> is of course much simpler
than what Jim proposed [1]:
he suggested a stat-like --format option which takes %-directives.

That would be much more flexible for the user, and the existing
output formats would just be a pre-defined format strings.

We could for the first time have blocks and inodes statistics
in one command:

  %i  inodes
  %I  inodes in percent
  %a  AVAIL
  %A  AVAIL in percent
  %u  unused
  %U  unused percentage
  %t  total size
  %T  FSTYPE
  %s  SOURCE
  %m  TARGET (mount point)
  ...

  df --format="%u:%i:%T:%m"

And some directives could have mixed SIZE modifiers, e.g.

  %{SIZE}u	used blocks with SIZE like KMGTPEZY.
  %{SIZE}i      inode number

  df --format="%Tt %Gu %Ki %m"

Scripts could parse the output of --format (or --printf) much
safer (SOURCE and TARGET can include almost any characters like
'\n', '\t', etc. but never e.g. NULL)

  df --printf="%U\0%s\0%m\0\n"

As already said, this would be a greater change in df.c,
but some code could surely be shared with stat.c and maybe
in future with "ls --format=..." ;-)

I'm not against --output, but the advantage of a more
flexible --printf is unbeatable IMO.

Have a nice day,
Berny

[1] http://lists.gnu.org/archive/html/bug-coreutils/2012-03/msg00007.html

Message #44 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Thu, 26 Jul 2012 17:11:56 +0100

On 07/26/2012 04:43 PM, Bernhard Voelker wrote:
> On 07/26/2012 04:23 PM, Pádraig Brady wrote:
>> On 03/01/2012 10:56 AM, Voelker, Bernhard wrote:
>>>
>>> What about a more general --fmt (or --format) option to
>>> just get the columns you want in the order you want?
>>> E.g.
>>>
>>>   df --format=size,free%,mnt,fs
>>> or
>>>   df --format=size-h,mnt  # <column name>-h or 
>>>   df --format=Size,mnt    # uppercase Size meaning -h
>>
>> This is a border line feature, but I'm 60:40 for implementing it.
>>
>> Note something similar I noticed is:
>>
>>   findmnt -l -o FSTYPE,SOURCE,TARGET
>>
>> It would make sense to align as closely to that as possible.
>> So a full --output list supported by df could be
>> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT

Oh right the last 4 items above should also have I... variants
to cater for inodes.

>> It's probably sufficient to use this to just order fields,
>> and leave other formatting to existing modifiers.
> 
> Implementing --output=<field-list> is of course much simpler
> than what Jim proposed [1]:
> he suggested a stat-like --format option which takes %-directives.
> 
> That would be much more flexible for the user, and the existing
> output formats would just be a pre-defined format strings.

> We could for the first time have blocks and inodes statistics
> in one command:

Good point, but that could be allowed too with --output

> 
>   %i  inodes
>   %I  inodes in percent
>   %a  AVAIL
>   %A  AVAIL in percent
>   %u  unused
>   %U  unused percentage
>   %t  total size
>   %T  FSTYPE
>   %s  SOURCE
>   %m  TARGET (mount point)
>   ...
> 
>   df --format="%u:%i:%T:%m"
> 
> And some directives could have mixed SIZE modifiers, e.g.
> 
>   %{SIZE}u	used blocks with SIZE like KMGTPEZY.
>   %{SIZE}i      inode number
> 
>   df --format="%Tt %Gu %Ki %m"

T overlaps, but I see what you mean.

> Scripts could parse the output of --format (or --printf) much
> safer (SOURCE and TARGET can include almost any characters like
> '\n', '\t', etc. but never e.g. NULL)

They can't actually. mbsalign replaced non printable chars
in all but the last field, and there was a patch last week
to replace control chars in the last field with '?'

Would you still want to apply mbsalign to all fields
but the last when using a specific format like this?

>   df --printf="%U\0%s\0%m\0\n"
> 
> As already said, this would be a greater change in df.c,
> but some code could surely be shared with stat.c and maybe
> in future with "ls --format=..." ;-)
> 
> I'm not against --output, but the advantage of a more
> flexible --printf is unbeatable IMO.

60:40 for --output as ordering/selection is needed by some
40:60 against --printf as detailed formatting is neede by few

cheers,
Pádraig.

Message #47 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Fri, 27 Jul 2012 09:00:08 +0200

On 07/26/2012 06:11 PM, Pádraig Brady wrote:
> On 07/26/2012 04:43 PM, Bernhard Voelker wrote:
>> On 07/26/2012 04:23 PM, Pádraig Brady wrote:

>>> So a full --output list supported by df could be
>>> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT

Today, there's no FREEPCT, but USEDPCT.
I'd leave that.


> Oh right the last 4 items above should also have I... variants
> to cater for inodes.

What about ISIZE, IUSED, IAVAIL and IUSEDPCT?


>> We could for the first time have blocks and inodes statistics
>> in one command:
> 
> Good point, but that could be allowed too with --output

Right.

>> And some directives could have mixed SIZE modifiers, e.g.
>>
>>   %{SIZE}u	used blocks with SIZE like KMGTPEZY.
>>   %{SIZE}i      inode number
>>
>>   df --format="%Tt %Gu %Ki %m"
> 
> T overlaps, but I see what you mean.

The SIZE could be in {}, e.g. "%{T}t".

How could we do this with --ouput?
Maybe something like:

  df --output=SIZE/M,IFREE/K,USED/1024,TARGET

> Would you still want to apply mbsalign to all fields
> but the last when using a specific format like this?

No, the idea was to create format specifiers for that like
e.g. "%-FIELD" (left-aligned) and "%+FIELD" (right-aligned),
and to have the traditional formats be a certain combination
of it.

This would need a lot of checking ... e.g. if a format string
contained a '+' or a '-', then what should happen with the
other fields? Error? Default alignment per field? Centered?
... --format is more flexible and much more complex.

> 60:40 for --output as ordering/selection is needed by some
> 40:60 against --printf as detailed formatting is neede by few

You see, I'm still jumping between --output and --format, now
also 60:40 pro --output.

What do the others think?

Have a nice day,
Berny

Message #50 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Fri, 27 Jul 2012 09:41:11 +0100

On 07/27/2012 08:00 AM, Bernhard Voelker wrote:
> On 07/26/2012 06:11 PM, Pádraig Brady wrote:
>> On 07/26/2012 04:43 PM, Bernhard Voelker wrote:
>>> On 07/26/2012 04:23 PM, Pádraig Brady wrote:
> 
>>>> So a full --output list supported by df could be
>>>> FSTYPE,SOURCE,TARGET,SIZE,USED,AVAIL,FREEPCT
> 
> Today, there's no FREEPCT, but USEDPCT.
> I'd leave that.

Oops, right :)

>> Oh right the last 4 items above should also have I... variants
>> to cater for inodes.
> 
> What about ISIZE, IUSED, IAVAIL and IUSEDPCT?

Yes, that's what I was thinking.

>>> We could for the first time have blocks and inodes statistics
>>> in one command:
>>
>> Good point, but that could be allowed too with --output
> 
> Right.
> 
>>> And some directives could have mixed SIZE modifiers, e.g.
>>>
>>>   %{SIZE}u	used blocks with SIZE like KMGTPEZY.
>>>   %{SIZE}i      inode number
>>>
>>>   df --format="%Tt %Gu %Ki %m"
>>
>> T overlaps, but I see what you mean.
> 
> The SIZE could be in {}, e.g. "%{T}t".
> 
> How could we do this with --ouput?
> Maybe something like:
> 
>   df --output=SIZE/M,IFREE/K,USED/1024,TARGET

Too much control I think.
Probably best leave the units globally controlled by -B and -h.

> 
>> Would you still want to apply mbsalign to all fields
>> but the last when using a specific format like this?
> 
> No, the idea was to create format specifiers for that like
> e.g. "%-FIELD" (left-aligned) and "%+FIELD" (right-aligned),
> and to have the traditional formats be a certain combination
> of it.
> 
> This would need a lot of checking ... e.g. if a format string
> contained a '+' or a '-', then what should happen with the
> other fields? Error? Default alignment per field? Centered?
> ... --format is more flexible and much more complex.

>> 60:40 for --output as ordering/selection is needed by some
>> 40:60 against --printf as detailed formatting is needed by few
> 
> You see, I'm still jumping between --output and --format, now
> also 60:40 pro --output.

Marginal decisions like this are awkward.
Thanks for taking the time to present possible options.

> 
> What do the others think?
> 
> Have a nice day,
> Berny
> 

cheers,
Pádraig.

Message #53 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Bernhard Voelker <mail <at> bernhard-voelker.de>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard to
	read
Date: Fri, 27 Jul 2012 14:04:25 +0200

Pádraig Brady wrote:
...
>>   df --printf="%U\0%s\0%m\0\n"
>>
>> As already said, this would be a greater change in df.c,
>> but some code could surely be shared with stat.c and maybe
>> in future with "ls --format=..." ;-)
>>
>> I'm not against --output, but the advantage of a more
>> flexible --printf is unbeatable IMO.
>
> 60:40 for --output as ordering/selection is needed by some
> 40:60 against --printf as detailed formatting is neede by few

At first I was going to say I'm 50:50,
but as I wrote, the balance tipped in favor of --output,
maybe even to 70:30.

A big factor for me was that here we want a column-selecting
option, rather than a true printf-like format-specifying option.
Of course we could augment the format-specifying option with
semantics that delimit columns and that allow us to specify
alternate formatting/units per column, but that would be something
new.  The simpler column-selecting facility (like that of say, ps)
seems attractive.

While added flexibility of --printf=FMT would be nice, it seems like it
would come at a price (more code and more complexity), and as Pádraig
says, in df the feature might not be used enough to justify the expense.
A point in --printf's favor is consistency with stat's option name and
the someday-in-ls option name.  I prefer --printf over --format because
in stat, --format always evokes a trailing newline.

However, it is hard to judge without seeing the actual changes.
If you feel strongly about it, go ahead and implement your preference.
Maybe the resulting code will be small and clean enough that the added
flexibility will be an obvious net gain.

Message #56 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jim Meyering <jim <at> meyering.net>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Pádraig Brady <P <at> draigBrady.com>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>,
	jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Fri, 27 Jul 2012 14:27:52 +0200

On 07/27/2012 02:04 PM, Jim Meyering wrote:
> However, it is hard to judge without seeing the actual changes.
> If you feel strongly about it, go ahead and implement your preference.
> Maybe the resulting code will be small and clean enough that the added
> flexibility will be an obvious net gain.

I'll try ... but it will take some time.
Thanks.

Have a nice day,
Berny

Message #59 received at 10915 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: "10915 <at> debbugs.gnu.org" <10915 <at> debbugs.gnu.org>,
	Jim Meyering <jim <at> meyering.net>, jaalto <jari.aalto <at> cante.net>
Subject: Re: bug#10915: 8.13: df -- overly long output lines are very hard
	to read
Date: Fri, 09 Nov 2012 10:12:04 +0000

unarchive 10915
close 10915
stop

On 07/27/2012 01:27 PM, Bernhard Voelker wrote:
> On 07/27/2012 02:04 PM, Jim Meyering wrote:
>> However, it is hard to judge without seeing the actual changes.
>> If you feel strongly about it, go ahead and implement your preference.
>> Maybe the resulting code will be small and clean enough that the added
>> flexibility will be an obvious net gain.
>
> I'll try ... but it will take some time.

Bernhard has addressed this with:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=dae8d22
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=ae3c2b4
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e73bb23

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.