GNU bug report logs - #20442
bug+patch: du output misaligned on different terminals

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 20442 in the body.
You can then email your comments to 20442 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: "L. A. Walsh" <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: bug+patch: du output misaligned on different terminals
Date: Mon, 27 Apr 2015 12:11:22 -0700

[Message part 1 (text/plain, inline)]

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

*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,
Linda Walsh

(FWIW - the patch may be used under the same license as the rest
of 'du.c').

[du_Xpandtab.patch (text/plain, inline)]

--- src/du.c	2015-04-01 17:31:02.000000000 -0700
+++ src/du.c	2015-04-26 16:16:43.829602843 -0700
@@ -1,3 +1,4 @@
+
 /* du -- summarize disk usage
    Copyright (C) 1988-2015 Free Software Foundation, Inc.
 
@@ -370,52 +371,86 @@
 
 /* FIXME: this code is nearly identical to code in date.c  */
 /* Display the date and time in WHEN according to the format specified
-   in FORMAT.  */
+   in FORMAT.
+   Note modificatino to return # of chars (exclusive of NUL)  */
 
-static void
+static int
 show_date (const char *format, struct timespec when)
 {
   struct tm *tm = localtime (&when.tv_sec);
+  int slen = 0;
   if (! tm)
     {
       char buf[INT_BUFSIZE_BOUND (intmax_t)];
       char *when_str = timetostr (when.tv_sec, buf);
       error (0, 0, _("time %s is out of range"), when_str);
+      slen=strlen(when_str);
       fputs (when_str, stdout);
-      return;
+      return slen;
     }
 
-  fprintftime (stdout, format, tm, 0, when.tv_nsec);
+  slen += fprintftime (stdout, format, tm, 0, when.tv_nsec);
+  return slen;
 }
 
 /* Print N_BYTES.  Convert it to a readable value before printing.  */
 
-static void
+static int
 print_only_size (uintmax_t n_bytes)
 {
   char buf[LONGEST_HUMAN_READABLE + 1];
-  fputs ((n_bytes == UINTMAX_MAX
+	char * outp;
+  fputs (outp = ((n_bytes == UINTMAX_MAX
           ? _("Infinity")
           : human_readable (n_bytes, buf, human_output_opts,
-                            1, output_block_size)),
+                            1, output_block_size))),
          stdout);
+	return strlen(outp);
+}
+
+
+/* using buf of len 'n', return a nul-term. string w/# spaces to ins for tab.
+ * If tabsize is 0, a 0-len string will be returned.
+ */
+
+static char *
+tabnspaces(char * buf, int n, int cur_output_len, int tabsize)
+{
+  char * obuf = buf;
+  int spaces =  tabsize ? tabsize - (cur_output_len % tabsize) : 0;
+
+  if (!n) return NULL;
+
+  /* pre-dec 'n' to reserve space for nul */
+  while(--n > 0  &&  spaces-- > 0) *obuf++ = ' ';
+  *obuf = '\0';
+  return buf;
 }
 
 /* Print size (and optionally time) indicated by *PDUI, followed by STRING.  */
 
+int term_tabsize = 8; /* default for now */
+
 static void
 print_size (const struct duinfo *pdui, const char *string)
 {
-  print_only_size (opt_inodes
-                   ? pdui->inodes
-                   : pdui->size);
+	int print_len = print_only_size (opt_inodes
+                                   ? pdui->inodes
+                                   : pdui->size);
+  char Xtab[1024];  /* Xpanded tab */
+  char * myspaces;
 
   if (opt_time)
     {
-      putchar ('\t');
-      show_date (time_format, pdui->tmax);
+  		myspaces = tabnspaces(Xtab, sizeof(Xtab), print_len, term_tabsize);
+			print_len+=strlen(myspaces);
+      fputs (myspaces, stdout);
+      print_len+= show_date (time_format, pdui->tmax);
     }
-  printf ("\t%s%c", string, opt_nul_terminate_output ? '\0' : '\n');
+ 
+  myspaces = tabnspaces(Xtab, sizeof(Xtab), print_len, term_tabsize);
+  fputs(myspaces, stdout);
+  printf ("%s%c", string, opt_nul_terminate_output ? '\0' : '\n');
   fflush (stdout);
 }
 

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

From: Pádraig Brady <P <at> draigBrady.com>
To: "L. A. Walsh" <coreutils <at> tlinx.org>, 20442 <at> debbugs.gnu.org
Subject: Re: bug#20442: bug+patch: du output misaligned on different terminals
Date: Tue, 28 Apr 2015 00:40:10 +0100

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.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>, 20442 <at> debbugs.gnu.org
Subject: Re: bug#20442: bug+patch: du output misaligned on different terminals
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.
> 

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>, 20442 <at> debbugs.gnu.org
Subject: Re: bug#20442: bug+patch: du output misaligned on different terminals
Date: Tue, 28 Apr 2015 01:28:47 +0100

