Thanks for the diff and test.  (I removed the older versions; there are “edit” links in the list of files leading to pages where it’s possible to remove them, if one has the required permissions.)

Your script passes with dash, which is probably the most POSIX-compliant shell we can find.  (bash has extensions, zsh/csh don’t use the POSIX shell language, so I think the behavior of dash should be our reference, not the bash man page.)

> I may be able to convince people that the current behaviour is wrong, but I can't tell you what will
> break if it is "fixed".  And should the fix be the default?  As you mentioned, it depends on what
> people expect it to do and how it is currently being used.

python-dev takes compatibility seriously.  Some things are clearly bugs and we fix them, even if it will break buggy code out there.  For example, we recently fixed bugs in HTML parsing: We had a specification to decide that they were really bugs, and we judged that no sane program could be relying on the exact behavior of the parser.  shlex is another case; in my opinion, it’s been used for years to implement parsing similar, but not identical in all cases, to the shell’s, and as there is code out there that depends on the current behavior of shlex and does not need to support && || ; ( ), if we add support for these tokens we should not break the existing code.  Given that we can’t test all programs that use shlex, I think we’ll have to add a new parameter, with a default value which gets us the previous behavior, as I said in my previous message.

(BTW, would you mind editing the quoted section when you reply by email?  Otherwise we get unhelpful, distracting walls of quoted texts.  Thanks in advance.)