I expected subprocess.list2cmdline() to convert my list of arguments
into a command line which results in behavior equivalent to the Unix
exec() functions -- that is, that I can safely pass arbitrary characters
to it and it'll make it such that those characters are escaped.  It
looks to me, though, like it doesn't handle the pipe symbol, so that if
I call list2cmdline(['echo', 'foo|bar']), I get the command line 'echo
foo|bar' instead of 'echo "foo|bar"' as I would expect.

If this is actually a result of my misunderstanding (or if it's fixed in
a more recent version), please accept my apologies.

fixed in trunk r60115 (2.6).

I reverted r60115 from trunk (2.7) in r82075 and from py3k in r82076.

Why is this bug invalid?

See the commit message for r82075 and the discussion on issue8972 and issue7839.

Hm, I'm not sure I understand.  After r82075, will list2cmdline(['echo', 'foo|bar']) return 'echo foo|bar', or will it return 'echo "foo|bar"'?

It will return the former.

To clarify, it's true that there appears to be a problem with Popen(['echo', 'foo|bar'], shell=True).  That is being tracked in issue7839.

What's invalid is the report that list2cmdline() should be quoting strings with | in them.  list2cmdline() is documented as being an implementation of the quoting convention implemented by the MS C runtime.  That quoting convention does not require | to be quoted.

It's cmd.exe which requires | to be quoted (if it is to be part of an argument value, rather than to indicate a command pipeline of some sort).  cmd.exe quoting rules need to be addressed separately from the MS C quoting rules used even if cmd.exe isn't involved.

Okay, makes sense.  It sure would be nice on Windows to have an equivalent of list2cmdline() that works for the shell.  I actually don't have immediate access to the code anymore, but I remember having to fool around with list2cmdline in the first place because it was difficult to do what I wanted without passing things through the shell (maybe I was spawning a process on Windows and capturing input/output/stderr; I don't remember in detail).

Maybe the solution is to make what I was trying to do easier without fooling with the shell instead of playing the fool's game of trying to improve the ability to deal with the shell so we can pass things through it unnecessarily.

Anyway, thanks.