ubuntuusers.de

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.

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:

1
2
3
4

$ { 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:

1
2
3
4
5
6

$ { sleep 10; echo background; } & { sleep 5; echo foreground; }; wait
[1] 23436
foreground
background
[1]+  Done                    { sleep 10; echo background; }
$ 

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.

BillMaier schrieb:

• Welche Desktop-Umgebung bringt keinen Menü-Editor mit? Menüeditor sieht recht vollständig aus imho.

Zum Beispiel die GNOME Shell, die jetzt Standard in Ubuntu ist. Von anderen weiß ich es nicht genau.

• was ist falsch daran, sich Desktop-Starter auf den Desktop zu legen?

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. 😉

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 👍

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]

Hallo,

Inyoka kann alles und das ist so einfach, dass machen wir zwischen 12 und Mittag. Der Redirect ist angelegt.

Gruß, noisefloor

noisefloor schrieb:

Inyoka kann alles und das ist so einfach, dass machen wir zwischen 12 und Mittag.

😬

Der Redirect ist angelegt.

Thx

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:

1
2
3
4
5
6
7

~$ 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

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

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

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:

  1 2	~$ echo $SHELL /bin/bash

  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

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

Hallo noisefloor,

OK, jetzt verstanden 😳

(...)
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 🇬🇧)?