マニュアルページにあるように、
openコマンドは、ファイルのアイコンをダブルクリックしたかのように、ファイル (またはディレクトリまたは URL) を開きます。
最終的に、アプリケーションは LaunchServices によって開始されますが、それは重要ではありません。重要なのは、それがシェルまたは Python スクリプトの子ではないということです。
また、要点はopen
アプリ自体を開くことなので、アプリを掘り下げて Unix 実行可能ファイルを見つける必要はありません。すでにそれを持っていて、Unix 実行可能ファイルとして実行したい場合は、次のように実行します。
xfoil = sp.Popen(['/Applications/Xfoil.app/Contents/MacOS/Xfoil'], stdin=sp.PIPE, stdout=sp.PIPE)
結局のところ、この場合、MacOS/Xfoil
正しいプログラムでさえありません。それはどうやらある種のラッパーであり、 LinuxでResources/xfoil
得られるものと実際に同等です。/usr/local/bin/xfoil
だからあなたはこれをしたい:
xfoil = sp.Popen(['/Applications/Xfoil.app/Contents/Resouces/xfoil'], stdin=sp.PIPE, stdout=sp.PIPE)
(また、技術的には、コマンド ラインはまったく機能しないはずです。-a
は、Unix 実行可能ファイルではなくアプリケーションを指定し、開くために少なくとも 1 つのファイルを渡す必要があります。しかし、LaunchServices は Unix 実行可能ファイルをあたかもそれらがアプリケーションでありopen
、引数が有効であることを確認せず、open -a /Applications/Xfoil.app/Contents/MacOS/Xfoil
実質的に と同じことを行うことになりopen /Applications/Xfoil.app/Contents/MacOS/Xfoil
ます。)
将来の読者のために、コメントからこの情報を含めます。
関数に行を書き込んでstdin
関数から戻る/メインスクリプトの最後に落ちるなどの場合、Popen
オブジェクトはガベージコレクションされ、両方のパイプが閉じられます。まだ実行が完了していない場合xfoil
、次に出力を書き込もうとしたときにエラーが発生し、Fortran runtime error: end of file
(stderr に?) 出力してベイリングすることでこれを処理するようです。これが起こらないようにするにはxfoil.wait()
、(または暗黙的に s を呼び出す何か)を呼び出す必要があります。wait