0

必要に応じて、実行前に元のパラメーターにいくつかの追加パラメーターを追加するスクリプトをos.environ['PATH']実行できるように修正する必要がありました。dir\to\fake\python.cmd

また、2 つの Python スクリプトがあります。

test1.py:

# ...
p = subprocess.call("test2.py")   # shell=True works fine
# ...

test2.py:

# ...
print "Hello from test2.py"
# ...

python test1.py「偽物」を実行するpython.cmdと、元のpythonが参照され、追加の引数c:\Python25で実行されます。test1.pyしかし、悲しいことにtest2.py、スクリプトは呼び出されません。私が引数shell=Trueとして置く場合subprocess.call- すべての罰金test2.pyは、呼び出されます。

c:\Python25Windowsは、デフォルトで実際の作業ディレクトリで呼び出しに使用するPythonインタープリターを見つけようとしてshell=Falseいます。

test1.pyあなたへの質問は、と のコードを変更せずに目標を達成するにはどうすればよいtest2.pyですか? virtualenvこの場合、ライブラリが非常に役立つのではないでしょうか。

ご助力ありがとうございます

4

1 に答える 1

1

ドキュメントに記載されているように:

shell引数(デフォルトはFalse)は、実行するプログラムとしてシェルを使用するかどうかを指定します。

shell = TrueのWindowsでは、COMSPEC環境変数がデフォルトのシェルを指定します。Windowsでshell=Trueを指定する必要があるのは、実行するコマンドがシェルに組み込まれている場合(dirやcopyなど)だけです。バッチファイルまたはコンソールベースの実行可能ファイルを実行するためにshell=Trueは必要ありません。

したがって、を呼び出すsubprocess.call("test2.py")と、システムは実行可能ファイルとして呼び出そうとしますtest2.pyが、実行可能ファイルではないため、失敗します。ただし、subprocess.openエラー状態をチェックするためにからの戻り値をキャプチャしないため、サイレントに失敗します。で呼び出すshell=Trueと、引数を指定してシステムシェルを呼び出します。これにより、システム上test2.pyのファイルのデフォルトの実行可能ファイルが検索され、.pyその方法でファイルが実行されます。

とはいえ、ここでのより深刻な問題は、コードの設計が非常に不十分であるということです。別のPythonスクリプトからOSを介してPythonスクリプトをディスパッチする正当な理由がある可能性はほとんどありません。すでに持っているものに加えて別の厄介なハックにパッチを当てるのではなく、将来の頭痛の種を避け、システムをリファクタリングして、より簡単で、より賢明で、より自然に統合された方法で物事を実行できるようにします。

于 2012-11-30T20:34:16.590 に答える