Re: Strange top(1) output

M. Warner Losh wrote:
> In message: <E1DWDNe-0005AE-3p_at_cs1.cs.huji.ac.il>
>             Danny Braniss <danny_at_cs.huji.ac.il> writes:
> : maybe the time has come to drop the 80 col. limit? it's been around for more
> : that 100 years, and screens (most of them) can be streched :-)
> 
> Not on the console.  The real bug is that it is hardwired to 80 and
> not the width of the terminal...

It makes sense that top would start with a minimally capable 80x24 ANSI 
terminal which only needs to know enough to clear the screen.  Supporting wider 
terminals strikes me as a fine idea, too, only I think this capability is 
already present...?

 From the related thread in -stable:

Matthias Buelow wrote:
> Kevin Oberman wrote:
>> top(1) could check the width of the display and tailor the display to
>> that width. May screen based tools already do this and it provides a lot
>> of flexibility. It's best to check the width for width on every update
>> so that the screen (if its a soft terminal) may be increased and the
>> display re-written to take advantage of that, on the fly.
> 
> Errm.. it is doing that already, doesn't it?
> 
> I can definitely resize the xterm and it adjusts itself to the new
> width, only the command name is clipped after a certain length (so
> there's a maximum length it would display).

...and I can confirm this.  If you resize a terminal while running top, it will 
display wider than 80-columns now.  The uptime and clock in the upper right 
corner stays right-justified if you resize, and the command column grows too, 
but is clipped.

BTW, Kevin, you don't need to recheck the terminal size with every redraw, 
although for something which only updates once a second by default, that would 
work OK.  However, if you register a signal handler for SIGWINCH, you can be 
notified when the terminal size changes and only adjust the layout when you 
actually need to.

	-----

Since Giorgos is the one who seems to be the closest to actively writing code, 
and has asked for feedback, well, I think his suggested layout is an 
improvement, and I agree with these:

   + The entire header line is limited to the window width too.
   + The USERNAME column is hard-limited to 8 characters.
   + The CPU/WCPU columns occupy the same space and can be toggled with
     the 'C' keyboard command.
   + When UID numbers are displayed, hitting 'u' will read a UID instead
     of a username.

The only thing I *don't* like is splatting the # of threads onto the end of the 
process name, seperated by a slash: that makes it remarkably hard to read.

I'd be happier with a "#TH" column, and limiting the # of threads to displayed 
to 999 or "+++", or some such.  If we need to drop a column, I'd much rather 
drop the "NICE" column and have a "#TH" column instead.  Or if we want to 
display more of the COMMAND, I'd rather drop both, and not display # threads at 
all.  Most processes have one thread, although that seems to vary by workload 
(ie, if you run lots of Java stuff), more than by platform.

-- 
-Chuck

PS: I disagree with whoever suggested removing the RES column; when I run top, 
I normally sort either my TIME or by RES (aka RSS or RPRVT).  Having the order 
of processes flicker around as transient CPU workload shifts I find less 
helpful then seeing which are consuming resources over the lifespan of the process.

PSS: At one point, I recall that top was staticly linked and had no required 
dependencies, not even on termcap, but that was a while ago.  The top that 
comes with FreeBSD now seems to be dynamicly linked against ncurses, and the 
current behavior suggests that it is using curses windows for drawing.

(Which is fine, curses does a lot of hard work that I'm just as happy to let it 
figure out.)