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

Rainer Orth wrote:
>> On Sun, Dec 30, 2018 at 02:17:12AM -0600, Jacob Bachmeyer wrote:
>>     
>>> 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.
>>>       
>> I've never been fond of this because it makes backward compatibility a
>> problem. If you introduce a "report" subcommand later, then users who
>> have grown to love the "report card" shortcut will have to change
>> their habits and/or scripts. One and only one command for each
>> feature, IMHO.
>>     
> an alternative would be to handle this like hg does: as long as a
> subcommand is a unique prefix, accept it as such, otherwise show
> possible completions.  This is very convenient for interactive use, and
> if at some later point a new subcommand removes the uniqueness, users
> will learn quickly enough ;-)
>   

The catch in this case is that the launcher can only examine word 
boundaries.  While hg is (IIRC) written in Python, dejagnu(1) is a shell 
script that must run under POSIX and has (thus far) followed other 
constraints as well, like using, to the extent possible, only commands 
from the list in the GNU Coding Standards (section 7.2.2 "Utilities in 
Makefiles") of utilities allowed in configure and Makefile rules.  This 
is a result of trying to produce a portable script with limited 
experience and little knowledge of non-GNU systems.
As an aside, the --help implementation would be much simpler if it used 
cut(1) and wc(1), which are not on that list, but it was possible to 
implement using grep(1), sed(1), and tr(1), which are on that list.  I 
note that awk(1) is also on that list, but at the time was considering 
the possibility that systems might not have it.  Since "report-card" is 
likely to end up with only an Awk implementation, I am considering 
rewriting some parts of dejagnu(1) to use short Awk programs and 
pointing at the GNU Coding Standards and saying "you are supposed to 
have awk(1); GNU Awk is Free and will work; you have no excuse; 
not-a-bug" if anyone complains about it not working because awk(1) is 
missing.

Another option would be to rework the command parsing in dejagnu(1) and 
add one token look-ahead, which would allow "report card" to be 
recognized even if "report" also exists.  This would also change the 
defined behavior of dejagnu(1), but at the moment, only the "launcher" 
testsuite cares about this case.

Another option is to simply consider "report card" a partial 
implementation of a "report" command that has the form "report <type>".  
Note that, as currently implemented, "dejagnu help report" would find a 
dejagnu-report.1 man page, even though no actual "report" command exists.


Overall, I like this last interpretation:  this patch introduces a 
"report" command that takes a report type as its first argument.  
Currently, only the report type "card" is implemented.  :-)


> For scripting use, one should always use the full form anyway.

I think that this settles the canonical name question:  "dejagnu 
report-card" (standard name for launcher, explicit one-token name for 
command)

Documentation should also mention the spaced alias, but the canonical 
name uses dashes.  On the other hand, this seems to contradict the 
notion that "report <type>" is a command.


-- Jacob