how to respond to bad options

One part of the `I want my -d' story caught my eye:

Justin Erenkrantz <jerenkrantz@apache.org> writes:
> My terminal is only about twenty-five lines high, so the top
> part got chopped off. I did run svn help co, but didn't catch the
> destination part at top of the help. Regardless, svn should have
> given me the syntax on 'svn co' in this case rather than giving me
> the completely unhelpful message it did.

I've always disliked programs that give you a complete usage summary
whenever you give it a bad option flag. Maybe I'm a poorer typist
than most, but usually I've simply mistyped something, and it's
annoying to have all my context --- that is, the actual work I've been
doing --- swept off the screen.

I prefer error messages that simply tell you which flag the program
didn't like, and tell you how to get usage if you actually need it:

$ svn co http://foo.bar.baz/project/trunk -y smootz
svn: invalid option character: y
Type `svn --help' for general Subversion usage information.
$

Or, if you wanted to be fancy:

$ svn co http://foo.bar.baz/project/trunk -y smootz
Type `svn --help co' for usage information for `svn co', or
`svn --help' for general Subversion usage information.
$

But generally, people won't read long error messages: they just try to
guess what they did wrong and try again. A short error message with a
pointer to more information actually gets used more.

Is Subversion's current behavior what many people actually prefer, or
should I submit a patch?

(This may have been discussed already, and if so, I'm sorry; if
someone has a pointer handy, I'll go read the prior discussion.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 25 22:57:32 2002