Is this the right way to run a shell script inside Python?

Each Answer to this Q is separated by one/two green lines.

import subprocess
retcode = subprocess.call(["/home/myuser/go.sh", "abc.txt", "xyz.txt"])

When I run these 2 lines, will I be doing exactly this?:

/home/myuser/go.sh abc.txt xyz.txt

Why do I get this error? But when I run go.sh normally, I don’t get that error.

File "/usr/lib/python2.6/subprocess.py", line 480, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1139, in _execute_child
    raise child_exception
OSError: [Errno 8] Exec format error

OSError: [Errno 8] Exec format error

This is an error reported by the operating system when trying to run /home/myuser/go.sh.

It looks to me like the shebang (#!) line of go.sh is not valid.

Here’s a sample script that runs from the shell but not from Popen:

#\!/bin/sh
echo "You've just called $0 [email protected]"

Removing the \ from the first line fixes the problem.

Change the code to following:

retcode = subprocess.call(["/home/myuser/go.sh", "abc.txt", "xyz.txt"], shell=True,)

Notice “shell=True”

From: http://docs.python.org/library/subprocess.html#module-subprocess

On Unix, with shell=True: If args is a
string, it specifies the command
string to execute through the shell.
This means that the string must be
formatted exactly as it would be when
typed at the shell prompt.

I recently ran into this problem with a script that looked like this:

% cat /tmp/test.sh
                              <-- Note the empty line
#!/bin/sh
mkdir /tmp/example

The script ran fine from the command line, but failed with

OSError: [Errno 8] Exec format error

when executed via

subprocess.Popen(['/tmp/test.sh']).communicate()

(The solution, of course, was to remove the empty line).

I just got this error on Mac OS, while trying to call a one-line script using subprocess.call. The script ran fine when called from the command line. After adding the shebang line #!/usr/bin/env sh, it also ran fine via subprocess.call.

It appears, while the shell has a default executor for text files marked executable, subprocess.Popen does not.

Yes, that’s perfectly fine if all you’re doing is calling the shell script, waiting for it to complete, and gathering its exit status, while letting its stdin, stdout, and stderr be inherited from your Python process. If you need more control over any of those factors, then you just use the more general subprocess.Popen, but otherwise what you have is fine.

Yes, this is the preferred way to execute something..

Since you are passing all arguments through an array (which will be used gor an exec()-style call internally) and not as an argument string evaluated by a shell it’s also very secure as injection of shell commands is impossible.

In :call??
Signature: call(*popenargs, **kwargs)
Source:   
def call(*popenargs, **kwargs):
    """Run command with arguments.  Wait for command to complete, then
    return the returncode attribute.

    The arguments are the same as for the Popen constructor.  Example:

    retcode = call(["ls", "-l"])
    """
    return Popen(*popenargs, **kwargs).wait()
File:      /usr/lib64/python2.7/subprocess.py
Type:      function

call just invoke Popen,use wait() method wait the popenargs completes


The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .