From david@sleepydog.net Tue Apr 2 16:55:50 2002 From: david@sleepydog.net (David Boddie) Date: Tue, 2 Apr 2002 17:55:50 +0100 Subject: [getopt-sig] Discussion over? Message-ID: <20020402165845.BE2C32AA8B@wireless-084-136.tele2.co.uk> There hasn't been any discussion on this list for a while which either means that people are too busy to move the discussion forwards, or that a consensus has been reached behind the scenes. In the meantime, I finally got round to writing my version of the ripoff interface for the library comparison page: http://www.python.org/sigs/getopt-sig/compare.html Allowing large numbers of options to be specified in any order gave my implementation some difficulty and an alternative approach was required. The library and example scripts can be found via the page at http://david.boddie.org.uk/Projects/Python/CMDSyntax/index.html As the ripoff interface test is quite short, I've posted it here since parts of it require comment: > #! /usr/bin/env python > import cmdsyntax, sys > > # Define the syntax. [] indicate optional arguments; () indicate groups of arguments; A|B indicates that either A or B must occur. > syntax = """ > [-h | --help] | [--version] | > ( > [ > (-v | --verbose=V) | (-q | --quiet) > ] > > [( -d DEVICE) | (--device=DEVICE)] > [(-b DIR) | --output-base=DIR] > > [(-t TRACKS) | --tracks=TRACKS] > > [ > (-p | --use-pipes | --synchronous) > | > ( > (-f | --use-files | --asynchronous) > [ > (-k | --keep-tmp) [-R | --rip-only] > ] > ) > ] > > [-P | --playback] > [-e | --eject] > [(-A ARTIST) | --artist=ARTIST] > [(-L ALBUM) | --album=ALBUM] > [(-D DISC) | --disc=DISC] > [(-y YEAR) | --year=YEAR] > [--offset=OFFSET] > ) > """ The ripoff syntax isn't just a flat sequence of optional parameters. Despite assertions that -v and -q should be tolerated on the same command line for cases when aliases to the ripoff script are being used, I have separated them and consider use of both on the same command line to be invalid. There may be other cases where use of one option precludes the use of another for valid input. > if __name__ == "__main__": > > # Create a syntax object. > syntax_obj = cmdsyntax.Syntax(syntax) > > # Match the command line arguments against the syntax definition. > matches = syntax_obj.get_args(sys.argv[1:]) This method returns a list of dictionaries. Ideally, there should be a single dictionary returned, but some syntaxes may be ambiguous and will return more than one match. > # No valid matches were found. > if matches == []: > > print "Syntax:", syntax > sys.exit() > > # Show each valid match. > for match in matches: > > print match > print > > sys.exit() Note that no coercion of types is performed. It would be up to the developer, or another library author, to ensure that user input conformed to that expected by the script. Has this raised any useful points to get the discussion going again? David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Tue Apr 9 13:11:44 2002 From: holger@trillke.net (holger@trillke.net) Date: Tue, 9 Apr 2002 14:11:44 +0200 Subject: [getopt-sig] mapping cmdline-interface to python function Message-ID: <20020409121144.GL21372@devel.trillke> Hello, Please bear with me as this is my first time i make a proposal to a python-sig. i am not new at enjoying and programming python, though :-) The basic idea is to map the commandline interface into a python class resp. a function. This can be done via code inspection supporting both the programmer to easily specify (in a pythonic way) options/arguments/documentation and the user to get nice output of false usage. Basically you can write a function and let a special module ('main') do all the laborious work for looking at sys.args I start with a sample program that uses the proposed functionality. it's a program that takes at least one filename, requires a "--id" or "-i" option together with a decimal value. it also accepts more than one filename. import main # this contains the code to map # cmdline-interface to classes # makes heavy intelligent use of # code inspection exec main.map_command_line_to('program') # classname as string class program: version="0.1" authors="Holger Krekel " download="http://www.trillke.net/~hpk/program/" help = """ longish tutorial with examples ...." def run(self, quiet =('q',None,0), # quiet operation verbose=('v',None,0), # print verbose information id=('i','%d',1), # specficies the id to use filein='%s', # the file to be read *morefiles): """ This program demonstrates the use of the main commandline interface mapper. it allows you to express without redundance the options, documentation and types of options and parameters for you function in one place and it is a natural place :-)""" OK. This is a complete specification of parsing and gettings the cmdline-args. Let me explain the the lines of the example: - the names of the variables are longoptions. quiet =('q',None,0), # quiet operation - if variables have a tuple as a default value, then this is a specification with the following meaning: optionaliases,argumentspec, required = (...) - optionalias is a string or a tuple of strings to specify alias option names - argumentspec specifies in string notation what is expected (could of course contain more than one '%d %s') - required indicates if this option is required - an optional fourth element could contain a (typed!) default value - if variables have a string as a default value, then this is a (non-option) argument and you can specify if it should be a decimal/string ... filein='%s', # the file to be read *morefiles): - additional args are in morefiles - the documentation behind the variables is the documentation for this option! So if you give an id that is not a decimal value, you would get a type-error which cites the documentation and urges the user to use a decimal value. This happens automatically. id=('i','%d',1), # id to look for in the files - usage is in the __doc__ string of the function """ This program demonstrates the use of the main commandline interface mapper....""" - non '__.*' class attributes are long options for informational use by the user. so "program --version" prints 0.1 "program --download" prints http://www.trillke.net/~hpk/program "program --authors" prints "program --help" prints a longish help (not just usage which) this posting is already long enough, so i am not going into details of my plan for implementation. But please note several things: - the program will just get all correct options and args or None if it wasn't specified (and not required). the main module educates the user about intended usage and your program can just work with the preprocessed given objects just as it would if have been called directly in python! if you say "program --id 17 /etc/passwd /etc/groups" your program.run function will have the following vars in locals() quiet = None verbose= None id=17 filein='/etc/passwd' morefiles=('/etc/groups') - documentation for options and program is right where the program is. - we can easily provide hooks in the class to check for correct combinations of arguments, special forbidden usages and so on. - Please note, that we could improve this design so that other python modules could easily use this program without making up an intermediate commandline-representation. they would call another function of the class "program" which raises a precise exception if you give wrong parameters. But it would feel as a ordinary python function... This idea really guides the whole design. Basically it makes writing standard commandline interfaces with *rich* functionality for the user a snap. Maybe it could even use optik or other libs as a backend. What do you think? I would really like to work with some people on improving the design before going to code it. holger From gward@python.net Thu Apr 11 20:34:38 2002 From: gward@python.net (Greg Ward) Date: Thu, 11 Apr 2002 15:34:38 -0400 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released Message-ID: <20020411193438.GA19008@gerg.ca> Optik 1.3 ========= Optik is a powerful, flexible, extensible, easy-to-use command-line parsing library for Python. Using Optik, you can add intelligent, sophisticated handling of command-line options to your scripts with very little overhead. Here's an example of using Optik to add some command-line options to a simple script: from optik import OptionParser [...] parser = OptionParser() parser.add_option("-f", "--file", action="store", type="string", dest="filename", help="write report to FILE", metavar="FILE") parser.add_option("-q", "--quiet", action="store_false", dest="verbose", default=1, help="don't print status messages to stdout") (options, args) = parser.parse_args() With these few lines of code, users of your script can now do the "usual thing" on the command-line: -f outfile --quiet -qfoutfile --file=outfile -q --quiet --file outfile (All of these result in options.filename == "outfile" options.verbose == 0 ...just as you might expect.) Even niftier, users can run one of -h --help and Optik will print out a brief summary of your script's optons: usage: [options] options: -h, --help show this help message and exit -fFILE, --file=FILE write report to FILE -q, --quiet don't print status messages to stdout That's just a taste of the flexibility Optik gives you in parsing your command-line. See the documentation included in the package for details. AUTHOR, COPYRIGHT, AVAILABILITY ------------------------------- Optik was written by Greg Ward The latest version of Optik can be found at http://optik.sourceforge.net/ Copyright (c) 2001 Gregory P. Ward. All rights reserved. CHANGES IN OPTIK 1.3 -------------------- * Fixed a couple of lurking bugs found by PyChecker. * You can now get away with not supplying an option's type, no matter the action: Optik now assumes a default type of "string". * You can now get away with not supplying an option's destination: Optik now derives a default destination from the first long option, or the first short option if no long options were given. Eg. an option string "--foo-bar" has the default destination 'foo_bar'. * Refactored both Option's and OptionParser's constructors to make life easier for people extending Optik. * Added the "examples/" subdirectory -- this is a repository of examples of extending and using Optik; the goal is to provide canonical implementations of various features that I don't want to add to Optik proper, but that are occasionally requested. (Also, this gives me a good place to test how Optik's extensibility.) * Added support for long and complex option types, mainly for completeness (patch by Matthew Mueller). * Added make_option() as an alias for the Option constructor, because someday there might be many Option classes (in which case make_option() will become a factory function). -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ Clarke's Law, redux: Any sufficiently advanced technology is indistiguishable from a rigged demo. From david@sleepydog.net Fri Apr 12 10:56:22 2002 From: david@sleepydog.net (David Boddie) Date: Fri, 12 Apr 2002 10:56:22 +0100 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: <20020411193438.GA19008@gerg.ca> References: <20020411193438.GA19008@gerg.ca> Message-ID: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> On Thursday 11 Apr 2002 8:34 pm, Greg Ward wrote: > With these few lines of code, users of your script can now do the > "usual thing" on the command-line: > > -f outfile --quiet > -qfoutfile The last one is truly diabolical. ;-) This is where having some sort of syntax style option would be useful because there are cirumstances in which a developer might want -qfoutFile (noting the use of "F" to avoid duplicating "f") to be equivalent to -q -f -o -u -t -F -i -l -e Is this regarded as bad style? David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Fri Apr 12 13:07:09 2002 From: holger@trillke.net (holger@trillke.net) Date: Fri, 12 Apr 2002 14:07:09 +0200 Subject: [getopt-sig] sig active or not? Message-ID: <20020412120709.GX21372@devel.trillke> Hello, what is the state of this getopt-sig? Anybody intested in conceptual discussions and/or implementations? Holger From david@sleepydog.net Fri Apr 12 13:12:17 2002 From: david@sleepydog.net (David Boddie) Date: Fri, 12 Apr 2002 13:12:17 +0100 Subject: [getopt-sig] sig active or not? In-Reply-To: <20020412120709.GX21372@devel.trillke> References: <20020412120709.GX21372@devel.trillke> Message-ID: <20020412121544.C08902AFB4@wireless-084-136.tele2.co.uk> On Friday 12 Apr 2002 1:07 pm, holger@trillke.net wrote: > Hello, > > what is the state of this getopt-sig? > > Anybody intested in conceptual discussions > and/or implementations? I'm still interested. There have been a couple of postings discussing various ideas recently. David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Fri Apr 12 13:32:42 2002 From: holger@trillke.net (holger@trillke.net) Date: Fri, 12 Apr 2002 14:32:42 +0200 Subject: [getopt-sig] sig active or not? In-Reply-To: <20020412121544.C08902AFB4@wireless-084-136.tele2.co.uk> References: <20020412120709.GX21372@devel.trillke> <20020412121544.C08902AFB4@wireless-084-136.tele2.co.uk> Message-ID: <20020412123242.GY21372@devel.trillke> On Fri, Apr 12, 2002 at 01:12:17PM +0100, David Boddie wrote: > On Friday 12 Apr 2002 1:07 pm, holger@trillke.net wrote: > > Hello, > > > > what is the state of this getopt-sig? > > > > Anybody intested in conceptual discussions > > and/or implementations? > > I'm still interested. There have been a couple of postings discussing > various ideas recently. may i ask what you think about my recent proposal? http://mail.python.org/pipermail/getopt-sig/2002-April/000121.html for details. thanks! holger From david@sleepydog.net Fri Apr 12 13:46:20 2002 From: david@sleepydog.net (David Boddie) Date: Fri, 12 Apr 2002 13:46:20 +0100 Subject: [getopt-sig] sig active or not? In-Reply-To: <20020412123242.GY21372@devel.trillke> References: <20020412120709.GX21372@devel.trillke> <20020412121544.C08902AFB4@wireless-084-136.tele2.co.uk> <20020412123242.GY21372@devel.trillke> Message-ID: <20020412124947.A35B82AFB4@wireless-084-136.tele2.co.uk> On Friday 12 Apr 2002 1:32 pm, holger@trillke.net wrote: > may i ask what you think about my recent proposal? > > http://mail.python.org/pipermail/getopt-sig/2002-April/000121.html In your proposal, you wrote: > if you say "program --id 17 /etc/passwd /etc/groups" > your program.run function will have the following vars > in locals() > > quiet = None > verbose= None > id=17 > filein='/etc/passwd' > morefiles=('/etc/groups') I think that this is interesting as you automatically obtain variables initialised to the desired values, but I can't really comment on the method you use. How do you propose that options such as "--output-file" are represented as variables? David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Fri Apr 12 14:31:32 2002 From: holger@trillke.net (holger@trillke.net) Date: Fri, 12 Apr 2002 15:31:32 +0200 Subject: [getopt-sig] sig active or not? In-Reply-To: <20020412124947.A35B82AFB4@wireless-084-136.tele2.co.uk> References: <20020412120709.GX21372@devel.trillke> <20020412121544.C08902AFB4@wireless-084-136.tele2.co.uk> <20020412123242.GY21372@devel.trillke> <20020412124947.A35B82AFB4@wireless-084-136.tele2.co.uk> Message-ID: <20020412133132.GZ21372@devel.trillke> On Fri, Apr 12, 2002 at 01:46:20PM +0100, David Boddie wrote: > On Friday 12 Apr 2002 1:32 pm, holger@trillke.net wrote: > > > http://mail.python.org/pipermail/getopt-sig/2002-April/000121.html > > In your proposal, you wrote: > > > if you say "program --id 17 /etc/passwd /etc/groups" > > your program.run function will have the following vars > > in locals() > > > > quiet = None > > verbose= None > > id=17 > > filein='/etc/passwd' > > morefiles=('/etc/groups') > > I think that this is interesting as you automatically obtain variables > initialised to the desired values, but I can't really comment on the > method you use. i guess you mean the code-inspection part? That's a wide field but i have some experience there and think its not really difficult to do. > How do you propose that options such as "--output-file" are represented > as variables? good question. several possibilities: 1. in the current design: def run( outputfile=('output-file', '%s') # ... 2. or we could lazily allow to let 'outputfile', 'out-put-file' ... to all map to the variable outputfile. The question is whether you usually want to *prevent* a cmdline-user from using either --outputfile or --output-file. personally i wouldn't want to prevent that. 3. maybe a better idea is to improve the design: def run( outputfile=('--output-file %s', 0) # ... which is shorter, more flexible and more precise than the first suggestion. what would you prefer or suggest? holger From goodger@users.sourceforge.net Fri Apr 12 21:45:05 2002 From: goodger@users.sourceforge.net (David Goodger) Date: Fri, 12 Apr 2002 16:45:05 -0400 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> Message-ID: David Boddie wrote: >> -f outfile --quiet >> -qfoutfile > > The last one is truly diabolical. ;-) > > This is where having some sort of syntax style option would be useful > because there are cirumstances in which a developer might want > > -qfoutFile > > (noting the use of "F" to avoid duplicating "f") to be equivalent to > > -q -f -o -u -t -F -i -l -e > > Is this regarded as bad style? Yes, and wrong too. Either the -f option takes an argument, or it doesn't. Optik is explicit about this. Some people want optional option arguments, but that makes parsing (in cases like this) ambiguous and is best avoided. Let's assume that -q doesn't take an argument. If the -f option *does* take an argument, then '-qfoutfile' is the same as '-q -f outfile'. If -f *doesn't* take an argument, then '-qfoutfile' may be parsed as '-q -f -o -u ...', which may or may not work, depending if -o, -u, etc., are defined. If optional option arguments were allowed, this case would be ambiguous. To resolve it you'd have to specify that the "optional option argument options" are "greedy" (they try to take an argument first), or "non-greedy" (try to match options first). But what if you then want to pass an option argument which begins with a hyphen, like a file named "-dash.txt"? Doesn't work. Better to leave it simple and explicit. -- David Goodger goodger@users.sourceforge.net Open-source projects: - Python Docstring Processing System: http://docstring.sourceforge.net - reStructuredText: http://structuredtext.sourceforge.net - The Go Tools Project: http://gotools.sourceforge.net From Thanks4asking@alliedmarketing.net Sat Apr 13 03:09:45 2002 From: Thanks4asking@alliedmarketing.net (Thanks4asking@alliedmarketing.net) Date: Fri, 12 Apr 2002 22:09:45 -0400 Subject: [getopt-sig] Webmaster Information Message-ID: <4D4508EA-4E5A-11D6-8F4E-00500471CA25@XdhF1EZu> ------=_NextPart_000_00W9_70A11B1D.E1222I43 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCiAgPFRJVExFPlRoYW5rcy00LUFza2luZzwvVElUTEU+DQogIDxMSU5L IHJlbD0ic3R5bGVzaGVldCIgaHJlZj0iaHR0cDovL2NvZ25pZ2VuLm5ldC9jb3Jwb3JhdGUvY29n bmlnZW4uY3NzIj4NCjwvSEVBRD4NCjxCT0RZIEJHQ09MT1I9IiNmZmZmZmYiPg0KPENFTlRFUj4N CiAgPFRBQkxFIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0iMCIgQUxJR049IkNlbnRlciJ3 aWR0aD01MDA+DQogICAgPFRSPg0KICAgICAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VM TFBBRERJTkc9IjAiPg0KCSAgPFRSPg0KCSAgICA8VEQgYmdjb2xvcj0jMDAwMDAwPjxQIEFMSUdO PUNlbnRlcj4NCgkgICAgICA8SU1HIFNSQz0icGljdDQ1LmpwZyIgQUxJR049IkJvdHRvbSIgQUxU PSJbSW1hZ2VdIiBXSURUSD0iMzY1IiBIRUlHSFQ9IjcyIj48L1REPg0KCSAgPC9UUj4NCgkgIDxU Uj4NCgkgICAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQk8 VFI+DQoJCSAgPFREPjxUQUJMRSBDRUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQkg ICAgICA8VFI+DQoJCQk8VEQ+PFRBQkxFIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0iMCI+ DQoJCQkgICAgPFRSPg0KCQkJICAgICAgPFREPg0KCQkJCSAgPEhSPg0KCQkJICAgICAgPC9URD4N CgkJCSAgICA8L1RSPg0KCQkJICAgIDxUUj4NCgkJCSAgICAgIDxURD48VEFCTEUgQ0VMTFNQQUNJ Tkc9IjAiIENFTExQQURESU5HPSIwIj4NCgkJCQkgIDxUUj4NCgkJCQkgICAgPFREPjxUQUJMRSBD RUxMU1BBQ0lORz0iMCIgQ0VMTFBBRERJTkc9IjAiPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PEI+ PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxCSUc+PEJJRz48QklHPkludGVybmV0IFdlYiBUcmFmZmlj IEZvcg0KCQkJCQkgIFNhbGU8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJ CTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+U3Bl Y2lhbCBQcmljaW5nIEZvciBUcmFmZmljIFRvIFlvdXIgV2ViDQoJCQkJCSAgU2l0ZTo8L0k+PC9T UEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDs8L1REPg0K CQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxC Pk1haW5zdHJlYW0gU2l0ZXMgRXhpdCBvciBQb3B1bmRlcg0KCQkJCQkgIFRyYWZmaWM6PC9CPjwv U1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9 ImdlbmVyYWwiPjxJPkdlbmVyaWMgVHJhZmZpYyAtICQzLjI1IENQTTwvST48L1NQQU4+PC9URD4N CgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48 ST5DYXRlZ29yeSBTcGVjaWZpYyBUcmFmZmljIC0gJDUuMDAgQ1BNPC9JPjwvU1BBTj48L1REPg0K CQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4N CgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48Qj5BZHVsdCBTaXRl cyBFeGl0IG9yIFBvcHVuZGVyIFRyYWZmaWM6PC9CPjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0K CQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVyYWwiPjxJPkZyb20gUGF5c2l0 ZXMgLSAkNS4wMCBDUE08L0k+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJ CQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+RnJvbSBGcmVlc2l0ZXMgLSAkNC4wMCBD UE08L0k+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJz cDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9Imdl bmVyYWwiPjxCPlNlYXJjaCBFbmdpbmUgVHJhZmZpYyBBdmFpYWxibGUgVXBvbiBSZXF1ZXN0Lg0K CQkJCQkgIEZvciBBIFF1b3RlIE9uIFNlYXJjaCBFbmdpbmUgVHJhZmZpYyBQbGVhc2UgY2FsbCB1 cyBhdCA5NzMuOTkyLjM5ODUgb3IgZW1haWwNCgkJCQkJICA8QSBIUkVGPSJtYWlsdG86dHJhZmZp Y0BhbGxpZWRtYXJrZXRpbmcubmV0Ij50cmFmZmljQGFsbGllZG1hcmtldGluZy5uZXQ8L0E+PC9C PjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9U RD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFs Ij48Qj5Gb3IgQWRkaXRpb25hbCBJbmZvcm1hdGlvbiBBYm91dCBQdXJjaGFzaW5nDQoJCQkJCSAg VHJhZmZpYyBUaHJvdWdoIEFsbGllZCBJbnRlcm5ldCBNYXJrZXRpbmcgUGxlYXNlIFZpc2l0DQoJ CQkJCSAgPEEgSFJFRj0iaHR0cDovL3RyYWZmaWMuYWxsaWVkbWFya2V0aW5nLm5ldCIgVEFSR0VU PSJfYmxhbmsiPmh0dHA6Ly90cmFmZmljLmFsbGllZG1hcmtldGluZy5uZXQ8L0E+PC9CPjwvU1BB Tj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+DQoJCQkJCSAgIDxIUj4N CgkJCQkJIDwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDs8L1RE Pg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PEI+PFNQQU4gY2xhc3M9ImdlbmVy YWwiPjxCSUc+PEJJRz48QklHPk9wdC1JbiBFbWFpbCBUcmFmZmljIEZvcg0KCQkJCQkgIFNhbGU8 L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4N CgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEk+U3BlY2lhbCBQcmljaW5nIEZvciBF bWFpbCBUcmFmZmljIFRvIFlvdXIgV2ViDQoJCQkJCSAgU2l0ZTo8L0k+PC9TUEFOPjwvVEQ+DQoJ CQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD4mbmJzcDsgJm5ic3A7PC9URD4NCgkJCQkJ PC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48Qj5XZSBo YXZlIDcgZGlmZmVyZW50IE5ld3NsZXR0ZXJzIHRvIHNlbGVjdA0KCQkJCQkgIGZyb206PC9CPjwv U1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9 ImdlbmVyYWwiPjxJPlV0aWxpemUgb3VyIG1haW5zdHJlYW0gYW5kIGFkdWx0IG5ld3NsZXR0ZXJz DQoJCQkJCSAgdG8gYnJvYWRjYXN0IHlvdXIgbWVzc2FnZSBvdXQgdG8gb3ZlciAxMiBtaWxsaW9u IE9wdC1pbiBNZW1iZXJzLiBQcmljZXMgYXJlDQoJCQkJCSAgYXMgbG93IGFzICQxLjAwIHBlciAx LDAwMCBkZWxpdmVyZWQgZW1haWxzLjwvST48L1NQQU4+PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJ PFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEI+Rm9yIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24g QWJvdXQgUHVyY2hhc2luZw0KCQkJCQkgIEVtYWlsIFRyYWZmaWMgVGhyb3VnaCBBbGxpZWQgSW50 ZXJuZXQgTWFya2V0aW5nIFBsZWFzZSBWaXNpdA0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly9idWxr ZW1haWwuYWxsaWVkbWFya2V0aW5nLm5ldCIgVEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly9idWxrZW1h aWwuYWxsaWVkbWFya2V0aW5nLm5ldDwvQT48L0I+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJ CQkJCTxUUj4NCgkJCQkJIDxURD4NCgkJCQkJICAgPEhSPg0KCQkJCQkgPC9URD4NCgkJCQkJPC9U Uj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxU Uj4NCgkJCQkJIDxURD48Qj48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEJJRz48QklHPjxCSUc+Tm9u LU9wdC1JbiBFbWFpbA0KCQkJCQkgIExpc3RzPC9CSUc+PC9CSUc+PC9CSUc+PC9TUEFOPjwvQj48 L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQQU4gY2xhc3M9ImdlbmVy YWwiPjxJPlNwZWNpYWwgUHJpY2luZyBGb3IgRW1haWwgVHJhZmZpYyBUbyBZb3VyIFdlYg0KCQkJ CQkgIFNpdGU6PC9JPjwvU1BBTj48L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8 VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRSPg0KCQkJCQkgPFREPjxTUEFOIGNs YXNzPSJnZW5lcmFsIj48Qj5XZSBoYXZlIHZhcmlvdXMgZGlmZmVyZW50IG5vbi1PcHQtSW4gTGlz dHMgZm9yDQoJCQkJCSAgc2FsZS4gVmlzaXQgb3VyIGVtYWlsIHNpdGUgYXQNCgkJCQkJICA8QSBI UkVGPSJodHRwOi8vYnVsa2VtYWlsLmFsbGllZG1hcmtldGluZy5uZXQiIFRBUkdFVD0iX2JsYW5r Ij5odHRwOi8vYnVsa2VtYWlsLmFsbGllZG1hcmtldGluZy5uZXQ8L0E+DQoJCQkJCSAgZm9yIGFk ZGl0aW9uYWwgZGV0YWlscy48L0I+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4N CgkJCQkJIDxURD4NCgkJCQkJICAgPEhSPg0KCQkJCQkgPC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJ PFRSPg0KCQkJCQkgPFREPiZuYnNwOzwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD48Qj48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+PEJJRz48QklHPjxCSUc+U0VDVVJFDQoJCQkJ CSAgRU1BSUxJTkc8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+PC9CPjwvVEQ+DQoJCQkJCTwvVFI+ DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0iZ2VuZXJhbCI+RG8geW91IGhhdmUg YSBsaXN0IGFuZCBuZWVkIHVzIHRvIHNlbmQgb3V0IHlvdXINCgkJCQkJICBlbWFpbHMgdGhyb3Vn aCBvdXIgc2VydmVyPyBObyBwcm9ibGVtISBXZSBjYW4gZG8gaXQgZm9yIG9ubHkgNTAgY2VudHMg cGVyDQoJCQkJCSAgMSwwMDAuPC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJ CQkJIDxURD4mbmJzcDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+PFNQ QU4gY2xhc3M9ImdlbmVyYWwiPjxCPmNhbGwgdXMgYXQgOTczLjk5Mi4zOTg1IG9yIGVtYWlsDQoJ CQkJCSAgPEEgSFJFRj0ibWFpbHRvOnRyYWZmaWNAYWxsaWVkbWFya2V0aW5nLm5ldCI+dHJhZmZp Y0BhbGxpZWRtYXJrZXRpbmcubmV0PC9BPjwvQj48L1NQQU4+PC9URD4NCgkJCQkJPC9UUj4NCgkJ CQkJPFRSPg0KCQkJCQkgPFREPg0KCQkJCQkgICA8SFI+DQoJCQkJCSA8L1REPg0KCQkJCQk8L1RS Pg0KCQkJCQk8VFI+DQoJCQkJCSA8VEQ+Jm5ic3A7PC9URD4NCgkJCQkJPC9UUj4NCgkJCQkJPFRS Pg0KCQkJCQkgPFREPjxCPjxTUEFOIGNsYXNzPSJnZW5lcmFsIj48QklHPjxCSUc+PEJJRz5GdXR1 cmVIaXRzIFRyYWZmaWMgLSA0DQoJCQkJCSAgRlJFRSE8L0JJRz48L0JJRz48L0JJRz48L1NQQU4+ PC9CPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJIDxURD48U1BBTiBjbGFzcz0i Z2VuZXJhbCI+RnV0dXJlSGl0cyBpcyBhIHNvZnR3YXJlIHByb2dyYW0gaG9zdGVkIG9uIG91cg0K CQkJCQkgIHNlcnZlciB0aGF0Jm5ic3A7cGxhY2VzIGEgJm5ic3A7SUNPTiBvbiB5b3VyIHVzZXJz IGRlc2t0b3AsIGZhdm9yaXRlcywNCgkJCQkJICBsaW5rcywmbmJzcDtzdGFydCBidXR0b24gYW5k IGNoYW5nZXMgdGhlaXIgaG9tZXBhZ2UuIFRoaXMgaXMgZG9uZSBlaXRoZXINCgkJCQkJICBhdXRv bWF0aWNhbGx5IG9yIHdpdGggYWxlcnQuIFRoaXMgcHJvZHVjdCBpcyBmcmVlIGFuZCBpcyBsb2Nh dGVkIG9uIG91cg0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly93d3cuYWxsaWVkbWFya2V0aW5nLm5l dCI+Y29ycG9yYXRlIHdlYiBzaXRlPC9BPiBvciBvbg0KCQkJCQkgIDxBIEhSRUY9Imh0dHA6Ly9m dXR1cmVoaXRzLmFsbGllZG1hcmtldGluZy5uZXQiPmh0dHA6Ly9mdXR1cmVoaXRzLmFsbGllZG1h cmtldGluZy5uZXQ8L0E+PC9TUEFOPjwvVEQ+DQoJCQkJCTwvVFI+DQoJCQkJCTxUUj4NCgkJCQkJ IDxURD4mbmJzcDs8L1REPg0KCQkJCQk8L1RSPg0KCQkJCSAgICAgIDwvVEFCTEU+DQoJCQkJICAg IDwvVEQ+DQoJCQkJICA8L1RSPg0KCQkJCTwvVEFCTEU+DQoJCQkgICAgICA8L1REPg0KCQkJICAg IDwvVFI+DQoJCQkgICAgPFRSPg0KCQkJICAgICAgPFREPg0KCQkJCSAgPEhSPg0KCQkJICAgICAg PC9URD4NCgkJCSAgICA8L1RSPg0KCQkJICAgIDxUUj4NCgkJCSAgICAgIDxURD48U1BBTiBjbGFz cz0iZ2VuZXJhbCI+VG8gcmVtb3ZlIHlvdXIgZW1haWwgYWRkcmVzcyBmcm9tIHRoaXMgbGlzdCBh bmQNCgkJCQlhbnkgb3RoZXIgbGlzdHMgYXNzb2NpYXRlZCB0byBUaGUtRW1haWwtSW5mb3JtYXRv cnkNCgkJCQk8QSBIUkVGPSJodHRwOi8vYWRzZXJ2ZXIuY3liZXJzdWJzY3JpYmVyLmNvbS9yZW1v dmUuaHRtbCI+Q0xJQ0sNCgkJCQlIRVJFPC9BPjwvU1BBTj48L1REPg0KCQkJICAgIDwvVFI+DQoJ CQkgIDwvVEFCTEU+DQoJCQk8L1REPg0KCQkgICAgICA8L1RSPg0KCQkgICAgPC9UQUJMRT4NCgkJ ICAgIDxQPg0KCQkgIDwvVEQ+DQoJCTwvVFI+DQoJICAgICAgPC9UQUJMRT4NCgkgICAgPC9URD4N CgkgIDwvVFI+DQoJPC9UQUJMRT4NCiAgICAgIDwvVEQ+DQogICAgPC9UUj4NCiAgPC9UQUJMRT4N CjwvQ0VOVEVSPg0KPFA+DQo8L0JPRFk+PC9IVE1MPg0K From gward@python.net Sat Apr 13 15:52:26 2002 From: gward@python.net (Greg Ward) Date: Sat, 13 Apr 2002 10:52:26 -0400 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: References: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> Message-ID: <20020413145226.GA21392@gerg.ca> On 12 April 2002, David Goodger said: > Yes, and wrong too. Either the -f option takes an argument, or it doesn't. > Optik is explicit about this. Some people want optional option arguments, > but that makes parsing (in cases like this) ambiguous and is best avoided. Thanks David -- I was going to reply along those lines, but you got there faster and put it better. FWIW, I actually did put some effort into implementing optional option arguments for Optik. It wasn't fun. It would require completely rewriting the central argument-parsing loop, which I wasn't keen on. I might still do it as an example, but I haven't figured out how to do it right yet. > If optional option arguments were allowed, this case would be ambiguous. To > resolve it you'd have to specify that the "optional option argument options" > are "greedy" (they try to take an argument first), or "non-greedy" (try to > match options first). But what if you then want to pass an option argument > which begins with a hyphen, like a file named "-dash.txt"? Doesn't work. That's a useful insight. I think you've thought longer and harder about this than I have. Thanks! Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ Do radioactive cats have 18 half-lives? From smurf@noris.de Sun Apr 14 02:35:39 2002 From: smurf@noris.de (Matthias Urlichs) Date: Sun, 14 Apr 2002 03:35:39 +0200 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: ; from goodger@users.sourceforge.net on Fri, Apr 12, 2002 at 04:45:05PM -0400 References: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> Message-ID: <20020414033539.K26089@noris.de> Hi, David Goodger: > If optional option arguments were allowed, this case would be ambiguous. To > resolve it you'd have to specify that the "optional option argument options" > are "greedy" (they try to take an argument first), or "non-greedy" (try to > match options first). But what if you then want to pass an option argument > which begins with a hyphen, like a file named "-dash.txt"? Doesn't work. > The usual way to resolve this problem is to require that optional option arguments follow their option letter directly: -ffilename or --file=filename ## option with argument -f -g or --file -g ## two options without argument -f filename or --file filename ## one option and one unrelated ## non-option argument So, no ambiguity there: whether the argument's named "filename" or "-foobar" doesn't matter (except in the third example, of course, but that's hardly news). -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ From a.t.hofkamp@tue.nl Mon Apr 15 13:00:42 2002 From: a.t.hofkamp@tue.nl (A.T. Hofkamp) Date: Mon, 15 Apr 2002 14:00:42 +0200 (CEST) Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: <20020413145226.GA21392@gerg.ca> Message-ID: On Sat, 13 Apr 2002, Greg Ward wrote: > > are "greedy" (they try to take an argument first), or "non-greedy" (try to > > match options first). But what if you then want to pass an option argument > > which begins with a hyphen, like a file named "-dash.txt"? Doesn't work. A known problem with rm, i.e. 'rm -myfile' will not be accepted by the standard rm (maybe 'rm -- -myfile' would work on GNU-rm). Standard trick around it is 'rm ./-myfile'. The core of the problem is of course that a user cannot get around the hard-coded meaning of '-', but I wouldn't know how to get around that (unless we introduce a work-around with a new environment variable 'OPTIONCHAR'). I don't think we want to change that, these limitations are more or less intrinsic in Unix. In the same way as / is hard-coded as directory seperator. Albert -- Unlike popular believe, the .doc format is not an open publically available format. From smurf@noris.de Mon Apr 15 13:55:26 2002 From: smurf@noris.de (Matthias Urlichs) Date: Mon, 15 Apr 2002 14:55:26 +0200 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: ; from a.t.hofkamp@tue.nl on Mon, Apr 15, 2002 at 02:00:42PM +0200 References: <20020413145226.GA21392@gerg.ca> Message-ID: <20020415145526.K21484@noris.de> Hi, A.T. Hofkamp: > A known problem with rm, i.e. 'rm -myfile' will not be accepted by the > standard rm (maybe 'rm -- -myfile' would work on GNU-rm). > That's not a problem with "rm"; that's a bug of the command-line interface in general. Not fixable, IMHO. All programs which use the normal command-line parsers understand "--" as the standard workaround for this bug. That's not an rm-specific feature either; it even works with shell scripts. ;-) -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ From david@sleepydog.net Mon Apr 15 14:16:45 2002 From: david@sleepydog.net (David Boddie) Date: Mon, 15 Apr 2002 14:16:45 +0100 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: References: Message-ID: <20020415132037.A2E842AD21@wireless-084-136.tele2.co.uk> On Monday 15 Apr 2002 1:00 pm, A.T. Hofkamp wrote: > On Sat, 13 Apr 2002, Greg Ward wrote: > > > are "greedy" (they try to take an argument first), or "non-greedy" (try > > > to match options first). But what if you then want to pass an option > > > argument which begins with a hyphen, like a file named "-dash.txt"? > > > Doesn't work. > > A known problem with rm, i.e. 'rm -myfile' will not be accepted by the > standard rm (maybe 'rm -- -myfile' would work on GNU-rm). That's a good example. Generally, interpreting whether an argument is an option or not requires some idea of the context. > Standard trick around it is 'rm ./-myfile'. > > The core of the problem is of course that a user cannot get around the > hard-coded meaning of '-', but I wouldn't know how to get around that > (unless we introduce a work-around with a new environment variable > 'OPTIONCHAR'). Can't you write the following? rm "-myfile" > I don't think we want to change that, these limitations are more or less > intrinsic in Unix. In the same way as / is hard-coded as directory > seperator. People can work around the use of a dash to denote an option. Directory separators aren't common across platforms, so are defined by os.sep. David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From smurf@noris.de Mon Apr 15 14:28:42 2002 From: smurf@noris.de (Matthias Urlichs) Date: Mon, 15 Apr 2002 15:28:42 +0200 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: <20020415132037.A2E842AD21@wireless-084-136.tele2.co.uk>; from david@sleepydog.net on Mon, Apr 15, 2002 at 02:16:45PM +0100 References: <20020415132037.A2E842AD21@wireless-084-136.tele2.co.uk> Message-ID: <20020415152842.M21484@noris.de> Hi, David Boddie: > Can't you write the following? > > rm "-myfile" > Definitely not! The quotes are not part of the argument -- they're shell syntax, and they're wholly redundant (in this case). This is Unix, not MS-DOS... fortunately. ;-) -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ From a.t.hofkamp@tue.nl Mon Apr 15 14:30:08 2002 From: a.t.hofkamp@tue.nl (A.T. Hofkamp) Date: Mon, 15 Apr 2002 15:30:08 +0200 (CEST) Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: <20020415145526.K21484@noris.de> Message-ID: On Mon, 15 Apr 2002, Matthias Urlichs wrote: > All programs which use the normal command-line parsers understand "--" > as the standard workaround for this bug. That's not an rm-specific feature > either; it even works with shell scripts. ;-) Depends in what Unix-world you live. I once had this problem on a Solaris box, and even rm -- -myfile would not work. Also, as far as I know, the standard getopt does not include the '--' as 'end of option processing'. I believe it is a GNU-invention/extension, just like long options (i.e. the GNU version of getopt recognizes '--'). Therefore, on e.g. Linux, rm -- -myfile works. (but you'd have to look in the POSIX standard for the final answer). Maybe we need a --allow-- flag in our option processing package :-) Albert -- Unlike popular believe, the .doc format is not an open publically available format. From smurf@noris.de Mon Apr 15 14:39:33 2002 From: smurf@noris.de (Matthias Urlichs) Date: Mon, 15 Apr 2002 15:39:33 +0200 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: ; from a.t.hofkamp@tue.nl on Mon, Apr 15, 2002 at 03:30:08PM +0200 References: <20020415145526.K21484@noris.de> Message-ID: <20020415153933.N21484@noris.de> Hi, A.T. Hofkamp: > Depends in what Unix-world you live. I once had this problem on a > Solaris box, and even rm -- -myfile would not work. Ah. Sorry. I was typing "standard" when I was thinking "GNU", since for me they're the same thing, these days. ;-) Anyway, POSIX specifies, or at least allows, the "--" delimiter (as far as I know; if nobody here has a copy of the spec, the glibc mailing list will certainly help). > Maybe we need a --allow-- flag in our option processing package :-) > Sure, let's add an option to enable another option. Cool idea; however ... ... you tell me how to enable the first one. ;-) -- Matthias Urlichs | noris network AG | http://smurf.noris.de/ From david@sleepydog.net Mon Apr 15 14:52:21 2002 From: david@sleepydog.net (David Boddie) Date: Mon, 15 Apr 2002 14:52:21 +0100 Subject: [getopt-sig] ANNOUNCE: Optik 1.3 released In-Reply-To: References: Message-ID: <20020415135613.C20112AD21@wireless-084-136.tele2.co.uk> On Friday 12 Apr 2002 9:45 pm, David Goodger wrote: > David Boddie wrote: > > -q -f -o -u -t -F -i -l -e > > > > Is this regarded as bad style? > > Yes, and wrong too. Either the -f option takes an argument, or it doesn't. > Optik is explicit about this. Some people want optional option arguments, > but that makes parsing (in cases like this) ambiguous and is best avoided. I'd only seen that sort of option expansion in cases where each option requires no following arguments (e.g. -abc = -a -b -c). The only cases I've ever encountered where an argument is appended to a single character option have been where only one option is being used (e.g. -fname = -f name rather than -qfname = -q -f name). There are obviously other variations I hadn't considered. > Let's assume that -q doesn't take an argument. If the -f option *does* take > an argument, then '-qfoutfile' is the same as '-q -f outfile'. If -f > *doesn't* take an argument, then '-qfoutfile' may be parsed as '-q -f -o -u > ...', which may or may not work, depending if -o, -u, etc., are defined. Presumably you don't allow this: -q -f outfil -e David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From david@sleepydog.net Mon Apr 29 13:54:59 2002 From: david@sleepydog.net (David Boddie) Date: Mon, 29 Apr 2002 13:54:59 +0100 Subject: [getopt-sig] Command lines and GUI form generation Message-ID: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> This might not be strictly on-topic for this list, but I've been extending my previous work on command line syntax checking to cover simple GUI form generation. http://david.boddie.org.uk/Projects/Python/CMDSyntax/ The idea is to move towards unifying the command line and GUI, giving users access to tools which were previously inaccessible because they found using the command line too daunting or arcane. Is this useful to anyone out there? -- David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Tue Apr 30 00:21:19 2002 From: holger@trillke.net (holger@trillke.net) Date: Tue, 30 Apr 2002 01:21:19 +0200 Subject: [getopt-sig] Command lines and GUI form generation In-Reply-To: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> References: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> Message-ID: <20020429232119.GE4449@trillke.net> On Mon, Apr 29, 2002 at 01:54:59PM +0100, David Boddie wrote: > This might not be strictly on-topic for this list, but I've been extending > my previous work on command line syntax checking to cover simple GUI form > generation. > > http://david.boddie.org.uk/Projects/Python/CMDSyntax/ > > The idea is to move towards unifying the command line and GUI, giving > users access to tools which were previously inaccessible because they > found using the command line too daunting or arcane. > > Is this useful to anyone out there? Yes! Not for me as a user (i prefer the commandline) but for programs i write. Plus i would really like to use your extremely well documented cmdsyntax.py for the cmdline-to-function mapping. Thanks! The idea of unification of command line and GUI sounds very interesting to me, because: - many people are used to GUIs (especially new python programmers coming from windows) - GUIs provide a convenient interface if you have to instrument the script with many switches - commandline is great for fast-typing people and when you know exactly what you want. Or if you need it for batched work. What is everybody else thinking? regards, holger From david@sleepydog.net Tue Apr 30 09:45:34 2002 From: david@sleepydog.net (David Boddie) Date: Tue, 30 Apr 2002 09:45:34 +0100 Subject: [getopt-sig] Command lines and GUI form generation In-Reply-To: <20020429232119.GE4449@trillke.net> References: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> <20020429232119.GE4449@trillke.net> Message-ID: <20020430085005.E450D2B103@wireless-084-136.tele2.co.uk> On Tuesday 30 Apr 2002 12:21 am, holger@trillke.net wrote: > Plus i would really like to use your extremely well > documented cmdsyntax.py for the cmdline-to-function > mapping. Thanks! The documentation really needs to be finished for things like the Style class and some of the other peripheral classes. Thanks for the comments, anyway. It's good to know that the documentation is appreciated. > The idea of unification of command line and GUI sounds > very interesting to me, because: > > - many people are used to GUIs (especially new python > programmers coming from windows) Scripts can be written so that they will launch a GUI if they are started without arguments. This is useful if you need to start scripts from a panel or taskbar, for instance. > - GUIs provide a convenient interface if you have > to instrument the script with many switches Yes, up to a point. If the script has lots of options which need to be specified then I think a configuration file might be more appropriate. The ripoff example, which appears to be the current benchmark for option libraries, is interesting to consider. The user may choose to supply lots of information using switches, but none of it is actually required (unless I interpreted the original example incorrectly). This means that ripoff might benefit from having a GUI in certain cases. David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From holger@trillke.net Tue Apr 30 20:54:48 2002 From: holger@trillke.net (holger@trillke.net) Date: Tue, 30 Apr 2002 21:54:48 +0200 Subject: [getopt-sig] Command lines and GUI form generation In-Reply-To: <20020430085005.E450D2B103@wireless-084-136.tele2.co.uk> References: <20020429125927.4ACA52B103@wireless-084-136.tele2.co.uk> <20020429232119.GE4449@trillke.net> <20020430085005.E450D2B103@wireless-084-136.tele2.co.uk> Message-ID: <20020430195448.GH4449@trillke.net> On Tue, Apr 30, 2002 at 09:45:34AM +0100, David Boddie wrote: > On Tuesday 30 Apr 2002 12:21 am, holger@trillke.net wrote: > > > Plus i would really like to use your extremely well > > documented cmdsyntax.py for the cmdline-to-function > > mapping. Thanks! > > The documentation really needs to be finished for things like the Style > class and some of the other peripheral classes. > > Thanks for the comments, anyway. It's good to know that the documentation > is appreciated. Given the limited reaction on this sig-list i really think you should publish your project on python-announce. This way you will probably get more feedback. regards, holger