staging.inyokaproject.org

Hallo,

richtig. Hab's entfernt.

Gruß, noisefloor

Ich finde mit Ubuntu 16.10 unter dem Zahnrad keine "Startprogramme" (links geklickt) - kriege leider keinen Screenshot als Beweis hin, bei "drucken" verschwindet immer das Zahnrad-Menü ☹

Habe gerade auch das Unity-Tweak-Tool installiert, dort gibt es - wohl anders als im Gnome-Tweak-Tool- keine Einstellung für Autostart. Das Gnome-tewak-tool ist aber, wenn ich das richtig verstehe, nichts für Unity. Wäre das noch erwähnenswert? Gerhard

Hallo,

Ich finde mit Ubuntu 16.10 unter dem Zahnrad keine "Startprogramme" (links geklickt)

Das ist korrekt - im Wikiartikel steht auch, dass das nur unter 12.04 so ist.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

Ich finde mit Ubuntu 16.10 unter dem Zahnrad keine "Startprogramme" (links geklickt)

Das ist korrekt - im Wikiartikel steht auch, dass das nur unter 12.04 so ist.

Gruß, noisefloor

Da hast du recht. Verstehe nicht, wie ich das überlesen konnte. Sorry. Gerhard

Hallo Moderatoren,

ich wollte lediglich etwas melden, in der Hoffnung hilfreich zu sein. Ich wollte gestern wie unter https://wiki.ubuntuusers.de/Autostart/ beschrieben, einfach das Program Kodi hinzufügen und freute mich zunächst, auf die einfache beschriebene Weise mit der GNOME-Shell. Ich rief Startprogramme auf, fügte Kodi hinzu, startete den PC neu. Kodi wurde nicht gestartet, es geschah einfach nichts.

Ich habe nun Kodi in das Verzeichnis .config/autostart/ kopiert und es funktioniert.

Ubuntu 16.04.

Gruß

Hi!

Ist rc.local unter 18.04 noch nutzbar? Müsste die Datei ggf. erst selbst angelegt werden? Wenn nicht, sollte in der Einleitung ein Hinweis darauf rein; der Artikel rc.local ist auch nicht für 18.04 getestet.

so long
hank

Hallo,

Ist rc.local unter 18.04 noch nutzbar?

Ja, systemd liest das aus Gründen der Rückwärtskompatibiliät aus und konvertiert das in systemd Units.

Müsste die Datei ggf. erst selbst angelegt werden?

Ja, macht aber wenig Sinn, da man bessere eine systemd Service Unit schreibt.

Gruß, noisefloor

Hi!

Jo, is' sicher einfacher, 'ne Systemd-Unit zu schreiben, als was in eine rc.local einzutragen... *duckundwegrenn*

Automatische Übersetzung in Systemd-Units! Wow, wird das Resultat dann in /lib/systemd/system abgelegt?

OK, danke, weiß ich Bescheid. Dann sollte rc.local wohl auch ein "kann-nach-xenial-wech-tag" bekommen?

so long
hank

Hallo,

Automatische Übersetzung in Systemd-Units! Wow, wird das Resultat dann in /lib/systemd/stystem abgelegt?

Nein, das erfolgt bei jedem Start dynamisch zur Laufzeit. Dafür ist die Unit rc-local.service zuständig. Siehe auch man systemd-rc-local-generator.

Dann sollte rc.local wohl auch ein "kann-nach-xenial-wech-tag" bekommen?

Theoretisch schon jetzt, weil Trusty die letzte Ubuntu-Version mit Support war, wo man rc.local wirklich brauchte. Könnte aber natürlich sein, dass in Xenial noch Pakete sind, die "nur" Dateien in rc.local ablegen und noch keine systemd Service Units anlegen.

Hallo!

Problembehebung¶

(...)

Autostart über Skript¶

Es kommt gerade beim Autostart immer wieder vor, dass die Zeile mit exec=... nicht zum Erfolg führt. Dann ist ein Umweg erforderlich. Dazu erstellt man sich im Ordner /usr/local/bin mit Root-Rechten ein Shellskript test.sh mit dem problematischen Befehl und macht die Datei nach dem Speichern ausführbar. Beispiel:

1 2	#!/bin/sh befehl

Dann verweist man in der .desktop-Datei mit exec=/usr/local/bin/test.sh auf dieses Shellskript.

Wenn man einen Befehl nicht nur ausführen, sondern auch die Rückmeldung sehen möchte, bastelt man sich ein Shell-Skript nach folgendem Muster:

