In article <Pine.LNX.4.44.0308281021290.18558-100000 at moroni.pp.asu.edu>,
David Bear <iddwb at asu.edu> wrote:
>On Wed, 27 Aug 2003, Steven Taschuk wrote:
>
>> > specified in options, rather than have it through an exception and return
>> > nothing?
>>
>> I don't think so. This is an unusual request -- normally it is
>> desirable for a program to insist on correct usage, rather than
>
>good points. yet, my purpose is to write a filter. the problem being
>that with different lpr implementations you don't know exactly what
>parameters will be passed since lpr is not really standardize (at least
>thats my understanding).
Right. It's what you don't want if you're duplicating
`ls` (for example) because ls recognizes all options no
matter where in the command line they appear.
It's what you want if you're duplicating the python
interpreter, which has to distinguish between its own
options and the options to send to the program it runs.
getopt treats everything after the first non-leading-'-'
argument as an argument.
I haven't looked at optparse yet. I should.
Command-line parsers aren't too hard to hand-roll. Main
problems are handling the potential equivalence of things
like "-n5", "-n 5", "-n:5" etc.
Regards. Mel.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4