os.system abwarten

[mzh]

Wenn ich auf der Shell also

Code: Alles auswählen

$ /path/to/program.sh < script.sh > output.dat

schreiben würde, würde das dann mit subprocess.Popen
so aussehen?

Code: Alles auswählen

p = subprocess.Popen(['/path/to/program.sh', 'script.sh', 'output.dat'],
                                      stdin='script.sh',
                                      stdout='output.dat'

Nein. Ungetestet(evtl sind die nested with's falsch):

Code: Alles auswählen

with open('script.sh'), open('output.dat', w) as in, out:
    p = subprocess.Popen(['/path/to/program.sh'],
                         stdin=in,
                         stdout=out)

ich hab mir das eben gedacht, dass es wahrscheinlich so sein soll... und ist 'in' nicht ein keyword? Danke jedenfalls.

[mzh]

Code: Alles auswählen

            
p = subprocess.Popen([self.vmd, '-dispdev text', '-eofexit'],
                    stdin=comScript,
                    stdout='./sandbox/vmd-%s-com.log' % self.target)

tja, wäre schön gewesen

Code: Alles auswählen

Traceback (most recent call last):
  File "/home/mzhpropka/public_html/a_content/runPDB2PQR.cgi", line 44, in ?
    ctrAlgn.writeCOM()
  File "/home/mzhpropka/public_html/a_content/realign.py", line 81, in writeCOM
    stdout='./sandbox/vmd-%s-com.log' % self.target)
  File "/usr/lib/python2.4/subprocess.py", line 533, in __init__
    (p2cread, p2cwrite,
  File "/usr/lib/python2.4/subprocess.py", line 830, in _get_handles
    p2cread = stdin.fileno()
AttributeError: 'str' object has no attribute 'fileno'

[EyDu]

Würdest du die Dokumentation lesen, dann wüsstest du auch, warum das nicht funktionieren kann:

stdin, stdout and stderr specify the executed programs’ standard input, standard output and standard error file handles, respectively. Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None.

[cofi]

ich hab mir das eben gedacht, dass es wahrscheinlich so sein soll... und ist 'in' nicht ein keyword? Danke jedenfalls.

Ja, `in` ist ein Keyword. Das musst du dann eben durch `in_` ersetzen.
Und wenn du dir gedacht hast, dass es "wahrscheinlich so sein soll", warum machst du es in deinem Versuch dann nicht so?

[syntor]

Würdest du die Dokumentation lesen, dann wüsstest du auch, warum das nicht funktionieren kann:

stdin, stdout and stderr specify the executed programs’ standard input, standard output and standard error file handles, respectively. Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None.

Oder ganz einfach cofi's Beispiel beachten.

[mzh]

Ich glaub ich habs jetzt endlich mehr oder weniger hingekriegt. Macht die folgende Art das externe Programm auszuführen ungefähr Sinn?

Code: Alles auswählen

>>> vmdCmd
'/home/mzhpropka/software/vmd-bin-dir/vmd'
>>> vmdInp
'/home/mzhpropka/public_html/a_content/sandbox/vmd_test.vmd'
>>> p2 = subprocess.Popen(vmdCmd + ' -dispdev text' + ' < ' + vmdInp, shell=True)
>>> Info) VMD for LINUX, version 1.8.7 (August 1, 2009)
Info) http://www.ks.uiuc.edu/Research/vmd/                         
Info) Email questions and bug reports to vmd@ks.uiuc.edu           
Info) Please include this reference in published work using VMD:   
Info)    Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual   
Info)    Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 1 CPU detected.
Info) Free system memory: 746MB (74%)
Info) No CUDA accelerator devices available.
invalid command name "-dispdev"
/home/mzhpropka/software/vmd-lib-dir/scripts/tcl8.5 /home/mzhpropka/software/vmd-lib-dir/scripts /home/mzhpropka/software/lib /Projects/johns/tcl/8.5.6/lib_LINUX/lib /home/mzhpropka/software/vmd-lib-dir/scripts/vmd /home/mzhpropka/software/vmd-lib-dir/plugins/LINUX/tcl /home/mzhpropka/software/vmd-lib-dir/plugins/noarch/tcl /home/mzhpropka/software/vmd-lib-dir/scripts/la1.0
/home/mzhpropka/software/vmd-lib-dir/scripts/tcl8.5 /home/mzhpropka/software/vmd-lib-dir/scripts /home/mzhpropka/software/lib /Projects/johns/tcl/8.5.6/lib_LINUX/lib /home/mzhpropka/software/vmd-lib-dir/scripts/vmd /home/mzhpropka/software/vmd-lib-dir/plugins/LINUX/tcl /home/mzhpropka/software/vmd-lib-dir/plugins/noarch/tcl /home/mzhpropka/software/vmd-lib-dir/scripts/la1.0 /home/mzhpropka/software/vmd-lib-dir/scripts/orient
VMD is loading the file
Info) Using plugin pdb for structure file 1AVD.pdb
Info) Using plugin pdb for coordinates from file 1AVD.pdb
Info) Determining bond structure from distance search ...
Info) Finished with coordinate file 1AVD.pdb.
Info) Analyzing structure ...
Info)    Atoms: 2022
Info)    Bonds: 2026
Info)    Angles: 0  Dihedrals: 0  Impropers: 0  Cross-terms: 0
Info)    Bondtypes: 0  Angletypes: 0  Dihedraltypes: 0  Impropertypes: 0
Info)    Residues: 287
Info)    Waters: 37
Warning) Unusual bond between residues:  17 (protein) and 600 (none)
Info)    Segments: 1
Info)    Fragments: 41   Protein: 2   Nucleic: 0
0
atomselect0
Info) Opened coordinate file 1AVD-rew.pdb for writing.
Info) Finished with coordinate file 1AVD-rew.pdb.
Info) VMD for LINUX, version 1.8.7 (August 1, 2009)
Info) Exiting normally.

