À l'aide de sous-processus pour exécuter un script Python sur Windows

Est-il un moyen simple d'exécuter un script Python sur Windows/Linux/OS X?

Sur les deux derniers, subprocess.Popen("/the/script.py") fonctionne, mais sur Windows j'obtiens l'erreur suivante:

Traceback (most recent call last):
  File "test_functional.py", line 91, in test_functional
    log = tvnamerifiy(tmp)
  File "test_functional.py", line 49, in tvnamerifiy
    stdout = PIPE
  File "C:\Python26\lib\subprocess.py", line 595, in __init__
    errread, errwrite)
  File "C:\Python26\lib\subprocess.py", line 804, in _execute_child
    startupinfo)
WindowsError: [Error 193] %1 is not a valid Win32 application

monkut de l' commentaire: Le cas d'utilisation n'est pas claire. Pourquoi utiliser des sous-processus pour exécuter un script python? Est-il quelque chose vous empêche d'importer le script et l'appel de la fonction nécessaire?

J'ai écrit un script vite fait pour tester l'ensemble des fonctionnalités de Python-outil de ligne de commande (à tester sur différentes plates-formes). Fondamentalement, il fallait créer un ensemble de fichiers dans un dossier temp, exécutez le script de cette et de vérifier les fichiers ont été renommés correctement.

Je pourrait avoir importé le script et a appelé la fonction, mais depuis elle s'appuie sur sys.argv et utilise sys.exit(), j'aurais besoin de faire quelque chose comme..

import sys
import tvnamer
sys.argv.append("-b", "/the/folder")
try:
    tvnamer.main()
except BaseException, errormsg:
    print type(errormsg)

Aussi, je voulais capturer le stdout et stderr pour le débogage au cas où quelque chose s'est mal passé.

Bien sûr une meilleure façon serait d'écrire le script en plus de l'unité-testable, mais le script est fondamentalement "fait" et je suis en train de faire un dernier lot de tester avant de faire un "1.0" libération (après quoi, je vais faire une réécriture/restructurer, ce qui sera beaucoup plus propre et plus testable)

Fondamentalement, il était beaucoup plus facile de simplement exécuter le script comme un processus, après la recherche de la sys.executable variable. Je l'ai écrit comme un shell-script, mais cela n'aurait pas été de la croix-plate-forme. Le script final peut être trouvé ici

Le cas d'utilisation n'est pas claire. Pourquoi utiliser des sous-processus pour exécuter un script python? Est-il quelque chose vous empêche d'importer le script et l'appel de la fonction nécessaire?
Eu le même problème lors de l'exécution de nodejs modules de python. sous-processus.appel([r'..\nodejs\mnp'], shell=True) a résolu le problème.

InformationsquelleAutor dbr | 2009-05-26

60

Viens de trouver sys.exécutable - le chemin d'accès complet à l'actuel Python exécutable, qui peut être utilisé pour exécuter le script (au lieu de compter sur la shbang, ce qui évidemment ne fonctionne pas sur Windows)
```
import sys
import subprocess

theproc = subprocess.Popen([sys.executable, "myscript.py"])
theproc.communicate()
```
- vous pouvez utiliser subprocess.check_call([sys.executable, "myscript.py"]) à la place.
- Ou mieux encore, en Python 3.5+, utilisez subprocess.run: subprocess.run([sys.executable, 'myscript.py'], check=True)
InformationsquelleAutor dbr
21

Comment à ce sujet:
```
import sys
import subprocess

theproc = subprocess.Popen("myscript.py", shell = True)
theproc.communicate()                   # ^^^^^^^^^^^^
```
Cela dit subprocess à utiliser le système d'exploitation shell pour ouvrir votre script, et travaille sur quelque chose que vous pouvez juste lancer dans cmd.exe.