1 2 3 4

#!/bin/sh echo | befehl echo "press any key" read -s

Damit wird das Beenden der Ausgabe solange verhindert, bis eine beliebige Taste gedrückt wird. Zum Start des Skripts sollte die dazugehörige .desktop-Datei in diesem Fall die Zeile

Terminal=true

enthalten (siehe Programmstarter).

Anmerkungen / Fragen:

• Sollte man statt "exec=..." nicht lieber "Exec=..." schreiben?

• Könnte man das Skript anstatt für alle Benutzer im Ordner /usr/local/bin alternativ nicht auch im Homeverzeichnis des aktuellen Nutzers unter ~/.local/bin ablegen?

• Programmstarter ist z.Zt. lediglich eine Umleitung nach .desktop-Dateien, das könnte man also hier konsequenterweise anpassen.

• In .desktop-Dateien (Abschnitt „Optionen-uebergeben“) steht IMHO eine im Gegensatz zu "Autostart über Skript" elegantere Lösung, welche – zumindest, falls man keine Rückmeldung braucht – gänzlich _ohne_ Skript auskommt:

Problembehebung¶

(...)

Optionen übergeben¶

Beim Aufruf eines Programms über die Zeile Exec=... ist die Übergabe von Optionen mit zwei Bindestrichen in der Form PROGRAMM --OPTION nicht möglich, während PROGRAMM -OPTION bzw. ein Bindestrich kein Problem ist. Falls zwei Bindestriche erforderlich sind, bedient man sich des folgenden Konstrukts:

Exec=sh -c "PROGRAMM --OPTION"

Die vorstehende Lösung passt auch besser zu Autostart (Abschnitt „Autostart-verzoegern“), und siehe auch noch .desktop-Dateien (Abschnitt „Zwei-oder-mehr-Programme-starten“).

Hallo,

Sollte man statt "exec=..." nicht lieber "Exec=..." schreiben?

Sehe ich auch so. Funktioniert exec (mit kleinem e) überhaupt?

Könnte man das Skript anstatt für alle Benutzer im Ordner /usr/local/bin alternativ nicht auch im Homeverzeichnis des aktuellen Nutzers unter ~/.local/bin ablegen?

Ich denke schon. Macht zu Testen jedenfalls Sinn, weil dann auch Nutzer ohne Root-Rechte das machen können.

Programmstarter ist z.Zt. lediglich eine Umleitung nach .desktop-Dateien, das könnte man also hier konsequenterweise anpassen.

Ja.

... elegantere Lösung, ...

Das ist wahrscheinlich historisch bedingt, weil der eine Artikel älter ist als der andere und beim Erstellen des .desktop-Artikel "vergessen" wurde. Kann / sollte man IMHO aber vereinheitlichen.

Gruß, noisefloor

Hallo linux_joy

magst du die Punkte umsetzen? Wenn du ne Baustelle dafür willst, gib doch hier bitte kurz Bescheid.

Gruß BillMaier

Hallo,

noisefloor schrieb:

Hallo,

Sollte man statt "exec=..." nicht lieber "Exec=..." schreiben?

Sehe ich auch so. Funktioniert exec (mit kleinem e) überhaupt?

Ob exec (mit kleinem e) überhaupt, könnte ich ich testen (falls ich sowieso die Baustelle bearbeite, s.u.).

Könnte man das Skript anstatt für alle Benutzer im Ordner /usr/local/bin alternativ nicht auch im Homeverzeichnis des aktuellen Nutzers unter ~/.local/bin ablegen?

Ich denke schon. Macht zu Testen jedenfalls Sinn, weil dann auch Nutzer ohne Root-Rechte das machen können.

OK.

Programmstarter ist z.Zt. lediglich eine Umleitung nach .desktop-Dateien, das könnte man also hier konsequenterweise anpassen.

Ja.

OK.

... elegantere Lösung, ...

Das ist wahrscheinlich historisch bedingt, weil der eine Artikel älter ist als der andere und beim Erstellen des .desktop-Artikel "vergessen" wurde. Kann / sollte man IMHO aber vereinheitlichen.

OK.

Gruß, noisefloor

Hallo BillMaier

magst du die Punkte umsetzen? Wenn du ne Baustelle dafür willst, gib doch hier bitte kurz Bescheid.

OK, Baustelle bitte einrichten.

Artikel ist in der Baustelle. Fertigstellungsdatum bitte wie immer selbstständig anpassen.

Gruß BillMaier