Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams subprocess.run(["ls", "-l"])

Another common way is os.system but you shouldn't use it because it is unsafe if any parts of the command come from outside your program or can contain spaces or other special characters, also subprocess.run is generally more flexible (you can get the stdout , stderr , the "real" status code , better error handling , etc.). Even the documentation for os.system recommends using subprocess instead.

On Python 3.4 and earlier, use subprocess.call instead of .run :

subprocess.call(["ls", "-l"])
                Is there a way to use variable substitution? IE I tried to do echo $PATH by using call(["echo", "$PATH"]), but it just echoed the literal string $PATH instead of doing any substitution. I know I could get the PATH environment variable, but I'm wondering if there is an easy way to have the command behave exactly as if I had executed it in bash.
– Kevin Wheeler
                Sep 1, 2015 at 23:17
                @KevinWheeler You should NOT use shell=True, for this purpose Python comes with os.path.expandvars. In your case you can write: os.path.expandvars("$PATH"). @SethMMorton please reconsider your comment -> Why not to use shell=True
– Murmel
                Nov 11, 2015 at 20:24
                Many arguments version looks like that:  subprocess.run(["balcon.exe","-n","Tatyana","-t", "Hello world"])
– Sergey Anisimov
                May 15, 2022 at 18:55

Here is a summary of ways to call external programs, including their advantages and disadvantages:

  • os.system passes the command and arguments to your system's shell. This is nice because you can actually run multiple commands at once in this manner and set up pipes and input/output redirection. For example:

    os.system("some_command < input_file | another_command > output_file")  
    

    However, while this is convenient, you have to manually handle the escaping of shell characters such as spaces, et cetera. On the other hand, this also lets you run commands which are simply shell commands and not actually external programs.

  • os.popen will do the same thing as os.system except that it gives you a file-like object that you can use to access standard input/output for that process. There are 3 other variants of popen that all handle the i/o slightly differently. If you pass everything as a string, then your command is passed to the shell; if you pass them as a list then you don't need to worry about escaping anything. Example:

    print(os.popen("ls -l").read())
    
  • subprocess.Popen. This is intended as a replacement for os.popen, but has the downside of being slightly more complicated by virtue of being so comprehensive. For example, you'd say:

    print subprocess.Popen("echo Hello World", shell=True, stdout=subprocess.PIPE).stdout.read()
    

    instead of

    print os.popen("echo Hello World").read()
    

    but it is nice to have all of the options there in one unified class instead of 4 different popen functions. See the documentation.

  • subprocess.call. This is basically just like the Popen class and takes all of the same arguments, but it simply waits until the command completes and gives you the return code. For example:

    return_code = subprocess.call("echo Hello World", shell=True)
    
  • subprocess.run. Python 3.5+ only. Similar to the above but even more flexible and returns a CompletedProcess object when the command finishes executing.

  • os.fork, os.exec, os.spawn are similar to their C language counterparts, but I don't recommend using them directly.

    The subprocess module should probably be what you use.

    Finally, please be aware that for all methods where you pass the final command to be executed by the shell as a string and you are responsible for escaping it. There are serious security implications if any part of the string that you pass can not be fully trusted. For example, if a user is entering some/any part of the string. If you are unsure, only use these methods with constants. To give you a hint of the implications consider this code:

    print subprocess.Popen("echo %s " % user_input, stdout=PIPE).stdout.read()
    

    and imagine that the user enters something "my mama didnt love me && rm -rf /" which could erase the whole filesystem.

    Nice answer/explanation. How is this answer justifying Python's motto as described in this article ? fastcompany.com/3026446/… "Stylistically, Perl and Python have different philosophies. Perl’s best known mottos is " There’s More Than One Way to Do It". Python is designed to have one obvious way to do it" Seem like it should be the other way! In Perl I know only two ways to execute a command - using back-tick or open. – Jean May 26, 2015 at 21:16 If using Python 3.5+, use subprocess.run(). docs.python.org/3.5/library/subprocess.html#subprocess.run – phoenix Oct 7, 2015 at 16:37 What one typically needs to know is what is done with the child process's STDOUT and STDERR, because if they are ignored, under some (quite common) conditions, eventually the child process will issue a system call to write to STDOUT (STDERR too?) that would exceed the output buffer provided for the process by the OS, and the OS will cause it to block until some process reads from that buffer. So, with the currently recommended ways, subprocess.run(..), what exactly does "This does not capture stdout or stderr by default." imply? What about subprocess.check_output(..) and STDERR? – Evgeni Sergeev Jun 1, 2016 at 10:44 which of the commands you recommended block my script? i.e. if I want to run multiple commands in a for loop how do I do it without it blocking my python script? I don't care about the output of the command I just want to run lots of them. – Charlie Parker Oct 24, 2017 at 19:08 This is arguably the wrong way around. Most people only need subprocess.run() or its older siblings subprocess.check_call() et al. For cases where these do not suffice, see subprocess.Popen(). os.popen() should perhaps not be mentioned at all, or come even after "hack your own fork/exec/spawn code". – tripleee Dec 3, 2018 at 6:00
    import subprocess
    p = subprocess.Popen('ls', shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
    for line in p.stdout.readlines():
        print line,
    retval = p.wait()
    

    You are free to do what you want with the stdout data in the pipe. In fact, you can simply omit those parameters (stdout= and stderr=) and it'll behave like os.system().

    .readlines() reads all lines at once i.e., it blocks until the subprocess exits (closes its end of the pipe). To read in real time (if there is no buffering issues) you could: for line in iter(p.stdout.readline, ''): print line, – jfs Nov 16, 2012 at 14:12 Could you elaborate on what you mean by "if there is no buffering issues"? If the process blocks definitely, the subprocess call also blocks. The same could happen with my original example as well. What else could happen with respect to buffering? – EmmEff Nov 17, 2012 at 13:25 the child process may use block-buffering in non-interactive mode instead of line-buffering so p.stdout.readline() (note: no s at the end) won't see any data until the child fills its buffer. If the child doesn't produce much data then the output won't be in real time. See the second reason in Q: Why not just use a pipe (popen())?. Some workarounds are provided in this answer (pexpect, pty, stdbuf) – jfs Nov 17, 2012 at 13:51 the buffering issue only matters if you want output in real time and doesn't apply to your code that doesn't print anything until all data is received – jfs Nov 17, 2012 at 13:53 This answer was fine for its time, but we should no longer recommend Popen for simple tasks. This also needlessly specifies shell=True. Try one of the subprocess.run() answers. – tripleee Dec 3, 2018 at 5:39

    Some hints on detaching the child process from the calling one (starting the child process in background).

    Suppose you want to start a long task from a CGI script. That is, the child process should live longer than the CGI script execution process.

    The classical example from the subprocess module documentation is:

    import subprocess
    import sys
    # Some code here
    pid = subprocess.Popen([sys.executable, "longtask.py"]) # Call subprocess
    # Some more code here
    

    The idea here is that you do not want to wait in the line 'call subprocess' until the longtask.py is finished. But it is not clear what happens after the line 'some more code here' from the example.

    My target platform was FreeBSD, but the development was on Windows, so I faced the problem on Windows first.

    On Windows (Windows XP), the parent process will not finish until the longtask.py has finished its work. It is not what you want in a CGI script. The problem is not specific to Python; in the PHP community the problems are the same.

    The solution is to pass DETACHED_PROCESS Process Creation Flag to the underlying CreateProcess function in Windows API. If you happen to have installed pywin32, you can import the flag from the win32process module, otherwise you should define it yourself:

    DETACHED_PROCESS = 0x00000008
    pid = subprocess.Popen([sys.executable, "longtask.py"],
                           creationflags=DETACHED_PROCESS).pid
    

    /* UPD 2015.10.27 @eryksun in a comment below notes, that the semantically correct flag is CREATE_NEW_CONSOLE (0x00000010) */

    On FreeBSD we have another problem: when the parent process is finished, it finishes the child processes as well. And that is not what you want in a CGI script either. Some experiments showed that the problem seemed to be in sharing sys.stdout. And the working solution was the following:

    pid = subprocess.Popen([sys.executable, "longtask.py"], stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE)
    

    I have not checked the code on other platforms and do not know the reasons of the behaviour on FreeBSD. If anyone knows, please share your ideas. Googling on starting background processes in Python does not shed any light yet.

    you might also need CREATE_NEW_PROCESS_GROUP flag. See Popen waiting for child process even when the immediate child has terminated – jfs Nov 16, 2012 at 14:16 I'm seeing import subprocess as sp;sp.Popen('calc') not waiting for the subprocess to complete. It seems the creationflags aren't necessary. What am I missing? – ubershmekel Oct 27, 2014 at 21:01 @ubershmekel, I am not sure what you mean and don't have a windows installation. If I recall correctly, without the flags you can not close the cmd instance from which you started the calc. – newtover Oct 28, 2014 at 12:25 The following is incorrect: "[o]n windows (win xp), the parent process will not finish until the longtask.py has finished its work". The parent will exit normally, but the console window (conhost.exe instance) only closes when the last attached process exits, and the child may have inherited the parent's console. Setting DETACHED_PROCESS in creationflags avoids this by preventing the child from inheriting or creating a console. If you instead want a new console, use CREATE_NEW_CONSOLE (0x00000010). – Eryk Sun Oct 27, 2015 at 0:27 I didn't mean that executing as a detached process is incorrect. That said, you may need to set the standard handles to files, pipes, or os.devnull because some console programs exit with an error otherwise. Create a new console when you want the child process to interact with the user concurrently with the parent process. It would be confusing to try to do both in a single window. – Eryk Sun Oct 27, 2015 at 17:37 No idea what I meant nearly a decade ago (check the date!), but if I had to guess, it would be that there's no validation done. – nimish Jun 6, 2018 at 16:01 This should now point to subprocess as a slightly more versatile and portable solution. Running external commands is of course inherently unportable (you have to make sure the command is available on every architecture you need to support) and passing user input as an external command is inherently unsafe. – tripleee Dec 3, 2018 at 5:11 @NathanB by using result = subprocess.run() instead and then doing result.stdout. It might also be possible by intercepting stdout – Boris Verkhovskiy May 22 at 9:51

    I'd recommend using the subprocess module instead of os.system because it does shell escaping for you and is therefore much safer.

    subprocess.call(['ping', 'localhost'])
                    If you want to create a list out of a command with parameters, a list which can be used with subprocess when shell=False, then use shlex.split for an easy way to do this docs.python.org/2/library/shlex.html#shlex.split (it's the recommended way according to the docs docs.python.org/2/library/subprocess.html#popen-constructor)
    – Daniel F
                    Sep 20, 2018 at 18:07
                    This is incorrect: "it does shell escaping for you and is therefore much safer". subprocess doesn't do shell escaping, subprocess doesn't pass your command through the shell, so there's no need to shell escape.
    – Lie Ryan
                    Dec 4, 2018 at 8:36
                    You can also save your result with the os.system call, since it works like the UNIX shell itself, like for example os.system('ls -l > test2.txt')
    – Stefan Gruenwald
                    Nov 7, 2017 at 23:19
    

    There are lots of different libraries which allow you to call external commands with Python. For each library I've given a description and shown an example of calling an external command. The command I used as the example is ls -l (list all files). If you want to find out more about any of the libraries I've listed and linked the documentation for each of them.

    Sources

  • subprocess: https://docs.python.org/3.5/library/subprocess.html
  • shlex: https://docs.python.org/3/library/shlex.html
  • os: https://docs.python.org/3.5/library/os.html
  • sh: https://amoffat.github.io/sh/
  • plumbum: https://plumbum.readthedocs.io/en/latest/
  • pexpect: https://pexpect.readthedocs.io/en/stable/
  • fabric: http://www.fabfile.org/
  • envoy: https://github.com/kennethreitz/envoy
  • commands: https://docs.python.org/2/library/commands.html
  • These are all the libraries

    Hopefully this will help you make a decision on which library to use :)

    subprocess

    Subprocess allows you to call external commands and connect them to their input/output/error pipes (stdin, stdout, and stderr). Subprocess is the default choice for running commands, but sometimes other modules are better.

    subprocess.run(["ls", "-l"]) # Run command
    subprocess.run(["ls", "-l"], stdout=subprocess.PIPE) # This will run the command and return any output
    subprocess.run(shlex.split("ls -l")) # You can also use the shlex library to split the command
    

    os is used for "operating system dependent functionality". It can also be used to call external commands with os.system and os.popen (Note: There is also a subprocess.popen). os will always run the shell and is a simple alternative for people who don't need to, or don't know how to use subprocess.run.

    os.system("ls -l") # Run command
    os.popen("ls -l").read() # This will run the command and return any output
    

    sh is a subprocess interface which lets you call programs as if they were functions. This is useful if you want to run a command multiple times.

    sh.ls("-l") # Run command normally
    ls_cmd = sh.Command("ls") # Save command as a variable
    ls_cmd() # Run command as if it were a function
    

    plumbum

    plumbum is a library for "script-like" Python programs. You can call programs like functions as in sh. Plumbum is useful if you want to run a pipeline without the shell.

    ls_cmd = plumbum.local("ls -l") # Get command
    ls_cmd() # Run command
    

    pexpect

    pexpect lets you spawn child applications, control them and find patterns in their output. This is a better alternative to subprocess for commands that expect a tty on Unix.

    pexpect.run("ls -l") # Run command as normal
    child = pexpect.spawn('scp foo user@example.com:.') # Spawns child application
    child.expect('Password:') # When this is the output
    child.sendline('mypassword')
    

    fabric

    fabric is a Python 2.5 and 2.7 library. It allows you to execute local and remote shell commands. Fabric is simple alternative for running commands in a secure shell (SSH)

    fabric.operations.local('ls -l') # Run command as normal
    fabric.operations.local('ls -l', capture = True) # Run command and receive output
    

    envoy

    envoy is known as "subprocess for humans". It is used as a convenience wrapper around the subprocess module.

    r = envoy.run("ls -l") # Run command
    r.std_out # Get output
    

    commands

    commands contains wrapper functions for os.popen, but it has been removed from Python 3 since subprocess is a better alternative.

    It is the recommended standard way. However, more complicated tasks (pipes, output, input, etc.) can be tedious to construct and write.

    Note on Python version: If you are still using Python 2, subprocess.call works in a similar way.

    ProTip: shlex.split can help you to parse the command for run, call, and other subprocess functions in case you don't want (or you can't!) provide them in form of lists:

    import shlex
    import subprocess
    subprocess.run(shlex.split('ls -l'))
    

    With external dependencies

    If you do not mind external dependencies, use plumbum:

    from plumbum.cmd import ifconfig
    print(ifconfig['wlan0']())
    

    It is the best subprocess wrapper. It's cross-platform, i.e. it works on both Windows and Unix-like systems. Install by pip install plumbum.

    Another popular library is sh:

    from sh import ifconfig
    print(ifconfig('wlan0'))
    

    However, sh dropped Windows support, so it's not as awesome as it used to be. Install by pip install sh.

    I always use fabric for doing these things. Here is a demo code:

    from fabric.operations import local
    result = local('ls', capture=True)
    print "Content:/n%s" % (result, )
    

    But this seems to be a good tool: sh (Python subprocess interface).

    Look at an example:

    from sh import vgdisplay
    print vgdisplay()
    print vgdisplay('-v')
    print vgdisplay(v=True)
    

    Check the "pexpect" Python library, too.

    It allows for interactive controlling of external programs/commands, even ssh, ftp, telnet, etc. You can just type something like:

    child = pexpect.spawn('ftp 192.168.0.24')
    child.expect('(?i)name .*: ')
    child.sendline('anonymous')
    child.expect('(?i)password')
    

    If you need the output from the command you are calling, then you can use subprocess.check_output (Python 2.7+).

    >>> subprocess.check_output(["ls", "-l", "/dev/null"])
    'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'
    

    Also note the shell parameter.

    If shell is True, the specified command will be executed through the shell. This can be useful if you are using Python primarily for the enhanced control flow it offers over most system shells and still want convenient access to other shell features such as shell pipes, filename wildcards, environment variable expansion, and expansion of ~ to a user’s home directory. However, note that Python itself offers implementations of many shell-like features (in particular, glob, fnmatch, os.walk(), os.path.expandvars(), os.path.expanduser(), and shutil).

    Note that check_output requires a list rather than a string. If you don't rely on quoted spaces to make your call valid, the simplest, most readable way to do this is subprocess.check_output("ls -l /dev/null".split()). – Bruno Bronosky Jan 30, 2018 at 18:18 Like the answer vaguely mentions, and many other answers on this page explain in more detail, you can pass a list, or with shell=True a single string which the shell then takes care of parsing and executing. Using plain .split() is fine under the circumstances you mention, but beginners typically don't understand the nuances; you are probably better off recommending shlex.split() which does handle quoting and backslash escapes correctly. – tripleee Jun 9, 2021 at 19:39

    Update:

    subprocess.run is the recommended approach as of Python 3.5 if your code does not need to maintain compatibility with earlier Python versions. It's more consistent and offers similar ease-of-use as Envoy. (Piping isn't as straightforward though. See this question for how.)

    Here's some examples from the documentation.

    Run a process:

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

    Raise on failed run:

    >>> subprocess.run("exit 1", shell=True, check=True)
    Traceback (most recent call last):
    subprocess.CalledProcessError: Command 'exit 1' returned non-zero exit status 1
    

    Capture output:

    >>> subprocess.run(["ls", "-l", "/dev/null"], stdout=subprocess.PIPE)
    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')
    

    Original answer:

    I recommend trying Envoy. It's a wrapper for subprocess, which in turn aims to replace the older modules and functions. Envoy is subprocess for humans.

    Example usage from the README:

    >>> r = envoy.run('git config', data='data to pipe in', timeout=2)
    >>> r.status_code
    >>> r.std_out
    'usage: git config [options]'
    >>> r.std_err
    

    Pipe stuff around too:

    >>> r = envoy.run('uptime | pbcopy')
    >>> r.command
    'pbcopy'
    >>> r.status_code
    >>> r.history
    [<Response 'uptime'>]
    

    This is how I run my commands. This code has everything you need pretty much

    from subprocess import Popen, PIPE
    cmd = "ls -l ~/"
    p = Popen(cmd , shell=True, stdout=PIPE, stderr=PIPE)
    out, err = p.communicate()
    print "Return code: ", p.returncode
    print out.rstrip(), err.rstrip()
    

    How to execute a program or call a system command from Python

    Simple, use subprocess.run, which returns a CompletedProcess object:

    >>> from subprocess import run
    >>> from shlex import split
    >>> completed_process = run(split('python --version'))
    Python 3.8.8
    >>> completed_process
    CompletedProcess(args=['python', '--version'], returncode=0)
    

    (run wants a list of lexically parsed shell arguments - this is what you'd type in a shell, separated by spaces, but not where the spaces are quoted, so use a specialized function, split, to split up what you would literally type into your shell)

    As of Python 3.5, the documentation recommends subprocess.run:

    The recommended approach to invoking subprocesses is to use the run() function for all use cases it can handle. For more advanced use cases, the underlying Popen interface can be used directly.

    Here's an example of the simplest possible usage - and it does exactly as asked:

    >>> from subprocess import run
    >>> from shlex import split
    >>> completed_process = run(split('python --version'))
    Python 3.8.8
    >>> completed_process
    CompletedProcess(args=['python', '--version'], returncode=0)
    

    run waits for the command to successfully finish, then returns a CompletedProcess object. It may instead raise TimeoutExpired (if you give it a timeout= argument) or CalledProcessError (if it fails and you pass check=True).

    As you might infer from the above example, stdout and stderr both get piped to your own stdout and stderr by default.

    We can inspect the returned object and see the command that was given and the returncode:

    >>> completed_process.args
    ['python', '--version']
    >>> completed_process.returncode
    

    Capturing output

    If you want to capture the output, you can pass subprocess.PIPE to the appropriate stderr or stdout:

    >>> from subprocess import PIPE
    >>> completed_process = run(shlex.split('python --version'), stdout=PIPE, stderr=PIPE)
    >>> completed_process.stdout
    b'Python 3.8.8\n'
    >>> completed_process.stderr
    

    And those respective attributes return bytes.

    Pass a command list

    One might easily move from manually providing a command string (like the question suggests) to providing a string built programmatically. Don't build strings programmatically. This is a potential security issue. It's better to assume you don't trust the input.

    >>> import textwrap
    >>> args = ['python', textwrap.__file__]
    >>> cp = run(args, stdout=subprocess.PIPE)
    >>> cp.stdout
    b'Hello there.\n  This is indented.\n'
    

    Note, only args should be passed positionally.

    Full Signature

    Here's the actual signature in the source and as shown by help(run):

    def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
    

    The popenargs and kwargs are given to the Popen constructor. input can be a string of bytes (or unicode, if specify encoding or universal_newlines=True) that will be piped to the subprocess's stdin.

    The documentation describes timeout= and check=True better than I could:

    The timeout argument is passed to Popen.communicate(). If the timeout expires, the child process will be killed and waited for. The TimeoutExpired exception will be re-raised after the child process has terminated.

    If check is true, and the process exits with a non-zero exit code, a CalledProcessError exception will be raised. Attributes of that exception hold the arguments, the exit code, and stdout and stderr if they were captured.

    and this example for check=True is better than one I could come up with:

    >>> subprocess.run("exit 1", shell=True, check=True)
    Traceback (most recent call last):
    subprocess.CalledProcessError: Command 'exit 1' returned non-zero exit status 1
    

    Expanded Signature

    Here's an expanded signature, as given in the documentation:

    subprocess.run(args, *, stdin=None, input=None, stdout=None, stderr=None, 
    shell=False, cwd=None, timeout=None, check=False, encoding=None, 
    errors=None)
    

    Note that this indicates that only the args list should be passed positionally. So pass the remaining arguments as keyword arguments.

    Popen

    When use Popen instead? I would struggle to find use-case based on the arguments alone. Direct usage of Popen would, however, give you access to its methods, including poll, 'send_signal', 'terminate', and 'wait'.

    Here's the Popen signature as given in the source. I think this is the most precise encapsulation of the information (as opposed to help(Popen)):

    def __init__(self, args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None, env=None, universal_newlines=None, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=(), *, user=None, group=None, extra_groups=None, encoding=None, errors=None, text=None, umask=-1, pipesize=-1):

    But more informative is the Popen documentation:

    subprocess.Popen(args, bufsize=-1, executable=None, stdin=None, stdout=None, 
    stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None,
    env=None, universal_newlines=None, startupinfo=None, creationflags=0, 
    restore_signals=True, start_new_session=False, pass_fds=(), *, group=None, 
    extra_groups=None, user=None, umask=-1, encoding=None, errors=None, 
    text=None)
    

    Execute a child program in a new process. On POSIX, the class uses os.execvp()-like behavior to execute the child program. On Windows, the class uses the Windows CreateProcess() function. The arguments to Popen are as follows.

    Understanding the remaining documentation on Popen will be left as an exercise for the reader.

    A simple example of two-way communication between a primary process and a subprocess can be found here: stackoverflow.com/a/52841475/1349673 – James Hirschorn Oct 16, 2018 at 18:05

    As of Python 3.7.0 released on June 27th 2018 (https://docs.python.org/3/whatsnew/3.7.html), you can achieve your desired result in the most powerful while equally simple way. This answer intends to show you the essential summary of various options in a short manner. For in-depth answers, please see the other ones.

    TL;DR in 2021

    The big advantage of os.system(...) was its simplicity. subprocess is better and still easy to use, especially as of Python 3.5.

    import subprocess
    subprocess.run("ls -a", shell=True)
    

    Note: This is the exact answer to your question - running a command

    like in a shell

    Preferred Way

    If possible, remove the shell overhead and run the command directly (requires a list).

    import subprocess
    subprocess.run(["help"])
    subprocess.run(["ls", "-a"])
    

    Pass program arguments in a list. Don't include \"-escaping for arguments containing spaces.

    Advanced Use Cases

    Checking The Output

    The following code speaks for itself:

    import subprocess
    result = subprocess.run(["ls", "-a"], capture_output=True, text=True)
    if "stackoverflow-logo.png" in result.stdout:
        print("You're a fan!")
    else:
        print("You're not a fan?")
    

    result.stdout is all normal program output excluding errors. Read result.stderr to get them.

    capture_output=True - turns capturing on. Otherwise result.stderr and result.stdout would be None. Available from Python 3.7.

    text=True - a convenience argument added in Python 3.7 which converts the received binary data to Python strings you can easily work with.

    Checking the returncode

    if result.returncode == 127: print("The program failed for some weird reason")
    elif result.returncode == 0: print("The program succeeded")
    else: print("The program failed unexpectedly")
    

    If you just want to check if the program succeeded (returncode == 0) and otherwise throw an Exception, there is a more convenient function:

    result.check_returncode()
    

    But it's Python, so there's an even more convenient argument check which does the same thing automatically for you:

    result = subprocess.run(..., check=True)
    

    stderr should be inside stdout

    You might want to have all program output inside stdout, even errors. To accomplish this, run

    result = subprocess.run(..., stderr=subprocess.STDOUT)
    

    result.stderr will then be None and result.stdout will contain everything.

    Using shell=False with an argument string

    shell=False expects a list of arguments. You might however, split an argument string on your own using shlex.

    import subprocess
    import shlex
    subprocess.run(shlex.split("ls -a"))
    

    That's it.

    Common Problems

    Chances are high you just started using Python when you come across this question. Let's look at some common problems.

    FileNotFoundError: [Errno 2] No such file or directory: 'ls -a': 'ls -a'

    You're running a subprocess without shell=True . Either use a list (["ls", "-a"]) or set shell=True.

    TypeError: [...] NoneType [...]

    Check that you've set capture_output=True.

    TypeError: a bytes-like object is required, not [...]

    You always receive byte results from your program. If you want to work with it like a normal string, set text=True.

    subprocess.CalledProcessError: Command '[...]' returned non-zero exit status 1.

    Your command didn't run successfully. You could disable returncode checking or check your actual program's validity.

    TypeError: init() got an unexpected keyword argument [...]

    You're likely using a version of Python older than 3.7.0; update it to the most recent one available. Otherwise there are other answers in this Stack Overflow post showing you older alternative solutions.

    "The big advantage of os.system(...) was its simplicity. subprocess is better" - how subprocess is better? I am happily using os.system, not sure how switching to subprocess and remembering extra shell=True benefits me. What kind of thing is better in subprocess? – reducing activity Mar 26, 2021 at 9:14 You're right in that os.system(...) is a reasonable choice for executing commands in terms of simple "blind" execution. However, the use cases are rather limited - as soon as you want to capture the output, you have to use a whole other library and then you start having both - subprocess and os for similar use cases in your code. I prefer to keep the code clean and use only one of them. Second, and I would have put that section at the top but the TL;DR has to answer the question exactly, you should not use shell=True, but instead what I've written in the Preferred Way section. – fameman Mar 27, 2021 at 11:30 The problem with os.system(...) and shell=True is that you're spawning a new shell process, just to execute your command. This means, you have to do manual escaping which is not as simple as you might think - especially when targeting both POSIX and Windows. For user-supplied input, this is a no-go (just imagine the user entered something with " quotes - you'd have to escape them as well). Also, the shell process itself could load code you don't need - not only does it delay the program, but it could also lead to unexpected side effects, ending with a wrong return code. – fameman Mar 27, 2021 at 11:34 Summing up, os.system(...) is valid to use, indeed. But as soon as you're writing more than a quick python helper script, I'd recommend you to go for subprocess.run without shell=True. For more information about the drawbacks of os.system, I'd like to propose you a read through this SO answer: stackoverflow.com/a/44731082/6685358 – fameman Mar 27, 2021 at 11:35

    os.system is OK, but kind of dated. It's also not very secure. Instead, try subprocess. subprocess does not call sh directly and is therefore more secure than os.system.

    Get more information here.

    While I agree with the overall recommendation, subprocess does not remove all of the security problems, and has some pesky issues of its own. – tripleee Dec 3, 2018 at 5:36 LocalCommand(<LocalPath /bin/ls>) u'build.py\ndist\ndocs\nLICENSE\nplumbum\nREADME.rst\nsetup.py\ntests\ntodo.txt\n' >>> notepad = local["c:\\windows\\notepad.exe"] >>> notepad() # Notepad window pops up u'' # Notepad window is closed by user, command returns

    os - This module provides a portable way of using operating system-dependent functionality.

    For the more os functions, here is the documentation.

    This fails to point out the drawbacks, which are explained in much more detail in PEP-324. The documentation for os.system explicitly recommends avoiding it in favor of subprocess. – tripleee Dec 3, 2018 at 5:02

    There is another difference here which is not mentioned previously.

    subprocess.Popen executes the <command> as a subprocess. In my case, I need to execute file <a> which needs to communicate with another program, <b>.

    I tried subprocess, and execution was successful. However <b> could not communicate with <a>. Everything is normal when I run both from the terminal.

    One more: (NOTE: kwrite behaves different from other applications. If you try the below with Firefox, the results will not be the same.)

    If you try os.system("kwrite"), program flow freezes until the user closes kwrite. To overcome that I tried instead os.system(konsole -e kwrite). This time program continued to flow, but kwrite became the subprocess of the console.

    Anyone runs the kwrite not being a subprocess (i.e. in the system monitor it must appear at the leftmost edge of the tree).

    I tend to use subprocess together with shlex (to handle escaping of quoted strings):

    >>> import subprocess, shlex
    >>> command = 'ls -l "/your/path/with spaces/"'
    >>> call_params = shlex.split(command)
    >>> print call_params
    ["ls", "-l", "/your/path/with spaces/"]
    >>> subprocess.call(call_params)
    

    I wrote a library for this, shell.py.

    It's basically a wrapper for popen and shlex for now. It also supports piping commands, so you can chain commands easier in Python. So you can do things like:

    ex('echo hello shell.py') | "awk '{print $2}'"
    

    Under Linux, in case you would like to call an external command that will execute independently (will keep running after the Python script terminates), you can use a simple queue as task spooler or the at command.

    An example with task spooler:

    import os
    os.system('ts <your-command>')
    

    Notes about task spooler (ts):

  • You could set the number of concurrent processes to be run ("slots") with:

    ts -S <number-of-slots>

  • Installing ts doesn't requires admin privileges. You can download and compile it from source with a simple make, add it to your path and you're done.

    ts is not standard on any distro I know of, though the pointer to at is mildly useful. You should probably also mention batch. As elsewhere, the os.system() recommendation should probably at least mention that subprocess is its recommended replacement. – tripleee Dec 3, 2018 at 5:43

    In Windows you can just import the subprocess module and run external commands by calling subprocess.Popen(), subprocess.Popen().communicate() and subprocess.Popen().wait() as below:

    # Python script to run a command line
    import subprocess
    def execute(cmd):
            Purpose  : To execute a command and return exit status
            Argument : cmd - command to execute
            Return   : exit_code
        process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        (result, error) = process.communicate()
        rc = process.wait()
        if rc != 0:
            print "Error: failed to execute command:", cmd
            print error
        return result
    # def
    command = "tasklist | grep python"
    print "This process detail: \n", execute(command)
    

    Output:

    This process detail:
    python.exe                     604 RDP-Tcp#0                  4      5,660 K
    

    Invoke is a Python (2.7 and 3.4+) task execution tool and library. It provides a clean, high-level API for running shell commands:

    >>> from invoke import run
    >>> cmd = "pip install -r requirements.txt"
    >>> result = run(cmd, hide=True, warn=True)
    >>> print(result.ok)
    >>> print(result.stdout.splitlines()[-1])
    Successfully installed invocations-0.13.0 pep8-1.5.7 spec-1.3.1
                    This is a great library.  I was trying to explain it to a coworker the other day adn described it like this: invoke is to subprocess as requests is to urllib3.
    – user9074332
                    Mar 12, 2019 at 2:00
    

    You can use Popen, and then you can check the procedure's status:

    from subprocess import Popen
    proc = Popen(['ls', '-l'])
    if proc.poll() is None:
        proc.kill()
    

    Check out subprocess.Popen.

  •