En outre, cela permettra de rechercher le CHEMIN pour "myscript.py" - qui pourrait être souhaitable.
- Je pense que cela va fonctionner de la même manière, si je me souviens droit shell=True s'arrête juste sous-processus de s'échapper tous les caractères spéciaux (donc "mycmd > somefile.txt" redirige texte somefile.txt plutôt que d'essayer d'exécuter un fichier appelé "mycmd > somefile.txt")
- Voici une situation dans laquelle les deux sont significativement différentes. Supposons que "myscript.py" est dans le CHEMIN d'accès au système, et non pas dans le répertoire courant. Si vous utilisez "shell = True", le script sera trouvé sur le CHEMIN, mais si vous utilisez "sys.exécutable" il ne sera pas.
- Ahh je vois ce que tu veux dire (bien que le script que j'essayais de courir a toujours été va être dans le répertoire courant)
- Corrigé mon erreur, par la façon dont il fonctionne sans shell = True sur python3 et échoue randonly sur 2.7, je ne sais pas pourquoi.
InformationsquelleAutor Roman Starkov
6

Oui subprocess.Popen(cmd, ..., shell=True) fonctionne comme un charme. Sous Windows, le .py extension de fichier est reconnu, de sorte que Python est appelé à traiter (sur *NIX simplement l'habitude shebang). Le chemin d'accès de l'environnement de contrôle si les choses sont vues. Donc, la première arg à Popen est juste le nom du script.
```
subprocess.Popen(['myscript.py', 'arg1', ...], ..., shell=True)
```
- shell=True # do not show the command prompt then true, if false show it
InformationsquelleAutor hmc
4

Il ressemble à windows tente d'exécuter le script à l'aide de ses propres EXE cadre plutôt que de l'appeler comme
```
python /the/script.py
```
Essayer,
```
subprocess.Popen(["python", "/the/script.py"])
```
Edit: "python" aurait besoin d'être sur votre chemin.
- L'python.org programme d'installation de Windows ne semble pas mettre le "python" de commande dans le CHEMIN, et je pense qu'il aurait du .exe suffixe (qui briserait les autres plates-formes)
- ah, je suppose que l' .exe serait de casser des choses, oui..
- Hm, il semble que vous pouvez exclure le .exe sur Windows, tant que c'est dans le CHEMIN, mais vous devez l'ajouter manuellement Python pour elle
- Donc, utiliser "cmd /S /C" au lieu de "python" - c'est toujours sur le chemin et va exécuter le script pour autant que l'extension est enregistré.
InformationsquelleAutor viksit
2

Vous utilisez un chemin d'accès séparateur, qui est dépendant de la plate-forme. Windows utilise "\" et Unix utilise "/".
- Bon point, même si dans le script lui-même qui a provoqué l'erreur, j'ai utilisé de l'os.chemin d'accès.join() (bien que je devrais avoir mentionné qu')
- Bien sûr, la barre oblique a été valable sur Windows depuis la préhistoire et est encore, ce n'est donc pas un problème.
- pas vraiment: sous-processus.appel([r'..\nodejs\mnp'], shell=True), alors que sous-processus.appel(['../nodejs/mnp'], shell=True) donne '..' n'est pas reconnu en tant que commande interne ou externe
- que serait la coquille se plaindre et de ne pas le sous-jacent de l'API Windows.
InformationsquelleAutor

Par exemple, pour exécuter la suite avec l'invite de commande ou un fichier de commandes, nous pouvons utiliser ce:

C:\Python27\python.exe "C:\Program files(x86)\dev_appserver.py" --host 0.0.0.0 --post 8080 "C:\blabla\"

Même chose à faire avec Python, on peut faire ceci:

subprocess.Popen(['C:/Python27/python.exe', 'C:\\Program files(x86)\\dev_appserver.py', '--host', '0.0.0.0', '--port', '8080', 'C:\\blabla'], shell=True)

subprocess.Popen(['C:/Python27/python.exe', 'C:/Program files(x86)/dev_appserver.py', '--host', '0.0.0.0', '--port', '8080', 'C:/blabla'], shell=True)

InformationsquelleAutor YumYumYum

1

Lorsque vous exécutez un script python sur windows en sous-processus, vous devez utiliser python en face du nom du script. Essayez:
```
process = subprocess.Popen("python /the/script.py")
```
InformationsquelleAutor Robbie

Vous devez vous connecter pour publier un commentaire.