Seite 1 von 1

Der einfachste Weg um Pythonscripts zu starten?

Verfasst: Donnerstag 19. Juli 2007, 18:39
von MilesTeg
Hallo

Ich bin gerade dran ein kleines Programm zu schreiben. Jetzt überlege ich wie ich das am besten "an den Mann/die Frau" bringe.

Am liebsten wäre es mir wenn man das Programm (zur Zeit nur ein Scriptfile) nach dem herunterladen einfach per doppelklick starten könnte.

Das Programm richtet sich vor allem an Einsteiger unter Linux (v.a. Ubuntu), aber sollte auch auf anderen Systemen einfach zu starten sein.

Bei google hab ich nix gefunden, da ich nicht ganz sicher bin wonach ich da suchen müßte

Gruß
MilesTeg

Verfasst: Donnerstag 19. Juli 2007, 19:22
von Joghurt

Code: Alles auswählen

#!/usr/bin/python
in die erste Zeile des Skriptes, das Skript als Ausführbar markieren (chmod +x Skriptname). Dann in ein tar packen und das Tar zum runterladen anbieten.

Das Getarre hat den Zweck, dass automatisch das Executable-Flag gesetzt wird und die Meisten DE wie Gnome und KDE bieten automatischen entpacken von tar an.

Verfasst: Donnerstag 19. Juli 2007, 19:30
von MilesTeg
danke, das hat mir schonmal weitergeholfen!

ich Linux-DAU :oops:

Verfasst: Donnerstag 19. Juli 2007, 19:30
von rafael
Oder wenn in deinem Skript eine bestimmte Funktion beim Aufruf ausgeführt werden soll, kannst du es so lösen:

Code: Alles auswählen

def main():
    # hier deine Funktion
    pass

if __name__ == '__main__':
    main()
Das testet, ob das Skript importiert wird oder so aufgerufen wird. Bringt also den Vorteil mit, modularer zu sein.

Verfasst: Donnerstag 19. Juli 2007, 20:11
von Leonidas
Joghurt hat geschrieben:

Code: Alles auswählen

#!/usr/bin/python
in die erste Zeile des Skriptes, das Skript als Ausführbar markieren (chmod +x Skriptname). Dann in ein tar packen und das Tar zum runterladen anbieten.
Ich würde eher

Code: Alles auswählen

#!/usr/bin/env python

machen, das hat den Vorteil auch dann zu funktionieren wenn ``python`` wo anders als in ``/usr/bin/`` liegt.

Verfasst: Donnerstag 19. Juli 2007, 20:35
von Joghurt
Leonidas hat geschrieben:das hat den Vorteil auch dann zu funktionieren wenn ``python`` wo anders als in ``/usr/bin/`` liegt.
Und den Nachteil, nicht zu funktionieren, wenn env in /bin statt /usr/bin liegt. Ist mir schonmal passiert.

Außerdem kannst du dann nicht mehr Optionen an Python übergeben, da nur die ersten beiden "Wörter" ausgewertet werden, zumindest unter einigen Unices.

Ist denke ich Geschmackssache

Verfasst: Donnerstag 19. Juli 2007, 20:53
von Leonidas
Joghurt hat geschrieben:
Leonidas hat geschrieben:das hat den Vorteil auch dann zu funktionieren wenn ``python`` wo anders als in ``/usr/bin/`` liegt.
Und den Nachteil, nicht zu funktionieren, wenn env in /bin statt /usr/bin liegt. Ist mir schonmal passiert.
Ja, das stimmt. Ich denke aber es ist warscheinlicher, dass ``env`` in ``/usr/bin/`` liegt, als dass ``python`` es tut. Es gibt ja doch mehr Leute die sich ``python`` nach ``/usr/local/bin/`` installieren, damit sie eine aktuelle Python-Version haben. Aber ich gebe zu, sehr viel Unterschied besteht da wirklich nicht.
Joghurt hat geschrieben:Außerdem kannst du dann nicht mehr Optionen an Python übergeben, da nur die ersten beiden "Wörter" ausgewertet werden, zumindest unter einigen Unices.
Ja, das ist ein ärgerlicher Bug, das stimmt.

Verfasst: Donnerstag 19. Juli 2007, 21:40
von birkenfeld
Leonidas hat geschrieben:
Joghurt hat geschrieben:Außerdem kannst du dann nicht mehr Optionen an Python übergeben, da nur die ersten beiden "Wörter" ausgewertet werden, zumindest unter einigen Unices.
Ja, das ist ein ärgerlicher Bug, das stimmt.
Weniger ein Bug als eine Beschränkung. Als nächstes kommt jemand und sagt, er will Quotes im Shebang interpretiert haben. Etc., und am Schluss muss der Kernel sämtliche Shell-Wordsplitting-Regeln implementieren.

Verfasst: Freitag 20. Juli 2007, 10:59
von lunar
birkenfeld hat geschrieben:
Leonidas hat geschrieben:
Joghurt hat geschrieben:Außerdem kannst du dann nicht mehr Optionen an Python übergeben, da nur die ersten beiden "Wörter" ausgewertet werden, zumindest unter einigen Unices.
Ja, das ist ein ärgerlicher Bug, das stimmt.
Weniger ein Bug als eine Beschränkung. Als nächstes kommt jemand und sagt, er will Quotes im Shebang interpretiert haben. Etc., und am Schluss muss der Kernel sämtliche Shell-Wordsplitting-Regeln implementieren.
Dann sind wir bei einem Shebang mit Scripting-Unterstützung und Umgebungsvariablen...

... und dann kommt jemand und will Python-Code im Sheband ausführen...

Verfasst: Freitag 20. Juli 2007, 12:40
von Leonidas
birkenfeld hat geschrieben:Weniger ein Bug als eine Beschränkung. Als nächstes kommt jemand und sagt, er will Quotes im Shebang interpretiert haben. Etc., und am Schluss muss der Kernel sämtliche Shell-Wordsplitting-Regeln implementieren.
Naja, das ist vielleicht schon übertrieben, obwohl es sicher auch dafür sinnvolle Anwendungsfälle gäbe, aber so ganz normale Parameter finde ich sind ziemlich grundlegende Funktionalität.

Verfasst: Freitag 20. Juli 2007, 14:26
von Y0Gi
Wenn man entsprechende Rechte auf dem ungewöhnlichen Zielsystem hat, könnte man - auch im Hinblick auf andere Scripts - Symlinks nutzen, um z.B. /usr/bin/env bereitzuhalten.

Andererseits kann man auch einfach die Shebang-Line anpassen :) Eine Lösung, die überall funktioniert, gibt es wohl ohnehin nicht. Da ist es doch gut, dass man es leicht den Anforderungen angleichen kann.

Verfasst: Freitag 20. Juli 2007, 14:37
von lunar
Y0Gi hat geschrieben:Andererseits kann man auch einfach die Shebang-Line anpassen :)
Das wird ja auch von den distutils so gehandhabt für alles, was über scripts installiert wird.