ubuntuusers.de

Kinch schrieb:

Ich dachte aber zugegeben auch, das Problem entstünde beim schließen des Terminals.

Achso! Ja, tatsächlich, und dann hilft auch kein „nohup“. Aber Barabbas’ Variante. Okay, ich bin ent-wundert.

(Note to self: Lesen)

Kinch schrieb:

Ich glaube zwar nicht, dass das Programm mal unter Windows laufen würde, aber reine Python-Lösung könnte zumindest auch unter nicht Unixen laufen.

Das Programm läuft technisch sehr wohl unter Windows, darauf habe ich geachtet. Ich kenne nur keine betriebssystemunabhängige Lösung, um beliebige Dateien (sowohl beliebig vom Dateityp als auch von der Anzahl) unter jeder erdenklichen Platform öffnen zu können. Und zwar am liebsten auch noch mit den vom User festgelegten Standardprogrammen.

Die Frage ist auch, ob Python für so ein Skript überhaupt die richtige Wahl ist.

Was genau darf ich unter "so ein Srkipt" verstehen? Niemand ausser mir hier kennt den Rest des Programmes ☺

Und ich versteh es nicht, wieso man sowas macht. Macht den os.system-Quatsch weg, tauscht die Shebang und das Teil läuft auch so.

Da muss ich dir zustimmen, os.system() bereitet für gewöhnlich nur Probleme bzw. es gibt meist bessere Lösungen.

Barabbas schrieb:

Hallo,

bei Verwendung von "shell=true" erwartet Popen keine Liste von Befehlen und Parametern, sondern den Befehl als String.

import subprocess
subprocess.Popen("nohup totem", shell=True)

Wenn ich das ganze mit totem, vlc, etc. mache funktionierts (war aber auch ohne "shell=True" schon so).

Bei xdg-open hingegen schließt sich das Fenster wieder, wenn das Python-Programm beendet wird. Faszinierend...

Hab testweise auch mal "&" bzw. "&!" hintendrangehängt. Trotzdem schließt sich das Fenster, wenn das Python-Programm beendet wird.

mfg

Developer92 schrieb:

import subprocess
subprocess.Popen("nohup totem", shell=True)

Wenn ich das ganze mit totem, vlc, etc. mache funktionierts (war aber auch ohne "shell=True" schon so).

Bei xdg-open hingegen schließt sich das Fenster wieder, wenn das Python-Programm beendet wird. Faszinierend...

Ich habe es gerade mal probiert - ist bei mir auch so. Dafür geht es mit der Doppel-Fork-Methode.

lG

brb

//edit:
Hier mal der Code, fast komplett von der zuvor verlinkten Seite übernommen und daher nicht weiter geprüft.

#!/usr/bin/env python
# coding: utf-8
import sys
import os

def simpleDaemon(func):
    # do the UNIX double-fork magic, see Stevens' "Advanced 
    # Programming in the UNIX Environment" for details (ISBN 0201563177)
    try: 
        pid = os.fork() 
        if pid > 0:
            # parent process, return and keep running
            return
    except OSError, e:
        print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror) 
        sys.exit(1)

    os.setsid()

    # do second fork
    try: 
        pid = os.fork() 
        if pid > 0:
            # exit from second parent
            sys.exit(0) 
    except OSError, e: 
        print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror) 
        sys.exit(1)

    # do stuff
    func()

    # all done
    os._exit(os.EX_OK)

simpleDaemon(lambda: os.system("xdg-open ~/arbeitgeber.png"))

Also bei mir bleiben Dateien, die ich mit subprocess.Popen(['xdg-open', filename]) öffne, auch nach dem Schließen des Python-Interpreters auf (z.B. in gedit geladenes Python-Skript). Keine Ahnung, was du da machst...

Kann ich für gedit bestätigen, für bspw. eog aber nicht.

Dann hat das mit großer Wahrscheinlichkeit was damit zu tun, welche Desktopumgebung genutzt wird und welchen Fallback xdg-open dementsprechend fährt.

Barabbas schrieb:

Kann ich für gedit bestätigen, für bspw. eog aber nicht.

snafu1 schrieb:

Dann hat das mit großer Wahrscheinlichkeit was damit zu tun, welche Desktopumgebung genutzt wird und welchen Fallback xdg-open dementsprechend fährt.

Hm, das ist interessant.

Bei mir zeigen sich leider keine Unterschiede. Auch gedit und eog schließen sich, wenn das Programm sich beendet.

Naja, xdg-open ist, wie so viele andere xdg-Tools auch, lediglich ein Bash-Skript, das auf andere Programme zurückgreift. Du kannst ja ggf nachgucken, welches Backend in deinem Fall verwendet wird.

Developer92 schrieb:

Bei mir zeigen sich leider keine Unterschiede. Auch gedit und eog schließen sich, wenn das Programm sich beendet.

Hast du denn jetzt mal die Sache mit den Doppelforks probiert?

Barabbas schrieb:

Hast du denn jetzt mal die Sache mit den Doppelforks probiert?

Nein, bisher noch nicht. Nimms mir nicht übel - die Idee ist genial - aber es muss auch ohne Doppelfork gehen.

Ich dachte eigentlich (jedenfalls anfangs), dass ein nohup mit xdg-open all meine Probleme zu dem Thema löst. Was es ja offensichtlich nicht macht.

snafu1 schrieb:

Naja, xdg-open ist, wie so viele andere xdg-Tools auch, lediglich ein Bash-Skript, das auf andere Programme zurückgreift. Du kannst ja ggf nachgucken, welches Backend in deinem Fall verwendet wird.

Wenn das Backend wieder abhängig von der Desktopumgebung ist, dann ist das schon ein wenig mies. Dann nehm ich doch lieber die Doppelforkmethode ☺

Muss mir dazu aber erstmal xdg-open genauer ansehen.

mfg

Nur zur Info: Ich hab jetzt die Lösung mit dem Doppelfork übernommen.

Allerdings bin ich damit nicht wirklich zufrieden. "nohup" existiert ja nicht umsonst...

Ausserdem funktioniert das mit dem Doppelfork IMHO nur auf POSIX-kompatiblen-Betriebssystemen (oder nicht?)

mfg

Unvollständig zitiert:

abwürge, stirbt auch das Kind [...] bleibt das Kind am Leben.

Ich wusste es doch: Linuxer töten kleine Kinder! 😲 🐸

SCNR - und sorry für das Ausgraben des alten Themas... 😉

Grüße, Benno

Benno-007 schrieb:

SCNR - und sorry für das Ausgraben des alten Themas... 😉

Gibts halt dieses Jahr für dich nix zu Weihnachten 😬

Macht nix, dann lad ich mir irgendein Linux, Unix, ReactOS, Haiku oder Kolibri OS (Assembler) runter. 😉