marlem
(Themenstarter)
Anmeldungsdatum: 12. Juli 2016
Beiträge: 139
Wohnort: Dußlingen
|
rklm hat geschrieben: Auch hier willst Du die Shebang-Zeile in MarlemsPyAssistent.py setzen und nicht explizit "python3" davor schreiben.
Wenn ich aber
#!/bin/bash
gnome-terminal -e 'python3 MarlemsPyAssistent.py' in meine Python-Datei einfüge, dann wird sie nicht mehr vom Python-Interpreter
beachtet, oder?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Du willst doch das Python-Programm in einem gnome-terminal starten. Also brauchst du ein Skript oder Programm, das das für dich macht. Und wenn du Shell-Syntax nutzt, muss die Datei einen passenden Shebang haben, der dafür sorgt, dass das Skript mit einer Shell aufgerufen wird. Das Python-Skript sollte einen Shebang haben, der dafür sorgt, dass es mit dem gewünschten Python-Interpreter aufgerufen wird und ausführbar sein. Wenn ein Skript bzw. Programm nicht im PATH ist, muss man einen absoluten oder relativen Pfad zu der ausführbaren Datei angeben, weil sie sonst nicht gefunden wird. Also legst du z.B. dein Start-Skript als /usr/local/bin/MarlemsPyAssistent ab (es ist unter Debian/Ubuntu guter Stil in diesen Ordnern auf Dateiendungen zu verzichten, damit man leicht auf eine Implementierung in einer anderen (Skript-)Sprache umstellen kann) und sorgst dafür, dass es ausführbar ist. Damit liegt es im PATH - das könnte dann z.B. so aussehen (den Pfad musst du natürlich auf eine Gegebenheiten anpassen):
| #!/usr/bin/sh
exec gnome-terminal -- /home/marlem/Prokekte/MarlemsPyAssistent/MarlemsPyAssistent.py
|
Wenn du dich entscheidest, das mit Python3 statt einem Shell-Skript zu machen, könnte das z.B. so aussehen (vgl. https://docs.python.org/3/library/os.html#os.execlp):
| #!/usr/bin/env python3
import os
os.execlp("gnome-terminal", "gnome-terminal", "--", "/home/marlem/Prokekte/MarlemsPyAssistent/MarlemsPyAssistent.py")
|
PS: -e ist veraltet und wird eine Warnung, daher habe ich das stattdesen empfohlene -- genutzt.
|
marlem
(Themenstarter)
Anmeldungsdatum: 12. Juli 2016
Beiträge: 139
Wohnort: Dußlingen
|
Das Gnome-Terminal war einmal zuviel:
| os.execlp("gnome-terminal", "--", "/home/markus/Programme/MarlemsPyAssistent/MarlemsPyAssistent.py")
|
Das Terminal wird aufgerufen, aber die Python-Datei nicht.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
marlem schrieb: Das Gnome-Terminal war einmal zuviel:
Nein, das war beabsichtig - das zweite "gnome-terminal" wird zum ersten Argument (also das Argument mit dem Index 0 in der Liste der Argumente) des aufgerufenen Programm und das ist normalerweise der Programmname.
|
marlem
(Themenstarter)
Anmeldungsdatum: 12. Juli 2016
Beiträge: 139
Wohnort: Dußlingen
|
Nein, das war beabsichtig
Das hat aber zur Endlosschleife geführt.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Was für eine Endlosschleife?
|
marlem
(Themenstarter)
Anmeldungsdatum: 12. Juli 2016
Beiträge: 139
Wohnort: Dußlingen
|
Beide Terinalfenster werden aktiv und wieder deaktiv und das endlos.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Das von mir gezeigte Python-Skript beendet sich sofort, nachdem es das gnome-terminal aufgerufen und ihm die Argumente übergeben hat - ich wüsste nicht, woher da eine Schleife kommen soll. Nutzt du eventuell noch irgendwelche zusätzlichen (Hilfs-)Programme, die in den Fenster-Fokus eingreifen? Ohne genau zu wissen, was dein im gnome-terminal gestartetes Python-Skript da genau macht und ob es da sonstige potentielle Störfaktoren geben könnte, ist das schwer zu sagen, wo das herkommt.
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
Wobei man os.execlp() nicht mehr nutzen sollte, da externe Programme in Python schon seit einer halben Ewigkeit über das subprocess-Modul ausgeführt werden. Dieses hat die älteren systemnahen exec*-Funktionen abgelöst. Man muss schon sehr gute Gründe haben, diese noch zu nutzen - der vorliegende Anwendungsfall ist IMHO kein solcher Grund. Früher war der üblicherweise genutzte Aufruf subprocess.call(), seit einiger Zeit ist subprocess.run() der bevorzugte Einstieg. Über den env-Parameter lassen sich auch die zu nutzenden Umgebungsvariablen angeben. Der einzige Unterschied sind also zwei eckige Klammern für die Argumente als Liste, sowie ein os.environ hinter dem besagen env-Parameter. Wobei für mich nicht nachvollziehbar ist, warum diese Verrenkung überhaupt nötig ist. Warum sollte man den Shebang nicht direkt im Python-Skript einbauen...?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Ich will ja keinen Subprozess starten, sondern den Prozess ersetzen (sonst hängt der erste Python-Prozess unnötigerweise herum). Die ganze Verrenkung braucht es, wenn man von einem ausführbaren Skript aus den eigentlichen Prozess in einem neuen Terminal starten will. Wenn man das auf eine .desktop-Datei umstellen würde, würde es genügen darin Terminal=True zu setzen und das eigentliche Python-Skript direkt aufzurufen. Das Problem mit .desktop-Dateien ist, dass man die nicht so einfach aus einer Shell heraus ausführen kann - natürlich kann man da drum herum arbeiten...
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
Wenn man möchte, dass das Terminal offen bleibt, kann man ans Ende des Python-Skripts auch einfach ein input() setzen.
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4563
Wohnort: Berlin
|
Das ist keine gute Lösung weil das jeden tierisch nervt, der ein Konsolenprogramm tatsächlich in einer Konsole/einem Terminal(emulator) startet und sich fragt warum man sinnloserweise am Ende immer noch mal die Eingabetaste betätigen muss, wenn man das Programm wie vorgesehen startet. Und es ist natürlich auch doof wenn während der Programmausführung eine Ausnahme auftritt, die man dann nicht sieht, weil das an dem Konsolenfenster-offen-haltenden input() vorbeigeht und die für die Fehlersuche wichtige Information nur einen Sekundenbruchteil sichtbar ist, bevor sich das Fenster schliesst. Letztlich sieht das hier alles nach komischem herumgeeiere aus statt die normalen Wege zu gehen, die unabhängig von Python sind: Konsolenprogramme startet man in einer bereits offenen Konsole und nicht per Doppelklick. Für Programme die man per Doppelklick starten will, schreibt man eine .desktop -Datei. Das sind die vorgesehenen Wege, und die funktionieren. Benutzerfreundlich — was auch immer das heissen mag.
|