--- trunk/compilers/imcc/main.c (original)
+++ trunk/compilers/imcc/main.c Tue Jul 18 01:33:59 2006
@@ -369,7 +369,7 @@
exit(EX_USAGE);
}
if (*argc == opt.opt_index ) {
- fprintf(stderr, "Missing option value or program name\n");
+ fprintf(stderr, "Option %s expects an argument\n", (*argv)[*argc -
1]);
usage(stderr);
exit(EX_USAGE);
}
... provides quite misleading results:
$ parrot -o file.pir
Option file.pir expects an argument
parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] <file>
I don't believe there's a working heuristic for guessing which parameter the
user failed to provide. That's why I didn't write the original version that
way.
-- c
Does r13347 look better? If not, please revert both my changes.
As an aside, regardless of the three changes, this still segfaults:
./parrot -D 1
as does this:
./parrot ''
Thanks,
Audrey
Hi Audrey,
> Does r13347 look better? If not, please revert both my changes.
I think it's still misleading. #13364 is probably as accurate as Parrot can
report.
> As an aside, regardless of the three changes, this still segfaults:
>
> ./parrot -D 1
>
> as does this:
>
> ./parrot ''
I'll work on those. Thanks for the report.
-- c
Sorry, I meant #13367. I forgot to push my change.
-- c
Actually, chromatic meant r13344, not r13364.
Chromatic: Your original commit log noted room for possible
improvements with the English
message, which I interpreted as a invitation to help, and acted
accordingly, but probably
was mistaken, and thereby perceived as rude. I'm sorry about the
miscommunication.
I'd like to apologize publicly for saying that you can revert both my
changes if you think
it's stylistically bad English; I should have said "I'd be willing to
revert to r13344 if
you find inaccuracies with it".
I was already committing a revert to r13344, but it clashed with your
r13367 a few minutes
ago; for the record, I think your freshly-committed r13367 gives far
better error message
than either r13344 or r13364.
It's very hard for me to write tests for English parts of a project,
as they are often
subjective calls. In this particular case, please forgive me for
making a change without
submitting as test+patch first to the mailing list, which I should
have done in the first
place. You would be correct to chide me for abusing my Parrot commit
bit; from now on,
I'll learn to avoid committing anything without a clear consensus
from the parrot porters.
Again, very, very sorry for causing your distress. It was not meant
that way, and I'll
learn to adjust my behavior.
Thanks,
Audrey
> Chromatic: Your original commit log noted room for possible
> improvements with the English
> message, which I interpreted as a invitation to help, and acted
> accordingly, but probably
> was mistaken, and thereby perceived as rude. I'm sorry about the
> miscommunication.
To be fair, it was one of my tersest and worst commit messages. I should have
noted why I was unhappy with the error message, as well as the problems I had
in creating a better one. (It was also 1 am local time.)
I hope r13376 was much more clear.
-- c
I know I'm a little late to the game here, but in the future it would
be useful to mention this sort of info in a comment in the source. :-)
And a comment might be a nice addition even now.
(You mentioned being more clear in the svn log, but a comment would
really be the most useful.)
--
Matt Diephouse
http://matt.diephouse.com
> I know I'm a little late to the game here, but in the future it would
> be useful to mention this sort of info in a comment in the source. :-)
> And a comment might be a nice addition even now.
>
> (You mentioned being more clear in the svn log, but a comment would
> really be the most useful.)
Something like this?
-- c
This is what I ended up applying (inlined because it's already ci'd).
I wanted to get more into why having -o means that we can't tell what
the user forgot to pass. (And having not written any of the code, I
could tell what wasn't immediately clear :-)
--
matt diephouse
http://matt.diephouse.com
--- compilers/imcc/main.c (revision 13376)
+++ compilers/imcc/main.c (working copy)
@@ -368,8 +368,17 @@
usage(stderr);
exit(EX_USAGE);
}
- /* reached the end of the option list and consumed all of argv */
+ /* if we reached the end of the option list and consumed all of argv,
+ * we don't have the name of a program to run */
if (*argc == opt.opt_index ) {
+
+ /* If the user passed the -o flag -- the only flag that must take a
+ * parameter -- then we can't be sure that the user forgot the name of
+ * the program. it could be that the user forgot to give the argument
+ * for -o and the rest of argv got slurped up as flags. (If -o appeared
+ * with no argument, the getopt check would have complained earlier.)
+ *
+ * Given that, this was the best error message we could come up with */
if (interp->output_file) {
fprintf(stderr, "Missing program name or argument for -o\n");
}