bug#20442: bug+patch: du output misaligned on different terminals

[Linda Walsh]

reopen 20442
thanks
=======

Your more general case doesn't work:

> du -sh /tmp/t*|numfmt --format %10f
numfmt: rejecting suffix in input: ‘4.0K’ (consider using --from)
> du -sh --time /tmp/t*|numfmt --format %10f
numfmt: rejecting suffix in input: ‘4.0K’ (consider using --from)


I usually use other arguments with 'du'.  Your external tool solution
doesn't handle the general case of "du's" output.

The point was to correct 'du's output, not find a *custom* solution
to correct assumptions made by 'du'.

Why would you reject something that fixes this problem?

Are you proposing to remove the special tab-handling 
in 'dir', 'ls', 'cat', 'expand', 'pr', 'unexpand', 'vdir'
among many other cmdline utils?

Relying on hard-coded constants is usually considered poor
programming practice.

In this case, you are relying on all terminals/output devices 
conforming to a fixed  value that you deem correct.
Is there a benefit to choosing an inferior design that
doesn't work across different terminal sizes?

The patch resolves the problem and works on all terminals.



Pádraig Brady wrote:
> tag 20442 wontfix
> close 20442
> stop
>
> On 27/04/15 20:11, L. A. Walsh wrote:
> > This is a fix/work-around for (RFE#19849 (bug#19849) which was 
> > about addingg options to expand tabs and/or set a tabsize
> > for output from 'du' so output would line up as intended.
> >
> > Without that enhancement, the current output is "messed
> > up" on terminals/consoles that don't use hard-coded-constant
> > widths for tabs (like many or most of the Xterm & linux
> > consoles).
> >
> > Adding the switches is more work than I want to chew
> > off right now, but the misaligned output made for difficult
> > reading (besides looking bad), especially w/a monospace font
> > where it is clear that the columns were meant to lineup.
> > So I threw together a quick patch against the current 
> > git source (changes limited to 'du.c').
> >
> > If someone would look it over, try it, or such and apply it
> > to the current coreutils source tree (it's in patch form
> > against 'src/du.c') for some soon future release, (at least
> > until such time as the above mentioned RFE can be addressed).
> >
> > 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 
> > The current du output (example from my tmp dir) on a
> > term w/o hard-coded-constant expansion looks like:
> >
> > Ishtar:tools/coreutils/work/src> /usr/bin/du /tmp/t*
> > 4 /tmp/t
> > 1160  /tmp/t1
> > 680 /tmp/t2
> > 4 /tmp/tab2.patch
> > 20  /tmp/tabs
> > 4 /tmp/tmpf
> > 4 /tmp/topcmds
> > 24  /tmp/topcmds-hlps
> > 24  /tmp/topcmds2
> > 8 /tmp/topcmds2.txt
> > 4 /tmp/tq1
> > 32  /tmp/tt
> > 32  /tmp/tt
>
> In fairness, this is with the unusual case after running `tabs 2`
>
> > *Without* the assumption of hard-coded or fixed tabs (using 
> > a 8-spaces/tab as seems to be the implementors assumption /
> > intention), the output columns, again, line-up vertically:
> >
> > Ishtar:tools/coreutils/work/src> ./du /tmp/t*       
> > 4       /tmp/t
> > 1160    /tmp/t1
> > 680     /tmp/t2
> > 4       /tmp/tab2.patch
> > 20      /tmp/tabs
> > 4       /tmp/tmpf
> > 4       /tmp/topcmds
> > 24      /tmp/topcmds-hlps
> > 24      /tmp/topcmds2
> > 8       /tmp/topcmds2.txt
> > 4       /tmp/tq1
> > 32      /tmp/tt
> >
> >
> > While not addressing the RFE, at least the original output format
> > should look the same on all terminals
>
> Thanks for the patch, however the same could be achieved
> more generally with external tools. For example numbers are
> better for human consumption when right aligned, so you
> could achieve both with:
>
>   du | numfmt --format %10f
>
> cheers,
> Pádraig.