[Python-Dev] Python long command line options
Heiko Wundram
me+python-dev at modelnine.org
Thu May 4 08:29:52 CEST 2006
Hi all!
Martin von Löwis said that it'd be necessary to discuss a patch to Python's
ability to parse command-line parameters to the interpreter here, and I
thought I might start the ball rolling.
The associated patch of mine is:
http://sourceforge.net/tracker/index.php?func=detail&aid=1481112&group_id=5470&atid=305470
which refers to:
http://groups.google.de/group/comp.lang.python/browse_thread/thread/e3db1619040d7c6c/3c119e09122c83ed?hl=de#3c119e09122c83ed
(sorry for the long URLs, tinyurl isn't working for me at the moment...)
The patch itself is an extension of the Python/getopt.c module to handle long
command-line parameters (including option data passed as --<name>=<data>),
which are specified in the optstring as:
"<shortopt>[(longopt)][:]"
for example:
"V(version)"
or
"c(command):"
The patch doesn't change behaviour on old optstrings, except where an old
optstring relied on the fact that one of :, (, ) are valid parameter names
(because of the unconditional strchr to find the option name). I've not found
any reference to _PyOS_GetOpt besides the one in Modules/main.c, so I don't
think this change in behaviour breaks any existing code. The patch relies
only on usability of strchr (which the old getopt.c did too), removes a usage
of strcmp which was completely unneccesary, fixes some checks which were
unneccesarily broad (>= replaced by ==), and compilation doesn't show any
warnings on gcc 3.4.6; as for Windows (and MSVC), I don't have the means to
test there.
The current patch offers prefix matching: when an option is only specified
with a significant amount of prefix characters which doesn't match any other
long option, the patch assumes that the user meant this option. For example:
--ver
would also be interpreted as command-line parameter
--version
just as would
--v
--ve
--vers
--versi
--versio
if there are no other long options that start with the corresponding prefix.
This "trick" is easy enough to remove from the sources, though, so that only
correctly spelled options are actually returned.
Anyway, back on topic, I personally agree with the people who posted to
comp.lang.python that --version (and possibly --help, possibly other long
parameters too) would be useful additions to Pythons command-line parameters,
as it's increasingly getting more common amongst GNU and BSD utilities to
support these command-line options to get information about the utility at
hand (very popular amongst system administrators) and to use long commandline
options to be able to easily see what an option does when encountered in a
shell script of some sort.
And, as this doesn't break any old code (-V isn't going away by the patch), I
personally find this to be a very useful change.
Your thoughts?
--- Heiko.
More information about the Python-Dev
mailing list