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
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
