GNU bug report logs -
#20442
bug+patch: du output misaligned on different terminals
Previous Next
Reported by: "L. A. Walsh" <coreutils <at> tlinx.org>
Date: Mon, 27 Apr 2015 19:12:01 UTC
Severity: normal
Tags: wontfix
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
>
This bug report was last modified 6 years and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.