>>> 

Wenn ich allerdings 'shell=False' setze, dann kriege ich

Code: Alles auswählen

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/subprocess.py", line 542, in __init__
    errread, errwrite)
  File "/usr/lib/python2.4/subprocess.py", line 975, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
>>> 

und in der Dokumentation steht, dass 'shell' normalerweise nicht benötigt wird. Woran kann es liegen, dass der Befehl bei mir nur mit 'shell=True' funktioniert?

[EyDu]

Da du offensichtlich nicht liest und umsetzt was andere schreiben, solltest du einfach den Thread noch einmal von vorne durcharbeiten und die Beiträge vestehen und entsprechend auf dein Problem anwenden.

[mzh]

Ich habe jetzt versucht soviel zu dem Thema zu verstehen wie möglich und dazu auch einige simple Beispiele versucht.
Bspw. das folgende:
Ich will mir den Inhalt des Verzeichnisses anzeigen lassen. Die Anzeige wird in ein File 'lsout.dat' umgeleitet.
Der Shellbefehl 'ls' steht in einem File 'lsCmd.sh'. Für 'ls' soll die '-l' Option verwendet werden.

Das 'lsCmd.sh' File sieht so aus:

Code: Alles auswählen

#!/bin/bash
ls -l

Nun der Pythonteil:

Code: Alles auswählen

import subprocess
lsproc = subprocess.Popen(['./lsCmd.sh'], stdout=subprocess.PIPE, shell=False)
lsout = open('lsout.dat', 'w')
lsout.write(lsproc.stdout.read())
lsout.close()

Im 'lsout.dat' File steht nun der Inhalt des Verzeichnisses. In meinem Fall sieht es so aus, dass ich ein Programm starten möchte, welches dann ein File mit Anweisungen ausführt, bspw. gnuplot.
Das Anweisungs-File 'sin_cos.gnu' könnte so aussehen:

Code: Alles auswählen

set terminal postscript;
set output 'sin_cos.ps';
plot sin(x), cos(x);
quit;

Auf der Shell würde ich das so aufrufen:

Code: Alles auswählen

$ gnuplot < sin_cos.gnu

So erhalte ich das 'sin_cos.ps' File.
Mit subprocess.Popen würde ich das jetzt so machen:

Code: Alles auswählen

import subprocess
gnup = subprocess.Popen(['gnuplot', 'sin_cos.gnu'], shell=False)

Das schreibt mir das 'sin_cos.ps' File. Ich versuche das jetzt auf meine Situation anzuwenden.

[snafu]

`sin_cos.gnu` ist kein Argument von `gnuplot`, sondern es ist eine Umleitung, die den Dateiinhalt von `sin_cos.gnu` in den `stdin` vom Prozess `gnuplot` schreibt. Du solltest das dann auch entsprechend in deinem `subprocess`-Aufruf so umsetzen.

Übrigens, du kannst `Popen()` bereits ein Dateiobjekt für die Umleitung eines Datenstroms mitgeben und musst daher nicht den Umweg über `PIPE` gehen.

[mzh]

@snafu:
Ich habe jetzt nur diese weitere Möglichkeit gefunden, ich versteh leider nicht genau wie du meinst.

Code: Alles auswählen

[mzh] @ ~/programming/subpro $ python
Python 2.6.1 (r261:67515, Feb 11 2010, 15:47:53) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> gnuproc = subprocess.Popen(['gnuplot'], stdin=subprocess.PIPE, shell=False)
>>> gnuinp = open('sin_cos.gnu', 'r')
>>> gnuinp
<open file 'sin_cos.gnu', mode 'r' at 0x406750>
>>> gnuproc.stdin.write(gni.read())
>>> 

