[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

how to respond to bad options

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2002-07-25 22:56:57 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.