When iostat outputs CPU usage values, columns are too narrow to accomodate 100%. For example: tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 68 103 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 319 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 Making it both slightly confusing to read, and a nightmare to accurately text process. Fix: Simple reformatting. Diff available from http://decoder.geek.sh/iostat.aragon.diff and also follows below :
On Wed, 14 Aug 2002, Aragon Gouveia wrote: > >Description: > When iostat outputs CPU usage values, columns are too narrow to accomodate 100%. For example: > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 68 103 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 > 0 319 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 > > Making it both slightly confusing to read, and a nightmare to accurately text process. > > >How-To-Repeat: > > >Fix: > Simple reformatting. Diff available from http://decoder.geek.sh/iostat.aragon.diff and also follows below : > > > --- iostat.c Thu Jul 19 06:15:42 2001 > +++ iostat.c.new Thu Aug 15 01:43:07 2002 > @@ -551,7 +551,7 @@ > } > } > if ((dflag == 0) || (Cflag > 0)) > - (void)printf(" cpu\n"); > + (void)printf(" cpu\n"); > else > (void)printf("\n"); > > @@ -576,7 +576,7 @@ > } > } > if ((dflag == 0) || (Cflag > 0)) > - (void)printf(" us ni sy in id\n"); > + (void)printf(" us ni sy in id\n"); > else > printf("\n"); > > @@ -674,6 +674,6 @@ > for (state = 0; state < CPUSTATES; ++state) > time += cur.cp_time[state]; > for (state = 0; state < CPUSTATES; ++state) > - printf("%3.0f", > + printf("%6.1f", > 100. * cur.cp_time[state] / (time ? time : 1)); > } This makes it a nightmare to read on 80-column terminals. The number of devices shown by default would have to be reduced from 3 to only 2 to reduce the line length to less than 80 columns again. Printing more precision might confuse parsers that expect plain integers, especially if they know that the integers are formatted in 3 characters, as they probably have to do to parse the run together digits. Bruce
| By Bruce Evans <bde@zeta.org.au> | [ 2002-08-15 10:37 +0200 ] > This makes it a nightmare to read on 80-column terminals. The number of > devices shown by default would have to be reduced from 3 to only 2 to > reduce the line length to less than 80 columns again. > > Printing more precision might confuse parsers that expect plain integers, > especially if they know that the integers are formatted in 3 characters, > as they probably have to do to parse the run together digits. Ok understandable. I think the column spacing should atleast be increased a notch to accomodate "100" without overlapping with a value next to it. I didn't intend to include the precision change in my diff - that kinda slipped in by accident because I use it. I don't think it's necessary either, but would be a nice option to enable on the command line. Will %4.0f still be too big for 80 column terms? Thanks, Aragon
On Thu, 15 Aug 2002, Aragon Gouveia wrote: > | By Bruce Evans <bde@zeta.org.au> > | [ 2002-08-15 10:37 +0200 ] > > This makes it a nightmare to read on 80-column terminals. The number of > > devices shown by default would have to be reduced from 3 to only 2 to > > reduce the line length to less than 80 columns again. > > > > Printing more precision might confuse parsers that expect plain integers, > > especially if they know that the integers are formatted in 3 characters, > > as they probably have to do to parse the run together digits. > > Ok understandable. I think the column spacing should atleast be increased a > notch to accomodate "100" without overlapping with a value next to it. > > I didn't intend to include the precision change in my diff - that kinda > slipped in by accident because I use it. I don't think it's necessary > either, but would be a nice option to enable on the command line. > > Will %4.0f still be too big for 80 column terms? It takes 80 exactly, which is 1 too many after line wrap. I suggest using almost the same method as in vmstat: " %2.0f" always leaves a space and usually has the same effect as "%3.0f". (vmstat uses "%2.0f " except for the last field it uses "%2.0f".) %%% Index: iostat.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/iostat/iostat.c,v retrieving revision 1.23 diff -u -2 -r1.23 iostat.c --- iostat.c 26 Sep 2001 19:35:03 -0000 1.23 +++ iostat.c 15 Aug 2002 17:55:10 -0000 @@ -727,5 +728,5 @@ time += cur.cp_time[state]; for (state = 0; state < CPUSTATES; ++state) - printf("%3.0f", + printf(" %2.0f", rint(100. * cur.cp_time[state] / (time ? time : 1))); } %%% Bruce
Perfect. :) | By Bruce Evans <bde@zeta.org.au> | [ 2002-08-15 20:02 +0200 ] > On Thu, 15 Aug 2002, Aragon Gouveia wrote: > > > | By Bruce Evans <bde@zeta.org.au> > > | [ 2002-08-15 10:37 +0200 ] > > > This makes it a nightmare to read on 80-column terminals. The number of > > > devices shown by default would have to be reduced from 3 to only 2 to > > > reduce the line length to less than 80 columns again. > > > > > > Printing more precision might confuse parsers that expect plain integers, > > > especially if they know that the integers are formatted in 3 characters, > > > as they probably have to do to parse the run together digits. > > > > Ok understandable. I think the column spacing should atleast be increased a > > notch to accomodate "100" without overlapping with a value next to it. > > > > I didn't intend to include the precision change in my diff - that kinda > > slipped in by accident because I use it. I don't think it's necessary > > either, but would be a nice option to enable on the command line. > > > > Will %4.0f still be too big for 80 column terms? > > It takes 80 exactly, which is 1 too many after line wrap. I suggest using > almost the same method as in vmstat: " %2.0f" always leaves a space and > usually has the same effect as "%3.0f". (vmstat uses "%2.0f " except for > the last field it uses "%2.0f".) > > %%% > Index: iostat.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/iostat/iostat.c,v > retrieving revision 1.23 > diff -u -2 -r1.23 iostat.c > --- iostat.c 26 Sep 2001 19:35:03 -0000 1.23 > +++ iostat.c 15 Aug 2002 17:55:10 -0000 > @@ -727,5 +728,5 @@ > time += cur.cp_time[state]; > for (state = 0; state < CPUSTATES; ++state) > - printf("%3.0f", > + printf(" %2.0f", > rint(100. * cur.cp_time[state] / (time ? time : 1))); > } > %%% > > Bruce >
On Thu, 15 Aug 2002, Aragon Gouveia wrote: > Perfect. :) > > Index: iostat.c > > ... > > - printf("%3.0f", > > + printf(" %2.0f", OK; I will commit this version. Bruce
Responsible Changed From-To: freebsd-bugs->ken Assign to iostat maintainer
Responsible Changed From-To: ken->freebsd-bugs With permission, reassign away from inactive committer.
this problem should no longer occur since all cpu fields (us, ni, sy, in and id) are now only " %2.0f" wide. this fix got committed by bde@ in 2002 with r102068. ;) it's in all branches >= stable4. -- Alexander Best
This is fixed in 8.0 for me. I'm sure this can be closed. :) Thanks
State Changed From-To: open->closed Apparently this can be closed, make this happen :)