[BlackJack]

@mzh: Du kannst bei `Popen()` anstelle von der `PIPE`-Konstante auch eine geöffnete Datei übergeben. Was ist denn daran jetzt schon wieder nicht zu verstehen!?

[mzh]

achso, also

Code: Alles auswählen

[mzh] @ ~/programming/subpro $ python
Python 2.6.1 (r261:67515, Feb 11 2010, 15:47:53) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> gnuproc = subprocess.Popen(['gnuplot'], stdin=open('gnuinp.gnu', 'r'), shell=False)
>>>

[problembär]

Auf der Shell würde ich das so aufrufen:

Code: Alles auswählen

$ gnuplot < sin_cos.gnu

So erhalte ich das 'sin_cos.ps' File.
Mit subprocess.Popen würde ich das jetzt so machen:

Code: Alles auswählen

import subprocess
gnup = subprocess.Popen(['gnuplot', 'sin_cos.gnu'], shell=False)

Was snafu meint, ist: Wo ist denn da das "<" aus dem obigen Shell-Befehl?
Was Du da machst ist doch eine Umleitung der Eingabe:

http://tldp.org/LDP/abs/html/io-redirection.html

So, und ob "subprocess" das mitmacht, wenn Du das "<" einfach als Argument mitgibst, weiß ich nicht. Deswegen benutze und empfehle ich bei solchen komplizierten Shell-Kommandos ja eben doch eher "os.system()" und "os.popen()". Hier wäre das einfach:

Code: Alles auswählen

os.system("gnuplot < sin_cos.gnu")

[cofi]

Genau dafür sind die `std*` Parameter des `subprocess.Popen`-Aufrufs da. Und selbst wenn man bei Shellbefehlen bleiben will, gibt es immernoch den Shell-Parameter. Es gibt schlichtweg keinen Grund weiterhin die Funktionen des `os` Moduls zu nutzen.

@mzh: Nein. Du solltest die Datei explizit schliessen und dich nicht auf den GC verlassen.

[mzh]

Code: Alles auswählen

os.system("gnuplot < sin_cos.gnu")

Wenn das in meinem Fall funktionieren würde, hätte ich mir ja den ganzen Thread sparen können. Das habe ich natürlich schon versucht, das Problem, soweit ich es verstehe, ist in diesem Fall aber, dass der gnuplot Prozess dabei in einer neuen Shell startet. Dh. Python selber setzt die Abarbeitung seines Skriptes fort, obwohl die Ausgabe aus dem Prozess von os.system(...) für die Fortsetzung des Skriptes benötigt wird. Dh. Python sollte "warten", bis der Flow of Control wieder zurück zum Skript kommt.
@cofi: So?

Code: Alles auswählen

[mzh] @ ~/programming/subpro $ python
Python 2.6.1 (r261:67515, Feb 11 2010, 15:47:53)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> inFile = open('gnuinp.gnu', 'r')
>>> gnuproc = subprocess.Popen(['gnuplot'], stdin=inFile.read(), shell=False)
>>> inFile.close()

Hab jetzt nicht getestet, ob da stehen soll 'stdin=inFile.read()', oder bloss 'stdin=inFile'.

[snafu]

Code: Alles auswählen

with open('sin_cos.gnu') as infile:
    subprocess.call('gnuplot', stdin=infile)

[cofi]

Nein, so wie ich es in meinem Beispiel gezeigt habe, damit der Code da ran kommt musst du das in ein `try ... finally` Konstrukt wickeln.

In dem Code hast du schon wieder keine File-Objekt mehr sondern einen String, also ja ohne `.read()`.

[derdon]

Hab jetzt nicht getestet, ob da stehen soll 'stdin=inFile.read()', oder bloss 'stdin=inFile'.

Und warum nicht?

[snafu]

Es hat beim Helfen immer so einen faden Beigeschmack, wenn man den Eindruck hat, dass der Fragesteller zu keinem Zeitpunkt so wirklich zu wissen scheint, was er da überhaupt gerade tut.

[mzh]

Es hat beim Helfen immer so einen faden Beigeschmack, wenn man den Eindruck hat, dass der Fragesteller zu keinem Zeitpunkt so wirklich zu wissen scheint, was er da überhaupt gerade tut.

Es erscheint mir angebracht zu bemerken, dass ich für Hinweise sehr froh und dankbar bin. Auf Kommentare, die mir unterstellen ich versuche der Beschäftigung mit der Materie auszuweichen muss ich nicht eingehen. Ich finde ein Forum eine sehr gute Form sich zu Wissen auszutauschen und ich habe hier schon oft den richtigen Hinweis gefunden, wie ein Problem zu lösen sei.