Heiner schrieb:
> Thorsten schrieb:
>> Führe ich das Skript aus mit ./etc/init.d/glabelsstart.sh
>
> Kleinigkeit: Den führenden Punkt brauchst du hier nicht. Der wäre nur
> erforderlich, wenn du bereits in /etc/init.d/ bist und dort das Skript
> aufrufen wolltest.
Das ist nicht ganz richtig, fürchte ich. In dem hier gezeigten Fall
müßte das Skript im Unterverzeichnis etc/init.d/ des aktuellen
Verzeichnisses liegen, denn da würde der Punkt das aktuelle Verzeichnis
repräsentieren.
Wenn allerdings zwischen dem Punkt und dem Pfad Whitespace ist, mithin
also stattdessen ". /etc/init.d/glabelsstart.sh" aufgerufen würde, dann
ist der Punkt in der Bash ein Shortcout für das Bash-Builtin "source"
(man 1 bash), das ein Skript im Kontext der aktuellen Shell aufruft.
Normalerweise wird "source" allerdings dazu benutzt, um
Umgebungsvariablen in der aktuell laufenden Shell zu setzen -- anstatt
in der Subshell, die das Shellscript ausführt, wie das bei einem
"normalen" Shellskript passieren würde. Pythons virtualenv(1) zum
Beispiel nutzt das.
> Thorsten schrieb:
>> Ich habe das dann mit
>> sudo update-rc.d glabelsstart.sh defaults
>> in den Autostart verschoben.
>
> Das willst du nicht tun. Das sind weder die richtigen Benutzerrechte
> noch ist es der richtige Zeitpunkt für eine grafische Anwendung.
Absolut korrekt, wenngleich aus zum Teil anderen Gründen: Raspbian (das
mittlerweile in "Raspberry Pi OS" umbenannt wurde) benutzt schon seit
geraumer Zeit systemd, und update-rc.d(8) ist für SysV-Init gemacht.
Deswegen ist es auch überholt, das Skript in /etc/init.d/ abzulegen.
Der richtige Weg, einen selbstentwickelten Daemon (nicht, wie hier, eine
grafische Applikation) zu installieren und zu starten, wäre daher, das
Programm oder Skript in /usr/local/bin/ unterzubringen (oder eine
Sammlung ggf. in opt). Denn diese beiden Verzeichnisse sind für
3rd-Party-Software im Filesystem Hierarchy Standard (FHS), der im
Übrigen Bestandteil der Linux Standard Base (LSB) ist, vorgesehen, und
sie werden deswegen von den Paketmaintainern des Distributors in Ruhe
gelassen. Wer so etwas in andere Verzeichnisse installiert, riskiert
damit, daß der Distributor beim nächsten Update ein gleichnamiges
Programm oder Skript über das eigene installiert.
Der Richtige Weg (tm), ein solches eigenes Programm oder Skript beim
Booten zu starten, wäre, ein systemd-Unitfile zu schreiben, es in
/etc/systemd/system/ oder in /etc/systemd/user/ abzulegen (siehe dazu
auch [1] und [2]) und dann zuerst mit dem "systemctl daemon-reload" die
systemd-Konfiguration neu zu laden, es mit "systemctl enable
<name-des-unitfile>" einzuschalten und ggf. mit "systemctl start
<name-des-unitfile>" zu starten.
Aber, wie Du sehr richtig sagst, geht es hier nicht um einen Daemon oder
eine Art von Hintergrundprogramm, sondern um eine grafische Applikation.
Deswegen ist dies ebenfalls nicht der richtige Mechanismus, um das
Programm bzw. Skript zu starten.
[1] https://wiki.ubuntuusers.de/systemd/User_Units/
[2] https://wiki.archlinux.org/index.php/systemd/User
> Insgesamt ist das aber der falsche Mechanismus. Für deinen Fall wäre ein
> Start mit der Desktop-Session sinnvoller
Wieder absolut korrekt. Übrigens könnte man theoretisch auch eine
systemd User-Unit benutzen, aber die würde dann bei jedem Login (auch
zB. per SSH) gestartet. Das kann man machen, wenn man SSH oder OpenSSH
mit X-Forwarding benutzt, weil man auf dem SSH-Client einen X-Server
hat, unter Windows ginge das etwa mit Moba XTerm oder dem bekannteren
Xming.
Thread beobachten
Seitenaufteilung abschalten