Re: PATCH: add dejagnu-report-card(1) tool (run as "dejagnu report card")

Ben Elliston wrote:
> On Sat, Dec 29, 2018 at 11:40:32PM -0600, Jacob Bachmeyer wrote
>> This patch is the long-promised dejagnu-report-card(1) tool,
>> although it is not yet actually installed under that name, instead
>> being run as "dejagnu report card" or "dejagnu report-card".
>>     
> The former ("dejagnu report card") is confusing because "card" looks
> like an argument. I think the launcher subcommands should not contain
> spaces. dejagnu report-card seems natural enough to me.
>   

The "dejagnu report card" form is an alias as long as there is no 
"report" command -- the launcher sees "report", notes that "report" is 
not a valid command, appends the next argument, checks again, and finds 
that "report-card" is valid.  If invoked as "dejagnu report-card", the 
launcher sees "report-card", notes that that *is* a valid command, and 
runs with it.

This is for user convenience, along with the symlink-to-launcher 
feature, which is intended to bring the commands into the $PATH where 
Readline can find them.  There are some CLIs that make extensive use of 
multi-word commands (C-Kermit is a good example, complete with command 
completion; this model is also very common in networking equipment) and 
the space bar can be easier to hit than the "-" key.

That said, the dejagnu subcommands need canonical names for 
documentation.  Should those be like "dejagnu-report-card" (using a 
launcher symlink) or "dejagnu report-card" (standard name for launcher, 
explicit full name for command)?

Or should the Texinfo manual use "dejagnu report-card" and the man pages 
use "dejagnu-report-card"?  The man pages themselves must use the latter 
form for their own names for technical reasons, but can list any form in 
the NAME section.

>> All three implementations are included in this patch.  Installing it
>> as dejagnu-report-card simply requires making a symlink
>> dejagnu-report-card -> dejagnu; the launcher will handle the rest if
>> called via such a symlink.
>>     
> As the person who gets to maintain this code, I'm really not a fan of
> multiple implementations. I don't mind if it's sh, Tcl or AWK. I
> understand the intrinsic value of n-version development in testing,
> but in practice, I don't want multiple copies of the code that do the
> same thing. Please just pick one on the criteria of performance or
> maintainability and submit that, please.

Picking just one and throwing out the other code is hard, but at least 
the other versions will be in the mailing list archive now, so that 
makes it easier.  :-)

Are you sure about this, since that value in testing is an ongoing 
benefit with future maintenance (and also a cost in additional effort to 
make changes, which may outweigh that benefit)?

I will look into it, but if you insist, I am leaning towards the Awk 
version:  (1) it has the best performance (by a significant margin) in 
every test I have done so far, and (2) Awk is part of the POSIX baseline 
and the GNU Coding Standards permit even configure itself (and Makefile 
rules) to assume the availability of awk(1) without checking or fallback.

Please tell me if you insist on this -- there is also some scaffolding 
in the testsuite in this patch that supports multiple implementations 
and needs to be reworked if multi-implementation commands are to be avoided.


-- Jacob