subprocess.run(capture_output=Bool) does the opposite of expected

[DragonEggBedrockBreaking]

BPO	45048
Nosy	@eryksun, @vedgar

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-08-30.09:16:19.605>
created_at = <Date 2021-08-29.21:12:54.167>
labels = ['invalid', 'library', '3.9']
title = 'subprocess.run(capture_output=Bool) does the opposite of expected'
updated_at = <Date 2021-08-30.09:16:19.604>
user = 'https://bugs.python.org/DragonEggBedrockBreaking'

bugs.python.org fields:

activity = <Date 2021-08-30.09:16:19.604>
actor = 'DragonEggBedrockBreaking'
assignee = 'none'
closed = True
closed_date = <Date 2021-08-30.09:16:19.605>
closer = 'DragonEggBedrockBreaking'
components = ['Library (Lib)']
creation = <Date 2021-08-29.21:12:54.167>
creator = 'DragonEggBedrockBreaking'
dependencies = []
files = []
hgrepos = []
issue_num = 45048
keywords = []
message_count = 5.0
messages = ['400561', '400562', '400564', '400565', '400583']
nosy_count = 3.0
nosy_names = ['eryksun', 'veky', 'DragonEggBedrockBreaking']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue45048'
versions = ['Python 3.9']

[DragonEggBedrockBreaking]

If you run subprocess.run(capture_output=True), it doesn't show output, but if you run subprocess.run(capture_output=False) (or if you just run subprocess.run() since False is default), it does show output. In the example in the docs, it shows this in the examples section:

>>> subprocess.run(["ls", "-l"])  # doesn't capture output
CompletedProcess(args=['ls', '-l'], returncode=0)

>>> subprocess.run(["ls", "-l", "/dev/null"], capture_output=True)
CompletedProcess(args=['ls', '-l', '/dev/null'], returncode=0,
stdout=b'crw-rw-rw- 1 root root 1, 3 Jan 23 16:23 /dev/null\n', stderr=b'')

This clearly shows capture_output showing output if true but not if false. Test code:

import subprocess
subprocess.run("dir", shell=True, capture_output=False)
subprocess.run("dir", shell=True, capture_output=False)

Other notes: for some reason I get an error if I don't add shell=True, so maybe that contributes? I am on Windows 10 if that matters.

[vedgar]

I think it is exactly what "capture" means: "not allow it to escape" (to the console). Maybe you should read the documentation?

[DragonEggBedrockBreaking]

I read the documentation, and I saw in the example that when capture_output was true, command output was printed, otherwise it isn't printed. my observations directly contradict the examples given in the docs, as stated in my original issue.

[eryksun]

The documentation states that "[i]f capture_output is true, stdout and stderr will be captured". This implies a container of some kind. So look to what subprocess.run() returns: "[w]ait for command to complete, then return a CompletedProcess instance". The stdout attribute of a CompletedProcess is the "[c]aptured stdout from the child process".

For example:

    >>> p = subprocess.run("dir", shell=True, capture_output=True)
    >>> p.stdout[:18]
    b' Volume in drive C'

If the output is not captured, the child process inherits the standard output/error files of the parent process, which is typically a console or terminal.

FYI, the dir command is internal to the CMD shell in Windows, so it only works with shell=True. There is no "dir.exe" executable that can be executed with shell=False.

[DragonEggBedrockBreaking]

Ok, thanks, I understand now.