From owner-svn-src-head@FreeBSD.ORG Tue Jun 3 17:43:04 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 407A111C; Tue, 3 Jun 2014 17:43:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13D932411; Tue, 3 Jun 2014 17:43:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s53Hh1o9042819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2014 10:43:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s53Hh1Rl042818; Tue, 3 Jun 2014 10:43:01 -0700 (PDT) (envelope-from jmg) Date: Tue, 3 Jun 2014 10:43:01 -0700 From: John-Mark Gurney To: Bruce Evans Subject: Re: svn commit: r266985 - head/sys/ddb Message-ID: <20140603174301.GA31367@funkthat.com> References: <201406022350.s52NoJe1096873@svn.freebsd.org> <20140603193401.W1018@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140603193401.W1018@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 03 Jun 2014 10:43:02 -0700 (PDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:43:04 -0000 Bruce Evans wrote this message on Tue, Jun 03, 2014 at 21:11 +1000: > On Mon, 2 Jun 2014, John-Mark Gurney wrote: > > >Log: > > handle longer commands so that lines don't overflow... people who added > > commands forgot to check this... > > Please fix the sticky "." key on your keyboard. It keeps repeating > spuriously. Also the shift key. > > The correct fix is to remove or rename the long commands. I agree, and once that has been fixed, we can change this back, but like vmstat 1, it's anoying when things overflow/wrap incorrectly... > 12 is already too long. Who wants to type 11-15 character command > names? It would be better to punish long command name[r]s using > "%-11.11s " format (with complications to avoid the trailing space(s) > in the last column). This punishment is not very severe since command > names should be unique in the first character or 2. This is needed > anyway, to avoid typing long command names. The command name parser > supports this by matching the name typed with a possibly-longer name > in the table. But then we'll have to add logic to make sure that what ever we truncate to, that they are unique, and as this width isn't a magic number, it'll be hard... Also, the feature of being able to type only partial command names is undocumented in ddb(4), so, expecting people to know this is surprising... Anyone wanting to submit patches to ddb(4), I'll review and commit... > Expanding to 16 adds the following bugs: > - reduction in the number of fields on an 80 column terminal from 6 or 7 > to 4 or 5 (from 6 * 12 + 7 or 8 left over depending on auto-wrap to > 4 * 16 + 15 or 16 left over) Yeh, it looks like autowrap isn't happening as I thought it was, and 16 is too large, and 15 would have been better to keep it at 5 columns, as countfreebufs only needs 13 characters... Once I have verified this I'll back down the width to 15... Though this is probably related to the fact that using column 80 can have issues depending if the terminal auto-continues to the next line or not, where if you unconditionally include a new line, it will then add a blank line instead of putting you back to the start... > - different mishandling of autowrap. In -current, the handling seems to > be to always waste the last 16 columns (previously only 8). This > avoids problems with auto-wrap, but the change makes it waste many > more columns. The number of fields is now 4 (was 6). 6 * 13 would > fit just as well as 6 * 12 (except for terminals with between 73 and > 78 columns). The formatting now works as follows: > The db_end_line()'s are not correctly paired with the db_printf()'s, > but they work. There is none before the first db_printf(), but callers > should arrange to start on a new line so there is no danger of > overruning the line before db_end_line() can check for overrun. Then > each db_end_line() except the last one (dynamically) is correctly paired > with the next db_printf(). Then the last db_end_line() checks for > output that will never be done. It may print a newline prematurely. > Perhaps an extra newline is printed to complete the table. This is > unclear because db_cmd_list() doesn't print one itself. I think > the prompt code _expects_ to be called with the previous line not > always terminated, and prints a newline iff necessary. > It used to give 7 fields of width 12 that were somehow usually > displayed nicely in 80 columns on a syscons terminal, depending > on whether the 12 characters printed in the 7 available columns > for the last field had enough trailing spaces. The trailing spaces > were apparently discarded by terminal magic on some terminals. But > command names of length exactly 8 gave auto-wrap problems, and ones > of length 9-12 were displayed in full and ran into the next line iff > they were in the 7th field. Command names of length 12 of course > ran into each other in any field except the last one. > > Since command namers usually get things like this wrong, short names > should be enforced by panicing for long ones. I once fixed all sleep > message strings to fit in the available 6 characters, but neglected > to enforce this, so there are many more broken ones now. This bug is > now most common in the zfs and audit subsystems. From top output: [deleted comment about wait states as unrelated to my commit] -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."