How do I hide the console when I use os.system() or subprocess.call()?

python windows console subprocess

65,079

Solution 1

The process STARTUPINFO can hide the console window:

si = subprocess.STARTUPINFO()
si.dwFlags |= subprocess.STARTF_USESHOWWINDOW
#si.wShowWindow = subprocess.SW_HIDE # default
subprocess.call('taskkill /F /IM exename.exe', startupinfo=si)

Or set the creation flags to disable creating the window:

CREATE_NO_WINDOW = 0x08000000
subprocess.call('taskkill /F /IM exename.exe', creationflags=CREATE_NO_WINDOW)

The above is still a console process with valid handles for console I/O (verified by calling GetFileType on the handles returned by GetStdHandle). It just has no window and doesn't inherit the parent's console, if any.

You can go a step farther by forcing the child to have no console at all:

DETACHED_PROCESS = 0x00000008
subprocess.call('taskkill /F /IM exename.exe', creationflags=DETACHED_PROCESS)

In this case the child's standard handles (i.e. GetStdHandle) are 0, but you can set them to an open disk file or pipe such as subprocess.DEVNULL (3.3) or subprocess.PIPE.

Solution 2

Add the shell=True argument to the subprocess calls.

subprocess.call('taskkill /F /IM exename.exe', shell=True)

Or, if you don't need to wait for it, use subprocess.Popen rather than subprocess.call.

subprocess.Popen('taskkill /F /IM exename.exe', shell=True)

65,079

Author by

Synapse

Updated on July 05, 2022

Comments

Synapse almost 2 years
I wrote some statements like below:
```
os.system(cmd) #do something
subprocess.call('taskkill /F /IM exename.exe')
```
both will pop up a console.

How can I stop it from popping up the console?
Synapse almost 13 years

sorry, the stuff I want to invoke cannot be run by subprocess.Popen, coz exception raised "invalid win32 app". But os.system can run it without any warning.
ambagesia almost 13 years

Er, that's not a problem with subprocess; I can run it on Windows 7, natively (Python 2.7.2) as well as under Cygwin (Python 2.6.5), with no warnings.
Chris Morgan almost 13 years

Sure, the startupinfo technique works, but this one's shorter (but put a comment in to indicate why you're using shell=True otherwise it probably wouldn't be as obvious).
arifwn almost 12 years

Hmm, for some reason my executable not running when using shell=True. But it run just fine when using startupinfo.
Chris Morgan almost 12 years

@arifwn: post a new question, please.
Eryk Sun almost 11 years

+1 for brevity. This way has subprocess configure STARTUPINFO for you. Note that running via cmd /c should only be used with trusted commands. In this case it's OK.
moltenform almost 9 years

Not a good solution. shell=True does more than you want, and opens up security problems if the user can manipulate the input.
AXO over 8 years

Doesn't work for me, the console still pops up. Also the shell argument defaults to False. Explicitly passing it should not make a difference.
BuvinJ over 8 years

Don't we want shell=False? Aren't we hiding the console window?
Chris Morgan over 8 years

@BuvinJ: look at the code to see what it does. You’re misunderstanding the purpose of shell (look at the docs too). This answer is basically taking a side-effect of shell=True and using it.
BuvinJ over 8 years

Ok. Well, I first tried opening notepad in Windows with os.system. That displayed a console window. I tried subprocess.call per your post and it did not open that extra window. I set shell=False though. It worked for my purpose, and the official docs say not to use shell=True if you don't have to. (See jmnben's comment)
Chris Morgan over 8 years

@BuvinJ: notepad doesn’t open a console under any circumstances. It doesn’t use the console subsystem. We’re talking about processes that do use the console subsystem, and stopping them from showing a console window.
BuvinJ over 8 years

I see. Sorry about that. I was looking to prevent the command prompt window from popping up when I ran a simple exe. This fixed that as well!
Cyan about 8 years

creationflags=CREATE_NO_WINDOW does no seem to be very portable
Eryk Sun about 8 years

@Cyan, in what sense is CREATE_NO_WINDOW not portable? This is a Windows question, and these flags should be supported in all versions of Windows NT, from 3.1 to Windows 10.
MandyShaw over 5 years

Hi, please provide some additional narrative to explain how this answers the question. Thanks.
Harmon758 over 5 years

Python 3.7 now has subprocess.CREATE_NO_WINDOW
Eryk Sun over 5 years

@Harmon758, I'm aware. The priority-class creation flags were being added, and I suggested that we may as well add some of the others, including the console flags CREATE_NO_WINDOW and DETACHED_PROCESS and two others that are unrelated to the console -- CREATE_BREAKAWAY_FROM_JOB and CREATE_DEFAULT_ERROR_MODE.
Harmon758 over 5 years

@eryksun My apologies, I didn't mean to imply that you weren't already aware of its existence. I didn't see it mentioned here yet, so I wanted to provide the information to anyone who came across this issue, since this answer has high visibility for it.
Eryk Sun over 5 years

@Harmon758, it's going to be a while before code can rely on them, since scripts may have to support 3.5, 3.6, and even 2.7. But I wanted to at least get them in the docs for visibility.
Owen over 5 years

Just FYI, this solution might make the child not see that its input has closed if the parent Python program closes the input pipe.
neferjina about 5 years

Its basically just a Python User Interface file. So it opens up a new Window without the command line. chech this link (filext.com/file-extension/PYW)
MandyShaw about 5 years

Please edit the actual answer to include this useful information, thank you.
FabioSpaghetti almost 5 years

Thank you @ErykSun but no single one of them worked for me,I tried them 1by1. I use anaconda to run R from Python. but the window always opens
Eryk Sun almost 5 years

@FabioSpaghetti, I don't use either Anaconda or R, so I can only suggest that you try to systematically identify the problem. Factor out Anaconda and your current Python environment by installing and using the regular Python 3.7 distribution with default settings and no third-party packages. For 64-bit Windows, I recommend the "x86-64 executable" installer. In your test script, check sys.executable to ensure that you're running the new Python installation and not your old Anaconda installation.
FabioSpaghetti almost 5 years

@ErykSun Thank you very much dear Eryk. well one point is that I have written many other codes using this idle, and I am afraid if I do only this part in 3.7 it might create difficulties for me. since I will need to gather all of the codes under one thkinter or executable file, will this solution help me ?
Eryk Sun almost 5 years

@FabioSpaghetti, it's not the final solution. It's the first step in the systematic narrowing down of what's causing the child R process to allocate a console. We begin by simplifying the Python side of things as much as possible. If the problem persists, it's likely in the R child process, perhaps due to command-line arguments or environment variables that make it allocate a console.
Soren Bjornstad about 4 years

This still doesn't answer the question, which is about using a subprocess() call within an already-running Python app (whether that runs in a console window or not).