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 eric.araujo
Recipients eric.araujo, eric.smith, robodan
Date 2011-11-24.16:20:40
SpamBayes Score 2.4511e-05
Marked as misclassified No
Message-id <>
Thanks for the comments.

> There are really two cases in one bug.
> The first part is that the shell will split tokens at characters that shlex doesn't.  The handling
> of &, |, ;, >, and < could be done by adjusting the definition of shlex.wordchars.  The shell may
> also understands things like: &&, ||, |&, and >&.  The exact definition of these depends on the
> shell, so maybe it's best to just split them out as separate tokens and let the user figure out the
> compound meanings.
Yes.  I think that the main use of shlex is really to parse a line into chunks with a way to embed spaces; it’s intended to parse a program command line (“prog --blah "value stillthesamevalue" "arg samearg"”), but not necessarily a full shell line (with & and | and whatnot).  When people have a line containing & and |, then they need a shell to execute it, so they would not call shlex.split but just pass the full line to os.system or subprocess.Popen.  Do you remember what use cases you had when you opened this report?

> The proper handling of quotes/escapes requires some kind of new interface.  You need to distinguish
> between tokens that were modified by the quote/escape rules and those that were not.
I don’t see why I would care about quotes in the result of shlex.split.

See also #7611.
Date User Action Args
2011-11-24 16:20:42eric.araujosetrecipients: + eric.araujo, eric.smith, robodan
2011-11-24 16:20:41eric.araujosetmessageid: <>
2011-11-24 16:20:41eric.araujolinkissue1521950 messages
2011-11-24 16:20:40eric.araujocreate