After thinking some more and re-reading the os.system doc, I am closing this. I think things are working exactly as documented, and in a way that will not be changed. The os.system doc initially says

1. "Execute the command (a string) in a subshell."

It does that.

2. "This is implemented by calling the Standard C function system(), and has the same limitations."

Read Standard C for more on that.

Nearly everything in os is a thin wrapper of operating system data and functions. Enhanced wrappers that add user-friendliness, go elsewhere.

3. "Changes to sys.stdin, etc. are not reflected in the environment of the executed command."

The sys module is Python-specific and has no effect on system functions. In particular, whether sys.stdout, initially copied from the process, is initally null or the terminal, Idle changing sys.stdout has no effect on os.system output, and it will not see it. This is, obviously, a known and expected limitation.

4. "If command generates any output, it will be sent to the interpreter standard output stream."

The interpreter process stdout is not sys.stdout. If it is null, bye-bye output.

The doc ends with

5. "The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function."

In other words, the limitations of os.system are known, and it is semi-deprecated, especially when it does not work as one would wish, and a replacement has been provided. The subprocess module is an example of an 'enhanced wrapper'.

6 "See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes."

These recipes are replacements for things that work. The .check_output method enables things that one could not very easily do before. I already gave examples of how to use it.