Login
Newsletter

Thema: GUI oder Konsole?

2 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von msi am Mo, 9. September 2019 um 16:44 #

Gut. Zugegeben. Es gibt ein paar nette Sachen.

Nichtsdestotrotz führt das Thema doch ein Nischendasein.

Das stimmt schon. Ich habe diese paar Sachen ja sozusagen aus 30 Jahren Unix- und Linux-Geschichte zusammengekratzt, wobei ich allerdings z. B. fish gar nicht erwähnt habe.

Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh.
Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.

Mir fallen da verschiedene mögliche Gründe ein.

Zum einen ist es so, dass POSIX eine erweiterte Bourne-Shell als Standard für alle Unix-Systeme spezifiziert und zumindest unter Linux und OpenBSD standardmäßig erweiterte – und in ihrem Erweiterungen weitgehend kompatible – POSIX-Shells zum Einsatz kommen. Solaris wird das schätzungsweise auch so machen. (FreeBSD fällt hier aus der Reihe, aber auch dort ist zumindest die Standard-Shell für normale Nutzer eine erweiterte POSIX-Shell, wenn auch deren Erweiterungen nicht so weit reichen wie bei Bash, KornShell oder Z Shell.)

Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.

Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.

Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.

Das führt gleich zum nächsten Punkt: Bei Betriebssystemshells spielt Rückwärtskompatibilität eine große Rolle.

Desktopumgebungen unter Linux nimmt, wie mir scheint, ohnehin niemand wirklich ernst, was ich gut nachvollziehen kann. Daher ähnelt dieser Bereich, wohl oder übel, auch eher einer Spielwiese für Entwickler.

Mir wäre mehr Diversität bei Unix-Shells auch eher ein Graus. Gut wäre stattdessen, wenn einfach eine Shell wie Es den Status einer gängigen Alternative zu den Bourne-ähnlichen Shells erlangen würde.

  • 0
    Von Andy_m4 am Mo, 9. September 2019 um 18:25 #

    z. B. fish gar nicht erwähnt habe.
    Ja. Fish kenne ich auch. Finde ich eigentlich auch gar nicht so schlecht. Bietet nette Funktionen und ist auch vom Start weg sehr gut benutzbar ohne das man irgendwas konfigurieren muss.
    Man hat sozusagen schon was davon, indem man sie einfach nur installiert.
    Mir geht sie aber in manchen Dingen einfach nicht weit genug und macht Dinge anders als ich sie mir wünschen würde.
    Dennoch ist es eine sehr empfehlenswerte Shell für Leute die da mal was anderes abseits von Bash probieren wollen.

    Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.
    Ich sag ja auch nicht, das andere Shells dafür verschwinden sollen. Aber als Ergänzung? warum nicht?

    Kann man ja so ein bisschen vielleichen mit dem vi. Den gibts auch "überall". Wenn Du also irgendwie unter nem "UNIX" ne Datei editieren willst, kannst Du sicher sein nen vi zu haben. Es ist praktisch, wenn man den zumindest halbwegs beherrscht.
    Trotzdem würde ich nicht auf die Idee kommen ihn deshalb ständig einzusetzen.

    Warum sollte ich das bei einer Shell nicht machen? Ich muss ja nicht mal meine Standardshell ändern. Ich kann ja meine Lieblingsshell jederzeit aufrufen, wenn ich meine ich möchte sie in dem Augenblick nutzen.

    Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.
    Genau dann ist aber die Shell eher wacklig. Gerade wenn Du Scripting-Sachen machst. Es gibt einfach so viele Stolperfallen. Klar kann man die umgehen. Aber besser ist natürlich, wenn es die gar nicht erst gibt.

    Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.
    Hat ja auch niemand behauptet, das bestehende Skripte alle neu geschrieben werden sollen.

    Aber wo wir gerade beim Scripting sind:
    Ne Shell erfüllt ja i.d.R. heutzutage zwei Aufgaben. Erstens das schon angesprochene Scripting, zweitens eine interaktive Benutzerstelle. Mal abgesehen davon, das es gegen "one Job one tool" verstößt ist es auch so, das es beides nicht optimal erfüllt und vielleicht auch nicht erfüllen kann.
    Nicht umsonst gibt es ja immer mal wieder Bestrebungen den Scripting-Teil mit was anderem zu machen. Perl ist ja da das klassische Beispiel für. Die reellen Geschehnisse zeigen also schon, das es da eine gewisse Spannung in der Thematik gibt.

    Fürs Bereich Skripting hat sich da ne Menge getan. Sei es nun Perl, Python, Ruby oder was auch immer, da gibt es reichlich Optionen die den Teil angehen und Alternativen bieten. POSIX-Shell-Scripte oder von mir aus auch noch Bash-Skripte haben natürlich weiterhin den Charme, das sie überall ohne großarige Voraussetzungen laufen. Aber damit hat es sich auch schon an Vorteilen.
    Auf der Seite der Interaktion mit dem Nutzer hast Du das meines Erachtens nach weniger Bewegung drin. Es gibt sie, aber die sind eben (wie schon gesagt) nicht so präsent.

    Wie gesagt. Es schätze es auch, wenn es einen Minimalstandard gibt der überall funktioniert. Für den täglichen Gebrauch wäre mir das aber dann doch zu rudimentär und unkomfortabel.

Pro-Linux
Gewinnspiel
Neue Nachrichten