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

From: Linda Walsh <[email-masked]>
Date: Mon, 27 Apr 2015 17:13:33 -0700

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