Re: --help option: sys.exit or return?

Brian Dorsey <[email protected]> Thu, 21 Oct 2004 10:18:16 -0700
Newsgroups gmane.comp.python.optik.user
Message-ID <[email protected]>
On Tue, 19 Oct 2004 20:45:56 -0400, Greg Ward <[email protected]> wrote:
> For me, 100% of scripts that use Optik are of the "parse command-line
> args and exit on error or help/version query".  I don't want to write
> duplicate logic in every single one of those scripts to handle the "exit
> on error or help/version query" bit -- that would get tiresome very
> quickly.  So I have Optik do it for me.

This is exactly my sitation as well. 100% of my scripts which use
optik (or really optparse) should die with a nice friendly message
when they have trouble parsing options or really, any other error.

There is one piece of duplicate logic I end up adding to every single
script I write though:
    opt, args = parser.parse_args(sys.argv[1:])
    if len(args) == 1 and args[0].lower() in ('/?', '/h', '/help'):
        parser.print_help()
        sys.exit(0)

It's clear from the Optik docs that the goal is unixy option parsing,
and keeping the interface consistant. I completely agree with that.
And yet I still find myself adding this snippet to nearly every script
I write. Most of them are cross-platform, or windows only and I find
that my technically oriented windows users (internal IT folks)
universally expect to type something with a forward slash to get help.
Without this check, any script which is OK with just one arg will
happily try to work on "/help" or whatever.

Would you be open to adding some way to deal with this to Optik? 

A couple of ideas I had were:
 * Magically use a modified STD_HELP_OPTION on windows machines.
 * Add another keyword parameter to OptionParser.__init__ with a list
of additional strings to accept as ways to print help.
 * Allow a list of strings to be passed to the existing keyword
parameter, something like:
parser = optparse.OptionParser(add_help_option=['/?', '/h', '/help'])

(perhaps neither of these methods would work well, if option instances
couldn't deal with slashes at all?)

If it's not likely to get accepted for Optik itself, I suppose my best
solution would be to just always use a custom subclass of
OptionParser?

Anyway, thanks for reading this far, and huge thanks for writing Optik
to begin with... I can't even calculate how much time it's saved me.
Optparse and logging are actually my two favorite Python2.3 features.

Take care,
-Brian


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl