From owner-freebsd-hackers Wed May 21 21:44:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA00369 for hackers-outgoing; Wed, 21 May 1997 21:44:46 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA00360 for ; Wed, 21 May 1997 21:44:40 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id OAA01982 for freebsd-hackers@freebsd.org; Thu, 22 May 1997 14:44:33 +1000 Received: from localhost.devetir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id OAA05825 for ; Thu, 22 May 1997 14:44:02 +1000 (EST) Message-Id: <199705220444.OAA05825@ogre.dtir.qld.gov.au> To: freebsd-hackers@freebsd.org Subject: Re: Slight problems after upgrade 2.2.1 -> 2.2.2 References: <3.0.1.32.19970521205601.00cfd590@mail.nacamar.de> <19970521220115.OG57138@uriah.heep.sax.de> In-Reply-To: <19970521220115.OG57138@uriah.heep.sax.de> from J Wunsch at "Wed, 21 May 1997 20:01:15 +0000" Date: Thu, 22 May 1997 14:44:02 +1000 From: Stephen McKay Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wednesday, 21st May 1997, J Wunsch wrote: >As Michael Beckmann wrote: > >> following an upgrade from 2.2.1 to 2.2.2, I have observed a minor problem >> with the top utility. It truncates the the processes to 6 characters: > >That's because it has been prepared for eventually upcoming support of >16-char usernames. (It's already been in -current for some time now.) "prepared"? I think "accidentally included from -current" is more accurate. I've just recompiled with rev 1.2 of usr.bin/top/machine.c and I'm much happier now. >The better way would be to dynamically calculate the required size. I agree, but how dynamically? Should each screen refresh recalculate positions (leading to stuff jumping left and right all the time), or just once per startup (leading to lots of wasted space if really_long_user is not logged in)? I'm tempted to put the username just left of the command field, and let it be dynamic per screen update. Has anyone contacted the author of top? >We finally adopted top as part of the base system. It's been an essential system tool since the late 80's! It just used most of your cpu cycles back then... Stephen.