Date: Tue, 3 Jun 2014 10:43:01 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r266985 - head/sys/ddb Message-ID: <20140603174301.GA31367@funkthat.com> In-Reply-To: <20140603193401.W1018@besplex.bde.org> References: <201406022350.s52NoJe1096873@svn.freebsd.org> <20140603193401.W1018@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140603174301.GA31367>