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.