Date: Wed, 4 Jun 2014 04:58:46 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John-Mark Gurney <jmg@funkthat.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r266985 - head/sys/ddb Message-ID: <20140604034825.D3520@besplex.bde.org> In-Reply-To: <20140603174301.GA31367@funkthat.com> References: <201406022350.s52NoJe1096873@svn.freebsd.org> <20140603193401.W1018@besplex.bde.org> <20140603174301.GA31367@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Jun 2014, John-Mark Gurney wrote: > 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... > ... >> 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... The list of commands is mainly a hint. Doesn't matter much if the names are truncated. (It matters that the list is unsorted (even the static part of it in the source code is unsorted, and the man page is only partly sorted) so it is hard to find things in it.) > 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... Many of the standard ones like s (step) are documented, and are also implemented as a separate command. This implementation is to make s unambiguous. Otherwise you would have to type st to disambiguate it from other commands starting with s. People should know this without documentation. Who would expect to type "step" instead of "s"? "step" and "s" are compatible with gdb. I don't remember ever typing "step" in either. (Even "s<return"> is too much to type. Better debuggers give the alternative of using a single function key for stepping if the console has function keys.) In gdb, the history makes longer commands easier to type by copying lines from history. History in ddb doesn't work so well, since it is tiny, unsearchable, and quickly fills up with garbage. The history buffer of size 2048 should be able to hold 2048 s commands even without discarding duplicates, but actually fills up with just 2048/DB_MAXLINE = 17 repeated s commands. There is no documented or explicit alias for "show", but I don't remember ever typing anything except "sh" for it. > 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... Just as easy to fix countfreebufs if it is the only one longer than 11. Or just remove countfreebufs. It is doesn't exist according to ddb.4 :-). countfreebufs actually needs 14 (1 for a separator). 6*14 exceeds 80, but 5*14 is still better than 5*15 since it works down to 71-column terminals and is easier to read by not leaving so much white space between fields. There may be several other nonexistent commands outside of the primary command table. These need documentation more than the primary ones since they are harder to find in the source code. In the primary command tables, only the following names are longer than 8: - "registers" (length 9). Only in the "show" subtable. - "findstack" (length 9) In FreeBSD-5.2, there was only 1 dynamic extension with a name longer than 8: "lockedvnods". This is an especially stupid name. It is very verbose, but saves a whole character by abbreviating "virtual (?) inode" as "vnod" instead of as the usual "vn". > 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... Sure. 1 is subtracted from the terminal width to avoid problems with auto-wrap provided the line length is never exceeded. Width 80 is hard-coded as 79 in the initializer for db_max_width. You have to change this using the maxwidth variable if you are on a terminal with a different width, or better change the terminal. db_printf() does tab expansion to help keep track of the output position, so this has a chance of working. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140604034825.D3520>