getopt issues

Re: getopt issues

[David Bear]
[color=blue]
> I'm stumped. Trying to follow the docs and .. failure.
>
> here's the args
>[color=green][color=darkred]
> >>> args[/color][/color]
>[/color]
'-Middwb@mainex1. asu.edu -AKHAAM@prlinux+ 898 -CA --D2003-08-20-09:28:13.417 -Ff
-Hprlinux --JTCPIP_NPF_TEST _DARS_PORTRAIT -NTCPIP_NPF_TEST _DARS_PORTRAIT --Phold
queue -Qholdqueue -aacct -b2895 -d/var/spool/lpd/holdqueue -edfA898prlinux -fTCP
IP_NPF_TEST_DAR S_PORTRAIT -hprlinux -j898 -kcfA898prlinux -l66 -nKHAAM -sstatus
-t2003-08-20-09:28:13.000 -w80 -x0 -y0 acct \n'[color=blue]
>
>
> I know, they're long. sorry. they just are. and maybe thats the
> bug.
>
> here's what happens
>[color=green][color=darkred]
> >>> a, b = getopt.getopt(a rgs, 'APQn')
> >>> a[/color][/color]
> [][color=green][color=darkred]
> >>> b[/color][/color]
>[/color]
'-Middwb@mainex1. asu.edu -AKHAAM@prlinux+ 898 -CA --D2003-08-20-09:28:13.417 -Ff
-Hprlinux --JTCPIP_NPF_TEST _DARS_PORTRAIT -NTCPIP_NPF_TEST _DARS_PORTRAIT --Phold
queue -Qholdqueue -aacct -b2895 -d/var/spool/lpd/holdqueue -edfA898prlinux -fTCP
IP_NPF_TEST_DAR S_PORTRAIT -hprlinux -j898 -kcfA898prlinux -l66 -nKHAAM -sstatus
-t2003-08-20-09:28:13.000 -w80 -x0 -y0 acct \n'[color=blue]
>
>
> not at all what the docs lead me to believe. Is getopt buggy?[/color]

Normally, it is prudent to suspect your own code first rather
than the module.

In this case, getopt is expecting a list for the args argument which
normally comes from sys.argv. Try this:

args = args.split()
a, b = getopt.getopt(a rgs, 'APQn')

That will get you closer.
The next step is define the missing codes like -M.


Raymond Hettinger

Re: getopt issues

Quoth David Bear:[color=blue][color=green][color=darkred]
> >>> args[/color][/color]
> '-Middwb@mainex1. asu.edu -AKHAAM@prlinux+ 898 [...][/color]
[...][color=blue][color=green][color=darkred]
> >>> a, b = getopt.getopt(a rgs, 'APQn')[/color][/color][/color]

getopt wants its arguments as a list of strings (like sys.argv),
not one big string. Here, for example,
[color=blue][color=green][color=darkred]
>>> a, b = getopt.getopt(a rgs.split(), 'APQn')[/color][/color][/color]
Traceback (most recent call last):
...
getopt.GetoptEr ror: option -M not recognized

as expected.

--
Steven Taschuk o- @
staschuk@telusp lanet.net 7O )
" (

Re: getopt issues

On Tue, 26 Aug 2003, Steven Taschuk wrote:[color=blue][color=green][color=darkred]
> > >>> args[/color]
> > '-Middwb@mainex1. asu.edu -AKHAAM@prlinux+ 898 [...][/color]
> [...][color=green][color=darkred]
> > >>> a, b = getopt.getopt(a rgs, 'APQn')[/color][/color]
>
> getopt wants its arguments as a list of strings (like sys.argv),
> not one big string. Here, for example,[/color]

many thanks. I didn't think the 'list' of args that getopt wanted was a
python list.

now that I've read a little more of the getopt documentation, it says that
getopt stops processing when a 'nonoption' is encounted. Is there a way
to have it process the whole argument list, then only return the options
specified in options, rather than have it through an exception and return
nothing?
[color=blue][color=green][color=darkred]
> > >>> a, b = getopt.getopt(a rgs.split(),[/color][/color][/color]
'APQn') > Traceback (most recent call last):[color=blue]
> ...
> getopt.GetoptEr ror: option -M not recognized
>
> as expected.
>
>[/color]

Re: getopt issues

Quoth David Bear:
[...][color=blue]
> now that I've read a little more of the getopt documentation, it says that
> getopt stops processing when a 'nonoption' is encounted. Is there a way
> to have it process the whole argument list, then only return the options
> specified in options, rather than have it through an exception and return
> nothing?[/color]

I don't think so. This is an unusual request -- normally it is
desirable for a program to insist on correct usage, rather than
trying to guess what the user meant. (Imagine, for example, that
a user types 'rm -I *', intending 'rm -i *', and rm just ignores
the unknown option '-I'. This would be bad.)

It might, however, be possible to subclass optparse.Option Parser
to get the behaviour you want. (The optparse module is new in the
2.3 stdlib.)

--
Steven Taschuk staschuk@telusp lanet.net
"Telekinesi s would be worth patenting." -- James Gleick

Re: getopt issues

David Bear:[color=blue]
> Still, I think getopt is rather weak. It would be better if I could build
> a dictionary of options that I wanted, then when parsing the args, just
> fill in my dictionary values from args that I want.[/color]

See the optparse modules in the new 2.3 distribution, at


from optparse import OptionParser

parser = OptionParser()
parser.add_opti on("-f", "--file", dest="filename" ,
help="write report to FILE", metavar="FILE")
parser.add_opti on("-q", "--quiet",
action="store_f alse", dest="verbose", default=True,
help="don't print status messages to stdout")

(options, args) = parser.parse_ar gs()


Andrew
dalke@dalkescie ntific.com

Re: getopt issues

David Bear <[email protected] u> wrote in message news:<Pine.LNX. 4.44.0308281021 [email protected] p.asu.edu>...
[color=blue]
> 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). I'm just interested in two parameters out of
> possibly many.[/color]

Can't you specify all the possible parameters and collect only those you
want, or are you dealing with conflicting specifications of certain options?
[color=blue]
> Still, I think getopt is rather weak. It would be better if I could build
> a dictionary of options that I wanted, then when parsing the args, just
> fill in my dictionary values from args that I want.[/color]

As an aside, since it doesn't deal with cases where the option is
concatenated with the following parameter, you might find cmdsyntax
interesting since it aims to populate dictionaries with appropriately
named entries for the command line input:



It will also try and parse the arguments and return a list of failed
matches if requested.

However, it may well be overkill for your purposes.

David