On 28/04/15 01:13, Linda Walsh wrote:
> 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)

You can use:

  du -h --time | numfmt --from=iec --to=iec --format %10f

Though more naturally you can use:

  du -B1 --time | numfmt --to=iec --format %10f

Since these are formatting for human consumption,
there are varying preferences etc, and so
(variants of) the above are appropriate for aliases,
or shell functions if accepting parameters.

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

There are backwards compatibility issues to consider.

cheers,
Pádraig.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Eric Blake <eblake <at> redhat.com>, 20442 <at> debbugs.gnu.org
Subject: Re: bug#20442: bug+patch: du output misaligned on different terminals
Date: Wed, 13 May 2015 14:36:18 -0700

Pádraig Brady wrote: > There are backwards compatibility issues to
consider.

Could you demonstrate any where similar issues wouldn't affect output
from 'ls'

Second, I don't remember numfmt being part being part of posix, but my
solution seems to fall under POSIX:



From: 	Pádraig Brady 
Subject: 	Re: du: POSIX mandating a single space instead of tab?  
Date: 	Tue, 28 Apr 2015 16:51:06 +0100 
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 28/04/15 15:42, Eric Blake wrote:

>>> No, the space stands for any (positive) amount of white space.  
>>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
>>> Andreas.
>>
>> Thanks for pointing that out Andreas.  
>> So a ' ' in a format implies any amount of blank chars.
> 
> Correct.  
> 

>> So we could separate the du columns with spaces rather than tab,

> 
> Yes, I'd prefer that we did that.  It is much easier to guarantee
> alignment when using spaces and completely avoiding whatever tab stops
> people have set up.

=====

I find myself agreeing with Eric on this issue.

Actually, I would prefer a envvar USE_TABS=[[ytfnx]] (yes true
false/no/false/no/expand) and their upper-case versions for simplicity
as defaulting to 8 space/tab -- though I could also support the absence
of 'USE_TABS' as being compatible with current functionality.

I can see the use of something like this in desktop programs tty/consoles,
editors, etc...


I would want to see standard column terminology (ala sort & cut ranging
from 1 - 80).


If the var is undefined, I think it would be _more_ _predictable_ to go go with
expanded as '8', OR with like the tty_tabs command w/no args: it shows
you the current settings.  (Why doesn't 'tabs' show them?)

However -- it we agree on the env-var for tab presence/expansion and tabstop
definitions, I could also agree on leaving behaviors in current programs the
same as they are now (w/o the USE_TABS envvar).

> tabs

tabs: no tab-list given  --- hmmm not too useful

> tabs 2 -- also tabs doesn't take columns but spaces of separation.
Tabstops are usually at set points like 1/2" or 1/4" or some fixed
number, so if I use tabs 2:, One might like 'tabs' to display the
current tabs: > tty_tab

(from 1, tabs skip to column: 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79
80 

I note the tab program also supports irregular tabs:

for i in a a2 c c2 c3 f p s u;do tabs -$i tty_tab done
                                                                      
(from 1, tabs skip to column: 10 16 36 72 80 
                                                                      
(from 1, tabs skip to column: 10 16 40 72 80 
                                                     
(from 1, tabs skip to column: 8 20 55 80 
                                               
(from 1, tabs skip to column: 6 10 14 49 80 
                                                                 
(from 1, tabs skip to column: 6 10 22 26 30 34 38 42 46 50 54 58 62 67 80 
                     
(from 1, tabs skip to column: 7 11 15 19 23 80 
                                                           
(from 1, tabs skip to column: 5 9 13 17 21 25 29 33 37 49 53 80 
                                                     
(from 1, tabs skip to column: 10 55 80 
                                          
(from 1, tabs skip to column: 12 20 44 80 

-----------------

I would like to see this in an ENV var so people could use it for
other utils in their session (like vim/emacs or whatever).

Some files like the /etc/fstab file really need variable tabs.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 20442 <at> debbugs.gnu.org
Subject: Re: bug#20442: bug+patch: du output misaligned on different terminals
Date: Mon, 22 Oct 2018 20:18:05 -0600

tags 20442 wontfix
close 20442
stop

(triaging old bugs)


With not further comments in 3 years
(and previous decisions to not fix),
I'm closing this bug.

regards,
 - assaf

Previous Next

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