[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jacob Bachmeyer
Subject: Re: PATCH: add dejagnu-report-card(1) tool (run as "dejagnu report card")
Date: Sun, 30 Dec 2018 19:25:23 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]