mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
rklm schrieb: Jetzt terminiert die Shell erst, wenn auch foo beendet ist. Anderfalls beendet sich die Shell, sobald bar terminiert. Wie gesagt, ich weiß nicht, ob DE dieses Wissen irgendwie benötigen.
Gute Frage, würde dir ein konkreter Anwendungsfall dazu einfallen? Wenn man das ohne wait mit grafischen Anwendungen macht, dürfte das eigentlich egal sein. Die Shell wird geöffnet, der erste Befehl nach dem Start in den Hintergrund gelegt und der zweite ausgeführt. Normalerweise soll eine Shell in so einem Fall ja laufen, bis beide Programme beendet wurden.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13015
|
mrkramps schrieb: rklm schrieb: Jetzt terminiert die Shell erst, wenn auch foo beendet ist. Anderfalls beendet sich die Shell, sobald bar terminiert. Wie gesagt, ich weiß nicht, ob DE dieses Wissen irgendwie benötigen.
Gute Frage, würde dir ein konkreter Anwendungsfall dazu einfallen?
Es könnte halt eine DE geben, die auf den ersten gestarteten Prozess schaut (also die Shell) und keinen zweiten startet, wenn der erste noch läuft. Aber das ist rein spekulativ. Normalerweise regeln die Programme das selber.
Wenn man das ohne wait mit grafischen Anwendungen macht, dürfte das eigentlich egal sein. Die Shell wird geöffnet, der erste Befehl nach dem Start in den Hintergrund gelegt und der zweite ausgeführt. Normalerweise soll eine Shell in so einem Fall ja laufen, bis beide Programme beendet wurden.
Das macht sie ohne wait aber nicht, weil sie nicht auf die Beendigung des Hintergrundprozesses wartet: | $ { sleep 10; echo background; } & { sleep 5; echo foreground; }
[1] 23413
foreground
$ background
|
Wie Du in Zeile 4 siehst, ist der Prompt schon wieder ausgegeben, während der Hintergrundprozess noch läuft. Mit wait : | $ { sleep 10; echo background; } & { sleep 5; echo foreground; }; wait
[1] 23436
foreground
background
[1]+ Done { sleep 10; echo background; }
$
|
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6487
|
Es geht um den Artikel .desktop-Dateien Hey Jonius (auch via PN) https://wiki.ubuntuusers.de/.desktop-Dateien/a/diff/943985/944982/ habe ich nicht ganz kapiert. Kannst Du kurz helfen, wie du zu den Änderungen kommst? Welche Desktop-Umgebung bringt keinen Menü-Editor mit? Menüeditor sieht recht vollständig aus imho. was ist falsch daran, sich Desktop-Starter auf den Desktop zu legen?
Schöne Grüße vom Neuling... ///edited: Ich nutze diese Dateien nicht, daher hab ich vll. auch was übersehen. Moderiert von noisefloor: An den passenden Diskussionthread im Wikiforum angehängt.
|
Jonius
Ikhayateam
Anmeldungsdatum: 21. August 2009
Beiträge: 1861
Wohnort: München
|
BillMaier schrieb: Zum Beispiel die GNOME Shell, die jetzt Standard in Ubuntu ist. Von anderen weiß ich es nicht genau. Das ist nicht falsch. Aber in dem Abschnitt geht es um das Anlegen von Programmstartern allgemein und der richtige Ort dafür ist nunmal ~/.local/share/applications bzw. /usr/share/applications. Von dort holen sich die Desktop-Umgebungen und Menüeditoren auch die Dateien. Dass man .desktop-Dateien zusätzlich an andere Orte kopieren kann, wie zum Beispiel den Desktop (der standardmäßig in der standardmäßigen GNOME Shell auch deaktiviert ist), dem widmet sich der komplette Abschnitt direkt darunter. Edit: Du hättest solche Fragen übrigens direkt in der Diskussion zum Artikel stellen können. Dafür ist die da. 😉
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6487
|
Danke für die Erklärung. Ich hatte deine Änderungen im Verlauf gesehen und nicht verstanden. Jetzt, im Kontext des ganzen Artikels, wird es klar. Danke für die Anpassung 👍
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 54683
Wohnort: Berlin
|
Mahlzeit. Mal eine ganz blöde Frage: Wäre es möglich eine Seite .desktop-Datei anzulegen, die auf .desktop-Dateien weiterleitet? So muss ich das immer doppelt schreiben, wenn ich in einem Support-Thread darauf verlinken will. 😛 [:.desktop-Dateien:.desktop-Datei]
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29541
Wohnort: WW
|
Hallo, Inyoka kann alles und das ist so einfach, dass machen wir zwischen 12 und Mittag. Der Redirect ist angelegt. Gruß, noisefloor
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 54683
Wohnort: Berlin
|
noisefloor schrieb: Inyoka kann alles und das ist so einfach, dass machen wir zwischen 12 und Mittag.
😬 Der Redirect ist angelegt.
Thx
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 705
Wohnort: Hannover
|
Hallo, soeben habe ich mal im Abschn. "Elemente eines Programmstarters" den Link über der Tabelle aktualisiert sowie in der Tabelle selbst auch noch 2 Links ergänzt. Dabei bin ich auch darauf gestoßen, dass im Abschn. "Problembehebung" bei den Punkten 2 bis 4 immer "Exec=sh " verwendet wird. Wäre es nicht eindeutiger, wenn anstatt "sh " "bash " benutzt würde und damit die verwendete Shell eindeutig bestimmt würde? Zwar geht es hierbei ja lediglich um einfache Kommandozeilen, aber die Bash ist im Linux-Umfeld im Allgemeinen und unter Ubuntuaner*innen im Speziellen ja das Synonym für "Shell". Ganz im Gegensatz dazu steht aber die Voreinstellung unter Ubuntu, womit "sh " nach "dash " umgeleitet wird und es somit bei Verwendung von "sh " potenziell zu Inkompatibilitäten kommen könnte, weil halt viele Nutzer*innen von der "sh → dash "-Umleitung nicht wissen und sie deswegen die "bash "-Syntax benutzen. Nachstehend der Nachweis der Umleitung: | ~$ ls -la /bin/ | grep sh
-rwxr-xr-x 1 root root 1113504 Jun 7 00:28 bash
-rwxr-xr-x 1 root root 121432 Jan 25 2018 dash
lrwxrwxrwx 1 root root 4 Jun 7 00:28 rbash -> bash
lrwxrwxrwx 1 root root 4 Apr 2 12:45 sh -> dash
lrwxrwxrwx 1 root root 4 Feb 17 2016 sh.distrib -> dash
lrwxrwxrwx 1 root root 7 Mär 6 21:51 static-sh -> busybox
|
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29541
Wohnort: WW
|
Hallo,
aber die Bash ist im Linux-Umfeld im Allgemeinen und unter Ubuntuaner*innen im Speziellen ja das Synonym für "Shell".
weil halt viele Nutzer*innen von der "sh → dash"-Umleitung nicht wissen
Sagt wer bzw. steht wo? Das ganze ist deinerseits rein spekulativ.
Wäre es nicht eindeutiger, wenn anstatt "sh" "bash" benutzt würde und damit die verwendete Shell eindeutig bestimmt würde?
Ist es doch. Hinter sh steckt kein Zufallgenerator, der wahllos mal die mal die Shell aufruft. Was man in dem Abschnitt hinzufügen könnte ist, dass Nicht POSIX-konforme Skripte (was Bash Skripte sein können) via bash aufgerufen werden müssen. Gruß, noisefloor
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 13015
|
noisefloor schrieb:
aber die Bash ist im Linux-Umfeld im Allgemeinen und unter Ubuntuaner*innen im Speziellen ja das Synonym für "Shell".
weil halt viele Nutzer*innen von der "sh → dash"-Umleitung nicht wissen
Sagt wer bzw. steht wo? Das ganze ist deinerseits rein spekulativ.
Selbst, wenn es so wäre, sehe ich das Argument nicht. Die sh ist nun mal der kleinste gemeinsame Nenner (aka POSIX) und deshalb der Standard.
Wäre es nicht eindeutiger, wenn anstatt "sh" "bash" benutzt würde und damit die verwendete Shell eindeutig bestimmt würde?
Ist es doch. Hinter sh steckt kein Zufallgenerator, der wahllos mal die mal die Shell aufruft.
Genau. Außerdem spricht einiges dafür, die sh als Standardshell für Skripte zu behalten und nur auf bash , ksh , zsh o.a. auszuweichen, wenn bestimmte Features außerhalb des POSIX-Standards benötigt werden. Z.B. ist die dash typischerweise weniger ressourcenhungrig.
Was man in dem Abschnitt hinzufügen könnte ist, dass Nicht POSIX-konforme Skripte (was Bash Skripte sein können) via bash aufgerufen werden müssen.
+1
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 705
Wohnort: Hannover
|
Hallo, nur noch ein bisschen von mir zum Thema... Zumindest unter Lubuntu 18.04 scheint aber die Bash – jedenfalls beim Arbeiten im grafischen Terminal – der Standard zu sein, im Gegensatz zum Skripting: Ich habe daran nichts manuell geändert, es ist also der Standardwert. Zumindest das Linux Professional Institute scheint das aber – wenigstens für seine LinuxEssentials Objectives V1.6(DE) – genauso wie ich zu sehen: 2.1 Grundlagen der Befehlszeile: Gewichtung
3
Beschreibung
Kandidaten sollten die grundlegende Verwendung der Linux-Befehlszeile beherrschen.
Hauptwissensgebiete:
Shell-Grundlagen
Befehlszeilen-Syntax
Variablen
Quoting
Hier ist eine auszugsweise Liste der verwendeten Dateien, Begriffe und Hilfsprogramme:
Bash
echo
history
Umgebungsvariable PATH
export
type
3.3 Von Befehlen zum Skript: Gewichtung
4
Beschreibung
Kandidaten sollten aus sich wiederholenden Befehlen einfache Skripte erstellen können.
Hauptwissensgebiete:
Grundlagen von Shell-Skripten
Wissen über die gängigen Texteditoren (vi and nano)
Hier ist eine auszugsweise Liste der verwendeten Dateien, Begriffe und Hilfsprogramme:
#! (shebang)
/bin/bash
Variablen
Argumente
for-Loops
echo
Exit-Status
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29541
Wohnort: WW
|
Hallo,
Zumindest unter Lubuntu 18.04 scheint aber die Bash – jedenfalls beim Arbeiten im grafischen Terminal – der Standard zu sein, im Gegensatz zum Skripting:
Das ist schon seit 6.10 so, seitdem ist Dash die Standard Nicht-Interaktive Shell bei *buntu. Und das /bin/sh auf /bin/dash zeigt steht auch im Artikel zur Dash. Dir ist der Unterschied zwischen interaktiver und nicht interaktiver Shell klar? Dir ist klar, dass die Bash Befehle kennt, die nicht POSIX-konform sind? Wenn nein → starte bitte einen separaten Thread im geeigneten Supportforum dazu. Dann können wir hier ggf., falls du es für nötig hältst, weiter diskutieren. Warum wir deinen Vorschlag für falsch halten, haben rklm und ich ja schon ausgeführt. Gruß, noisefloor
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 705
Wohnort: Hannover
|
Hallo noisefloor, OK, jetzt verstanden 😳
|
linux_joy
Anmeldungsdatum: 6. Februar 2008
Beiträge: 705
Wohnort: Hannover
|
(...) Dieser Artikel behandelt die manuelle Erstellung von .desktop-Dateien. Neben allgemeinen Einstellungen werden Besonderheiten der jeweiligen Desktop-Umgebung bzw. des Fenstermanagers aufgeführt. Prinzipiell können diese Dateien auch eine Internet-Adresse (URL) enthalten und damit als Lesezeichen (Bookmark) dienen, was hier aber nicht weiter behandelt wird.
Justin-Time schrieb: aasche schrieb: So ganz kann ich immer noch nicht folgen.
Also ich habe es folgendermaßen aufgeteilt: Eine .desktop-Datei kann neben einem Programmstarter auch ein Untermenü und Weblinks erstellen. Die aktuelle Baustelle Baustelle/.desktop-Dateien führt in die Thematik ein und zeigt jeweils ein Beispiel zu den unterschiedlichen Verwendungszwecken. (...)
diesch schrieb: Type=Directory kenne ich eigentlich nur von .directory -Dateien. Die verwenden zwar das gleiche Dateiformat, ich würde das aber trotzdem hier weglassen und dafür in der Einleitung auf .desktop-Dateien/Menü verweisen.
Bei Type=Link kann man nicht nur Weblinks, sondern beliebige URIs verwenden, solange die Arbeitsumgebung damit was anfangen kann, z.B. file:// als Alternative zu Symlinks oder mailto: #!/usr/bin/env xdg-open würde ich überall wegmachen.
Bei "Lokalisierung" würde ich die @MODIFIER evtl. weglassen, das halte ich für eher exotisch. In der Tabelle würde ich "Sprache" und "Region" statt "lang" und "COUNTRY" benutzen. Speziell "lang" ist in einem ansonsten deutschen Text missverständlich.
Hallo zusammen! Frage: Warum eigentlich wird der Themen-Komplex ".desktop-Datei als Lesezeichen (Bookmark)" hier aber nicht weiter behandelt? Unwichtig? Uninteressant? Oder etwa sonstwas? Hat jemand dazu noch andere Erläuterungen (außer Recognized desktop entry keys 🇬🇧)?
|