Suggestion: UnixOptionParser class in optparse.py

Beni Cherniavsky cben at techunix.technion.ac.il
Tue Jan 7 14:52:46 EST 2003


On 2003-01-06, Rich Harkins wrote:

> I love the OptionParser class.Good stuff.  The only thing that I would
> want different (right now anyway) would be a simple way to parse Unix
> style options (first non-option argument terminates options).My
> proposal is to add a tiny subclass in optparse.py that would handle
> this:
>
[snip]
>
> This would provide the best of both worlds IMO.I can understand why
> some users would like the interspersed args, but it makes it harder to
> provide applications consistent with other Unix commands.

If you are using Linux or anything else with a rich set of installed GNU
programs, the majority of the applications already use this style.  As far
as many users like me are concerned, this is the new unix style and it's
here to stay :-).

The proper ways in most applications to disable it are setting
POSIXLY_CORRECT or usign '--' (which is the only really bullet-proof way
to protect unpredicatable data from interpretation as options).  IIRC,
optparse already respects both, so for typical application I think it's
best to let the user decide.

[There is also the dirty _<pid>_GNU_nonoption_argv_flags_ hack for a shell
to signal which args resulted from wildcard expansion, see info grep
for details - not that I ever saw bash set this...]

> I would have
> to wrap this separately to provide wrapper programs.For example,
>
> mydebugger [options] command args...
>
> will fail if args contains any flags.
>
This is a special use.  Indeed here forcing the posix behavior is the
right thing, so adding your class (that I snipped) is a good idea IMHO.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>






More information about the Python-list mailing list