From owner-freebsd-current@FreeBSD.ORG Fri May 13 09:42:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30AEE16A4CE; Fri, 13 May 2005 09:42:06 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8137143D5A; Fri, 13 May 2005 09:42:05 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id BBBAE5D17; Fri, 13 May 2005 05:42:04 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57482-01; Fri, 13 May 2005 05:42:03 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) by pi.codefab.com (Postfix) with ESMTP id 5635F5CBB; Fri, 13 May 2005 05:42:02 -0400 (EDT) Message-ID: <42847665.4030803@mac.com> Date: Fri, 13 May 2005 05:41:57 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050512.220006.124086156.imp@bsdimp.com> In-Reply-To: <20050512.220006.124086156.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@FreeBSD.org cc: Matthias Buelow cc: Giorgos Keramidas Subject: Re: Strange top(1) output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 09:42:06 -0000 M. Warner Losh wrote: > In message: > Danny Braniss 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.)