This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skilletaudio
Recipients andersk, bethard, davidben, drm, eric.araujo, eric.smith, gdb, nelhage, r.david.murray, skilletaudio
Date 2011-12-28.18:15:41
SpamBayes Score 3.5621506e-13
Marked as misclassified No
Message-id <1325096142.86.0.306567984083.issue9334@psf.upfronthosting.co.za>
In-reply-to
Content
I have encountered this issue(python 2.7) with respect to positional arguments that begin with a dash (linux/ bash).

In the following example, the parser requires three positional arguments. I attempted to encase the arguments in single-quotes as that is expected in general to result in strings to be correctly handled (these args are API keys, so they could contain shell-unfriendly chars like - and &).

./tool.py  arg1 'arg2' '-arg3&otherstuff' 

You'll note there are no optional arguments in this example, it just boils down to a positional argument being broken up on parse.

Needless to say it was quite confusing to see the script complain after passing in what would typically be perfectly valid strings in most other apps / scripts.

Is it possible to get argparse to correctly notice and handle shell-appropriate single-quoting methods(dont break down a string that has been implied as a complete token via ' ')

As it stands, it appears I have two workaround options: 1) adopt the ./tool.py -- <postional args> convention mentioned in this thread, or 2) escape leading dashes in positional argument strings to avoid this issue.
History
Date User Action Args
2011-12-28 18:15:43skilletaudiosetrecipients: + skilletaudio, bethard, eric.smith, eric.araujo, r.david.murray, andersk, gdb, nelhage, drm, davidben
2011-12-28 18:15:42skilletaudiosetmessageid: <1325096142.86.0.306567984083.issue9334@psf.upfronthosting.co.za>
2011-12-28 18:15:42skilletaudiolinkissue9334 messages
2011-12-28 18:15:41skilletaudiocreate