On Apr 9, 4:37 pm, Raphael Mayoraz wrote:
> Ooops, forgot to attach the file in my first e-mail. Now, here it is.
>
>
> Hello,
>
> I have some trouble to make getopt.getopt work and the way I want (and
> is described in the documentation).
>
> Matt Nordhoff wrote:
> > BTW: Checked out optparse? It's bigger and sexier!
If you're doing things with positional arguments, you should consider using
argparse (http://argparse.googlecode.com/svn/tags/r101/doc/index.html). It's
like optparse, but (much) better.
Cheers,
Emm
--
http://mail.
Matt Nordhoff wrote:
> BTW: Checked out optparse? It's bigger and sexier!
Thanks for the tip. Works a treat.
-- Matt
--
http://mail.python.org/mailman/listinfo/python-list
Matthew Lear wrote:
> Hello,
>
> I'm having problems getting getopt to function correctly. Basically, no
> exception is being raised if no argument is passed to the code snippet
> below. I've read the Python documentation and tried example code from
> various sources which should cause an exceptio
LoD MoD wrote:
> In this instance the trackback was somewhat unhelpful.There problem was
> here:
>
>file = open(filename, 'r')
>
> should be
>
>file = open(a, 'r')
>
> args should be passed within the getopt riff
Well given the code you posted, this little "problem" you
In this instance the trackback was somewhat unhelpful.There problem was
here:
file = open(filename, 'r')
should be
file = open(a, 'r')
args should be passed within the getopt riff
On Fri, Jul 17, 2009 at 11:08 AM, MRAB wrote:
> LoD MoD wrote:
>
>> I am having trouble ex
LoD MoD wrote:
I am having trouble extending my option parsing.
Any help is appreciated:
import sys
import getopt
import time
def tail(file):
while 1:
where = file.tell()
line = file.readline()
if not line:
time.sleep(1)
file.seek(where)
Keep your threadiquette to yourself.
On Wed, Feb 11, 2009 at 1:48 PM, John Machin wrote:
> On Feb 11, 6:16 am, Matthew Sacks wrote:
>> Hi List,
>> I am getting an index out of range error when trying to parse with getopt.
>> Probably something simple. Any suggestions are appreciated
>>
>> optlis
Perhaps you can give me a call privately and I will explain it to you.
Regards,
Matthew
On Wed, Feb 11, 2009 at 1:48 PM, John Machin wrote:
> On Feb 11, 6:16 am, Matthew Sacks wrote:
>> Hi List,
>> I am getting an index out of range error when trying to parse with getopt.
>> Probably something s
On Feb 11, 6:16 am, Matthew Sacks wrote:
> Hi List,
> I am getting an index out of range error when trying to parse with getopt.
> Probably something simple. Any suggestions are appreciated
>
> optlist, args = getopt.getopt(sys.argv[1:], 'h', ['connectPassword=',
> 'adminServerURL=', 'action=', 't
>because the traceback says the index is 0 and there's only one line with a 0
>in it!
Indeed. Thank you.
On Wed, Feb 11, 2009 at 7:11 AM, MRAB wrote:
> Steve Holden wrote:
>>
>> Matthew Sacks wrote:
>>>
>>> Hi List,
>>> I am getting an index out of range error when trying to parse with
>>> geto
Steve Holden wrote:
Matthew Sacks wrote:
Hi List,
I am getting an index out of range error when trying to parse with getopt.
Probably something simple. Any suggestions are appreciated
optlist, args = getopt.getopt(sys.argv[1:], 'h', ['connectPassword=',
'adminServerURL=', 'action=', 'targets=',
Matthew Sacks wrote:
> Hi List,
> I am getting an index out of range error when trying to parse with getopt.
> Probably something simple. Any suggestions are appreciated
>
> optlist, args = getopt.getopt(sys.argv[1:], 'h', ['connectPassword=',
> 'adminServerURL=', 'action=', 'targets=', 'appDir=']
On Feb 11, 5:46 pm, Matthew Sacks wrote:
> I didn't realize that the no-value arguments, -b, -h, etc are required?
required sense 1: the 2nd arg of the function is required; if there
are to be no short options, the 2nd arg should be an empty string.
required sense 2: you are required to specify
I didn't realize that the no-value arguments, -b, -h, etc are required?
This seems to make things a bit more difficult considering unless I
use the GNU style getopt all arguments are required to be passed?
I could be mistaken.
I will have a look at what you have posted here and report my results.
On Feb 11, 4:36 pm, Matthew Sacks wrote:
> The documentation leaves lack for want, especially the examples.
You had two problems:
(1) str(passedArgs): The docs make it plain that "args" is a list, not
a str instance: """args is the argument list to be parsed, without the
leading reference to the
On Feb 11, 12:25 pm, John Machin wrote:
> On Feb 11, 12:12 pm, Matthew Sacks wrote:
>
> > if anyone can have a look at this code and offer suggestions i would
> > appreciate it.
> > i am forced to use getopt, so i cant use something good like optparse
>
> > passedArgs = sys.argv[1:]
> > optlist,
The documentation leaves lack for want, especially the examples.
On Tue, Feb 10, 2009 at 5:25 PM, John Machin wrote:
> On Feb 11, 12:12 pm, Matthew Sacks wrote:
>> if anyone can have a look at this code and offer suggestions i would
>> appreciate it.
>> i am forced to use getopt, so i cant use s
On Feb 11, 12:12 pm, Matthew Sacks wrote:
> if anyone can have a look at this code and offer suggestions i would
> appreciate it.
> i am forced to use getopt, so i cant use something good like optparse
>
> passedArgs = sys.argv[1:]
> optlist, args = getopt.getopt(str(passedArgs), ["connectPassword
On Sep 29, 7:58 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Carl Banks <[EMAIL PROTECTED]> writes:
> > On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
> > wrote:
> > > Steven Bethard <[EMAIL PROTECTED]> writes:
> > > > A user shouldn't have to go out of their way to specify regular
> > > > numbe
Carl Banks <[EMAIL PROTECTED]> writes:
> On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> > Steven Bethard <[EMAIL PROTECTED]> writes:
> > > A user shouldn't have to go out of their way to specify regular
> > > numbers on the command line, regardless of whether they're
> > > positive
On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
> > A user shouldn't have to go out of their way to specify regular
> > numbers on the command line, regardless of whether they're positive
> > or negative.
>
> A user shouldn't have to go out of
Steven Bethard <[EMAIL PROTECTED]> writes:
> A user shouldn't have to go out of their way to specify regular
> numbers on the command line, regardless of whether they're positive
> or negative.
A user shouldn't have to go out of their way to know whether what they
type on a command line will be t
Casey wrote:
> Ben Finney wrote:
>> I believe they shouldn't because the established interface is that a
>> hyphen always introduced an option unless (for those programs that
>> support it) a '--' option is used, as discussed.
>
> Not "THE" established interface; "AN" established interface. There
On Sep 27, 10:47 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> I believe they shouldn't because the established interface is that a
> hyphen always introduced an option unless (for those programs that
> support it) a '--' option is used, as discussed.
Not "THE" established interface; "AN" established
Ben Finney wrote:
> Casey <[EMAIL PROTECTED]> writes:
>
>> Well, it is a hack and certainly not as clean as having getopt or
>> optparse handle this natively (which I believe they should).
>
> I believe they shouldn't because the established interface is that a
> hyphen always introduced an opti
Casey <[EMAIL PROTECTED]> writes:
> Well, it is a hack and certainly not as clean as having getopt or
> optparse handle this natively (which I believe they should).
I believe they shouldn't because the established interface is that a
hyphen always introduced an option unless (for those programs t
On Sep 27, 7:57 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> One person's "brilliant" is another's "kludge".
Well, it is a hack and certainly not as clean as having getopt or
optparse handle this natively (which I believe they should). But I
think it is a simple and clever hack and still allows ge
Casey wrote:
> On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
>> If you can access the argument list manually, you could scan it for a
>> negative integer, and then insert a '--' argument before that,
>> if needed, before passing it to getopt/optparse. Then you wouldn't have
>>
Casey wrote:
> Is there an easy way to use getopt and still allow negative numbers as
> args?
[snip]
> Alternatively, does optparse handle this?
Peter Otten wrote:
> optparse can handle options with a negative int value; "--" can be used to
> signal that no more options will follow:
>
import
On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
> If you can access the argument list manually, you could scan it for a
> negative integer,
> and then insert a '--' argument before that, if needed, before passing it to
> getopt/optparse.
> Then you wouldn't have to worry about i
On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
> If you can access the argument list manually, you could scan it for a
> negative integer, and then insert a '--' argument before that,
> if needed, before passing it to getopt/optparse. Then you wouldn't have to
> worry about it
On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
...
> >>> args
>
> ['-123']
>
> Without the "--" arg you will get an error:
>
> >>> parser.parse_args(["-123"])
>
> Usage: [options]
>
> : error: no such option: -1
> $
>
> Peter
Passing -a-123 works
>>> options, args = parser.parse_args(
, 2007 at 08:08:05PM +0200, Peter Otten wrote regarding Re:
getopt with negative numbers?:
>
> Casey wrote:
>
> > On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> >> optparse can handle options with a negative int value; "--" can be used
> >
Casey wrote:
> On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
>> optparse can handle options with a negative int value; "--" can be used
>> to signal that no more options will follow:
>
> Thanks, Peter. getopt supports the POSIX "--" end of options indicator
> as well, but that seems
On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> optparse can handle options with a negative int value; "--" can be used to
> signal that no more options will follow:
Thanks, Peter. getopt supports the POSIX "--" end of options
indicator as well, but that seems a little less elegant t
Casey wrote:
> Is there an easy way to use getopt and still allow negative numbers as
> args? I can easily write a workaround (pre-process the tail end of
> the arguments, stripping off any non-options including negative
> numbers into a separate sequence and ignore the (now empty) args list
> re
Rocky Zhou wrote:
> .dirs .files is just a snapshot of the current directories, which can
> be used to delete-outdated files when restoring. Here I used absolute
> path by using tar's -P parameter. When fs_rstore, it will do this:
> command = "tar -xpz -P -f %s.tgz -T %s" % (archive, self.t_files)
Well, I think I must have more explanation on my script. The script's
usage is like this:
~# fs_backup
Lack of backup identity name
program usage: fs_backup [OPTIONS] $identity
OPTIONS:
-a|--append [t/x[L]:$path, append 1 dir or file to $identity
t/x: include/exclude list, as -T/-X
Rocky Zhou wrote:
> I wonder is there any way to make the wrapper program can wrap options
> && arguments for the the subprocess/command the wrapper will
> execute? by getopt or optparse module?
[snip]
> I need this because I now have finished a fs_backup script written in
> python, it will execu
On Mon, 19 Dec 2005, [EMAIL PROTECTED] wrote:
> I want to be able to do something like:
>
> myscript.py * -o outputfile
>
> and then have the shell expand the * as usual, perhaps to hundreds of
> filenames. But as far as I can see, getopt can only get one argument
> with each option. In the abov
On Mon, 19 Dec 2005 02:29:41 -0800, [EMAIL PROTECTED] wrote:
> I want to be able to do something like:
>
> myscript.py * -o outputfile
>
> and then have the shell expand the * as usual, perhaps to hundreds of
> filenames.
If you are calling this from most Linux and Unix shells, the shell will
On Mon, 19 Dec 2005 02:29:41 -0800, [EMAIL PROTECTED] wrote:
> I want to be able to do something like:
>
> myscript.py * -o outputfile
>
> and then have the shell expand the * as usual, perhaps to hundreds of
> filenames. But as far as I can see, getopt can only get one argument
> with each opti
On 19 Dec 2005 02:29:41 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I want to be able to do something like:
>
> myscript.py * -o outputfile
>
> and then have the shell expand the * as usual, perhaps to hundreds of
> filenames. But as far as I can see, getopt can only get one argument
> wi
Frans Englich wrote:
On Wednesday 15 December 2004 14:07, Diez B. Roggisch wrote:
In my use of getopt.getopt, I would like to make a certain parameter
mandatory. I know how to specify such that a parameter must have a value
if it's specified, but I also want to make the parameter itself
mandatory(c
On Wednesday 15 December 2004 14:07, Diez B. Roggisch wrote:
> > In my use of getopt.getopt, I would like to make a certain parameter
> > mandatory. I know how to specify such that a parameter must have a value
> > if it's specified, but I also want to make the parameter itself
> > mandatory(combin
In <[EMAIL PROTECTED]>, Frans Englich
wrote:
>> > In my use of getopt.getopt, I would like to make a certain parameter
>> > mandatory.
>>
>> Isn't a *mandatory option* a contradiction? Why don't you turn it into an
>> argument? You already called it argument in the subject of your post.
>
> I p
On Wednesday 15 December 2004 20:12, Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Frans Englich
>
> wrote:
> > Hello,
> >
> > In my use of getopt.getopt, I would like to make a certain parameter
> > mandatory.
>
> Isn't a *mandatory option* a contradiction? Why don't you turn it into
In <[EMAIL PROTECTED]>, Frans Englich
wrote:
>
> Hello,
>
> In my use of getopt.getopt, I would like to make a certain parameter
> mandatory.
Isn't a *mandatory option* a contradiction? Why don't you turn it into an
argument? You already called it argument in the subject of your post.
Ciao,
> In my use of getopt.getopt, I would like to make a certain parameter
> mandatory. I know how to specify such that a parameter must have a value
> if it's specified, but I also want to make the parameter itself
> mandatory(combined with a mandatory value, the result is that the user
> must specify
Frans Englich wrote:
> In my use of getopt.getopt, I would like to make a certain parameter
> mandatory.
but you just did:
>if configurationFile == "":
>print "You must pass an URL/path to a configuration file, see
> --help."
>sys.exit(common.exitCodes["parameter"
51 matches
Mail list logo
