command line arguments

[Jon Hewer]

hi

i am writing a little script and currently implementing command line
arguments following the guide by mark pilgrim from dive into python;

http://diveintopython.org/scripts_and_streams/command_line_arguments.html

thats all fine, however i am not sure of the BEST way to handle
multiple command line arguments

for my script, i want to be able to accept two arguments, a name and a
url, but i am not sure if its best to use one command line option/flag
(eg -n to specify name) and then grab the url from the extra data
which will be in 'args':

opts, args = getopt.getopt(s ys.argv[1:], "n:", ["name="])

or to have two command line options/flags, -n and -u, and checking
that these have both been specified and then proceeding (this might be
a little messier)

any tips would be much appreciated

thanks in advance
jon

[Peter Hansen]

Re: command line arguments

Jon Hewer wrote:[color=blue]
> i am writing a little script and currently implementing command line
> arguments following the guide by mark pilgrim from dive into python;
>
> http://diveintopython.org/scripts_an...arguments.html
>
> thats all fine, however i am not sure of the BEST way to handle
> multiple command line arguments
>
> for my script, i want to be able to accept two arguments, a name and a
> url, but i am not sure if its best to use one command line option/flag
> (eg -n to specify name) and then grab the url from the extra data
> which will be in 'args':
>
> opts, args = getopt.getopt(s ys.argv[1:], "n:", ["name="])
>
> or to have two command line options/flags, -n and -u, and checking
> that these have both been specified and then proceeding (this might be
> a little messier)
>
> any tips would be much appreciated[/color]

I would approach this as a usability issue for your users, rather than
from the point of view of which is "a little messier" in the code.

What's the purpose of this utility? Is it to do something with the URL?
And the URL must always be specified? What about the name? Also
mandatory, or optional? The relationship between the two?

I would guess (without yet knowing what you are doing) that if these
things are not really *optional*, making them options is not the best
approach and you might be better off just requiring them to be specified
on the command line as two arguments.

-Peter

[wittempj@hotmail.com]

Re: command line arguments

You also could opt for the OptionParser in optparse, it is quiet
powerful, and you can keep your code clean. Your requirements would
translate to something like:
py>#!/usr/bin/env python
py>"""show OptionParser
py>"""
py>from optparse import OptionParser
py>
py>def main():
py> parser = OptionParser(us age = __doc__, version = '3.1415926')
py> parser.add_opti on("-n", "--name", dest="name", action="store",
py> help="enter a name")
py> parser.add_opti on("-u", "--url", action="store", dest="url",
help = "enter an url")
py>
py> (options, args) = parser.parse_ar gs()
py> if not options.name and not options.url:
py> parser.error('s pecify both name and url')
py> print options.name
py> print options.url
py>
py>if __name__ == "__main__":
py> main()

when called it will print things like:
martin@ubuntu:~ $ ./test.py -u www.python.org -n python
{'url': 'www.python.org ', 'name': 'python'} []
martin@ubuntu:~ $ ./test.py -u www.python.org -n python
python

https://www.python.org

martin@ubuntu:~ $ ./test.py -h
usage: show OptionParser


options:
--version show program's version number and exit
-h, --help show this help message and exit
-n NAME, --name=NAME enter a name
-u URL, --url=URL enter an url
martin@ubuntu:~ $ ./test.py --version
3.1415926
martin@ubuntu:~ $ ./test.py
usage: show OptionParser


test.py: error: specify both name and url
martin@ubuntu:~ $

[Michael Hoffman]

Re: command line arguments

wittempj@hotmai l.com wrote:
[color=blue]
> py> parser.add_opti on("-n", "--name", dest="name", action="store",
> py> help="enter a name")
> py> parser.add_opti on("-u", "--url", action="store", dest="url",
> help = "enter an url")[/color]

It's worth noting that this will have the same effect and involves less
repetitive typing:

parser.add_opti on("-n", "--name", help="enter a name")
parser.add_opti on("-u", "--url", help="enter a url")

Discovering this has made optparse usage much more painless for me, and
also reduces the incidence of those nasty multiple line option additions.

Although I should note for the record that I agree with Peter Hansen
that if the arguments are not *optional* then they should not be made
options in this manner.
--
Michael Hoffman

[Bryan Olson]

Command-line arguments; was -- same thing

Peter Hansen wrote:[color=blue]
> I would approach this as a usability issue for your users, rather than
> from the point of view of which is "a little messier" in the code.[/color]

I agree, yet in my own programs, the command-option support
tends to suck. I think I can work out function/class/module
interfaces well enough, but command-lines, not so much.

Anyone know of a good command-option style-guide for cross-
platform apps?


--
--Bryan

[Jon Hewer]

Re: command line arguments

>What's the purpose of this utility? Is it to do something with the URL?[color=blue]
>And the URL must always be specified? What about the name? Also
>mandatory, or optional? The relationship between the two?[/color]

its just a simple rss reader. i'm writing it almost purely just to
get me using language (i'm learning python) it lets you save rss
feeds, and to do this one would specify a name and url (ie you have to
specify both), but there are other things it can do (remove a rss
feed, view a feed) hence i thought it was best to using command line
options
[color=blue]
>You also could opt for the OptionParser in optparse..[/color]

Thanks, i'll take a look

On 8/31/05, Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote:[color=blue]
> wittempj@hotmai l.com wrote:
> [color=green]
> > py> parser.add_opti on("-n", "--name", dest="name", action="store",
> > py> help="enter a name")
> > py> parser.add_opti on("-u", "--url", action="store", dest="url",
> > help = "enter an url")[/color]
>
> It's worth noting that this will have the same effect and involves less
> repetitive typing:
>
> parser.add_opti on("-n", "--name", help="enter a name")
> parser.add_opti on("-u", "--url", help="enter a url")
>
> Discovering this has made optparse usage much more painless for me, and
> also reduces the incidence of those nasty multiple line option additions.
>
> Although I should note for the record that I agree with Peter Hansen
> that if the arguments are not *optional* then they should not be made
> options in this manner.
> --
> Michael Hoffman
> --
> http://mail.python.org/mailman/listinfo/python-list
>[/color]

[Peter Hansen]

Re: command line arguments

Jon Hewer wrote:[color=blue][color=green]
>>What's the purpose of this utility? Is it to do something with the URL?
>>And the URL must always be specified? What about the name? Also
>>mandatory, or optional? The relationship between the two?[/color]
>
>
> its just a simple rss reader. i'm writing it almost purely just to
> get me using language (i'm learning python) it lets you save rss
> feeds, and to do this one would specify a name and url (ie you have to
> specify both), but there are other things it can do (remove a rss
> feed, view a feed) hence i thought it was best to using command line
> options[/color]

In that case, consider making the URL or the name, or both, an argument
*after* the options. The operation you want to perform would be
specified with an option, possibly including an argument of its own if
that information wasn't normally needed. For example (and keep in mind
I really have no idea what RSS is useful for, and my sole exposure to it
is to subscribe to the BBC Latest Headlines in Firefox):

rssutil --add -nBBC http://fxfeeds.mozilla.org/rss20.xml
rssutil --remove -n BBC
rssutil --view http://fxfeeds.mozilla.org/rss20.xml

or perhaps:
rssutil -ahttp://fxfeeds.mozilla .org/rss20.xml BBC
rssutil --remove BBC
rssutil -v BBC

I can't judge which blend of possibilities is more reasonable; I'm just
trying to point out some of the thought process behind choosing an
appropriate scheme. Making *everything* an option here just feels
wrong, from a user interface point of view.

-Peter