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 <holger@trillke.net>"
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:
<yourscript> -f outfile --quiet
<yourscript> -qfoutfile
<yourscript> --file=outfile -q
<yourscript> --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
<yourscript> -h
<yourscript> --help
and Optik will print out a brief summary of your script's optons:
usage: <yourscript> [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 <gward@python.net>
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:
>
> <yourscript> -f outfile --quiet
> <yourscript> -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
<yourscript> -qfoutFile
(noting the use of "F" to avoid duplicating "f") to be equivalent to
<yourscript> -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: <B8DCBF8C.215B4%goodger@users.sourceforge.net>
David Boddie wrote:
>> <yourscript> -f outfile --quiet
>> <yourscript> -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
>
> <yourscript> -qfoutFile
>
> (noting the use of "F" to avoid duplicating "f") to be equivalent to
>
> <yourscript> -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: <B8DCBF8C.215B4%goodger@users.sourceforge.net>
References: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> <B8DCBF8C.215B4%goodger@users.sourceforge.net>
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: <B8DCBF8C.215B4%goodger@users.sourceforge.net>; from goodger@users.sourceforge.net on Fri, Apr 12, 2002 at 04:45:05PM -0400
References: <20020412095949.7ADCF2AFB4@wireless-084-136.tele2.co.uk> <B8DCBF8C.215B4%goodger@users.sourceforge.net>
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: <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl>
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: <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl>; from a.t.hofkamp@tue.nl on Mon, Apr 15, 2002 at 02:00:42PM +0200
References: <20020413145226.GA21392@gerg.ca> <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl>
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: <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl>
References: <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl>
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: <Pine.LNX.4.33.0204151345310.8060-100000@se-46.wpa.wtb.tue.nl> <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: <Pine.LNX.4.33.0204151523050.8060-100000@se-46.wpa.wtb.tue.nl>
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: <Pine.LNX.4.33.0204151523050.8060-100000@se-46.wpa.wtb.tue.nl>; from a.t.hofkamp@tue.nl on Mon, Apr 15, 2002 at 03:30:08PM +0200
References: <20020415145526.K21484@noris.de> <Pine.LNX.4.33.0204151523050.8060-100000@se-46.wpa.wtb.tue.nl>
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: <B8DCBF8C.215B4%goodger@users.sourceforge.net>
References: <B8DCBF8C.215B4%goodger@users.sourceforge.net>
Message-ID: <20020415135613.C20112AD21@wireless-084-136.tele2.co.uk>
On Friday 12 Apr 2002 9:45 pm, David Goodger wrote:
> David Boddie wrote:
> > <yourscript> -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