staging.inyokaproject.org

[Kwami] CLI versus GUI

kwami.png

kaputtnik macht sich in diesem Beitrag Gedanken über die Vor- und Nachteile der beiden Benutzerschnittstellen GUI und CLI. Neben einer kurzen Einführung zum Begriff „Benutzerschnittstelle“ versucht er die wesentlichen Punkte heraus zu arbeiten.

Hinweis:

Dieser Artikel gehört der Kategorie Kwami an. Er spiegelt damit allein die Meinung des Autors und nicht zwingend die des ubuntuusers.de-Teams wider.

Oft liest man im Forum, dass eine „richtige“ Benutzung von Linux auf der Kommandozeile (CLI = Command-Line Interface) erfolgen sollte. Viele Umsteiger von anderen Betriebssystemen sind jedoch die Benutzung per grafischer Benutzerschnittstelle (GUI = Graphical User Interface) gewohnt und können sich nur schwer mit der Eingabe von Text in einem Terminal anfreunden. Eine Gegenüberstellung der Benutzerschnittstellen GUI und CLI, dabei hat jede Art seine Vor- und Nachteile…

Benutzerschnittstelle

Um ein Programm bedienen zu können, muss es die Möglichkeit bieten, Eingaben entgegen zu nehmen und nach der Verarbeitung der Daten eine Ausgabe zu erzeugen. Am einfachsten für den Programmierer ist eine solche Ein- und Ausgabe per Kommandozeile zu realisieren, da er sich nicht um die Eigenheiten verschiedener Grafikbibliotheken, wie Qt oder GTK, zu kümmern braucht. Er kann sich voll und ganz auf die Verarbeitung der Daten konzentrieren und an beliebiger Stelle im Quellcode einen Text auf die Kommandozeile ausgeben. So liegen die meisten Programme in einer Kommandozeilenversion vor. Eine grafische Schnittstelle für dieses Programm wird erst später, oft durch andere Programmierer, dem eigentliche Programm übergestülpt. Arbeitet man mit „grafischen Programmen“, so nutzt man oft nur ein Frontend, die eigentliche Arbeit machen Konsolenprogramme im Hintergrund. Die Kommunikation zwischen Programm und GUI erfolgt dabei über andere Wege als über das Terminal.

CLI

Vorteile CLI

Exit status vom Programm cd
Exit status:
0 if OK,
1 if minor problems (e.g., cannot access subdirectory),
2 if serious trouble (e.g., cannot access command-line argument).

Verfechter der CLI-Benutzung führen an, dass eine grafische Benutzeroberfläche das eigentliche Geschehen, also was ein Programm gerade macht, versteckt. Man sieht nicht, was im Moment passiert, oder welche Meldungen ausgegeben werden. Grund hierfür ist der unterschiedliche Kommunikationsweg. Grafische Benutzerschnittstellen erhalten bei einem Fehler in der Regel nur einen Exit status in Form einer Nummer zurück.

Wenn also zum Beispiel das Software-Center eine Aktion mit der Mitteilung „Das Paketsystem ist beschädigt“ quittiert, wird dem Benutzer nur ein Fehler mitgeteilt, aber nicht, wie er es möglicherweise lösen kann. Welche Meldungen Programme darüber hinaus in einem Terminal ausgeben können, sieht man sehr gut, wenn man ein grafisches Programm über das Terminal startet. Hier beispielsweise beim Start von Spiele/Widelands:

$ widelands
Set home directory: /home/kaputtnik/.widelands
No version file found
Adding directory:/usr/share/widelands
Version file found with id "build-17" (real "build-17" )
No version file found
Adding directory:/usr/share/games/widelands
Adding directory:.
No version file found
selected language: (system language)
using locale de_DE.UTF-8
SDL_VIDEODRIVER=&
Graphics: Trying Video driver: 0 x11 SDL_VIDEODRIVER=x11
Graphics: Trying opengl
Graphics: Try to set Videomode 1280x960 32Bit
Graphics: Setting video mode was successful
[…]

Bei einem Start über das Menü sieht man von diesen Dingen nichts.

Um auf das Software-Center zurück zu kommen: Wird statt dem Frontend Software-Center das eigentliche Programm APT auf der Kommandozeile ausgeführt, sind die Fehlermeldungen in der Regel viel aussagekräftiger.

Gerade im Forum sind diese Ausgaben gegenüber einem Bildanhang von enormen Vorteil:

  • Es sind Textausgaben, die man beliebig zitieren, kürzen oder auch markieren kann

  • Textausgaben sind immer lesbar und unabhängig von Bildschirmauflösung und Bildformat

Werden vom Helfenden weitere Abfragen gefordert oder eine Lösung per CLI-Befehl gegeben, können sie von jedem einfach kopiert ( Strg + C ) und in einem Terminal eingefügt ( + Strg + V ) werden. Vorgangsbeschreibungen wie

Nutzt Du das Softwarecenter, dann klicke darin auf „Bla“, im Reiter „Blup“ kannst Du unten die Einstellung wie folgt ändern: […] Wenn Du ein anderes Programm benutzt geht es anders, dann klickst Du auf […]

entfallen, wenn einem gesagt wird, in welcher Konfigurationsdatei man welche Änderungen vornehmen soll. Statt sich durch unzählige Menüs zu klicken, ist es manchmal einfacher, den entsprechenden Wert in einer Konfigurationsdatei zu ändern. Bei dem Versuch einen Großteil des Systems über Konfigurationsdateien zu konfigurieren, kommt man jedoch sehr schnell an die Grenzen der CLI, da viel Wissen erforderlich ist.

Nachteile CLI

Um eine Einstellung in einer Konfigurationsdatei ändern zu können, muss ich

  1. wissen, wo die Konfigurationsdatei liegt und wie sie heißt

  2. wie der Wert, die Einstellungsoption, in dieser Datei bezeichnet ist und welche Werte ich Ihr geben kann

Sich dieses Wissen anzueignen ist mit viel Aufwand verbunden. Gerade für Konsolen-Programme sind solche Angaben zwar sehr gut in den Man-Pages dokumentiert, diese liegen jedoch oft nur in englischer Sprache vor. In der Regel eignet man sich aber die gängigsten Optionen und Parameter eines Befehls mit der Zeit an. Ein

sudo apt-get update 

ist schnell zu merken, erfordert aber Schreibarbeit. Schreibarbeit ist mit der Gefahr von Syntaxfehlern bzw. Schreibfehlern verbunden und können bei potenziell gefährlichen Befehlen das System beschädigen. Obiger Befehl ist dabei ein vergleichsweise kurzer (und ungefährlicher) Befehl, der mit Hilfe der History schnell wieder hervor zu holen und zu korrigieren ist. Bei einem

ffmpeg -f x11grab -s 1680x1050 -i :0.0 -s 840x525 -vcodec libx264 -b 4000k -vpre medium -an AUSGABEDATEI 

sieht die Suche nach Schreibfehlern und deren Korrektur schon etwas anders aus.

GUI

Vorteile GUI

cli_vs_gui_tooltip.jpg
Tooltip in der GUI KFind

Eine grafische Benutzeroberfläche versucht alle Optionen und Kommandos sinnvoll zu sortieren und in Gruppen aufzuteilen. Oft werden dabei mehrere Konsolenprogramme in einer Oberfläche verschmolzen. Als Beispiel sei hier GParted genannt, welches für unterschiedliche Arbeiten auch unterschiedliche Programme bzw. Bibliotheken benutzt:

Die GUI bietet die Möglichkeit die entsprechenden Optionen gleich mit (mehr oder weniger) verständlichem Text zu versehen und per Mausklick zu (de)aktivieren. In der Regel stehen die Programme in der richtigen Sprache zur Verfügung und bieten weitere Hilfen per Tooltip bzw. umfangreichem Hilfesystem an.

Zudem lassen sich die Auswirkungen verschiedener Optionen meistens per Klick testen. Die GUI vermindert dabei die Gefahr von Schreibfehlern, da Optionen und Kommandos fest im Programmcode hinterlegt sind.

Nachteile GUI

Eine GUI wird quasi ausschließlich mit der Maus bedient. Ist Schreibarbeit nötig, muss ständig zwischen Maus und Tastatur gewechselt werden, was unnötige Bewegungsabläufe erfordert.

Die Bedienung eines GUI-Programms muss genauso erlernt werden, wie die eines Terminalprogrammes. Auch wenn Optionsschalter beschrieben sind, heißt es noch lange nicht, dass man deren Auswirkungen auch versteht. Ein Grundlagenwissen ist auch hier erforderlich.

Die Auswertung und Darstellung eines vom Terminalprogramm zurück gegebenen Fehlercodes obliegt dem Programmierer der grafischen Benutzerschnittstelle, was er aber aufgrund von nicht reproduzierbaren Fehlern nicht immer berücksichtigen kann.

Mein Fazit

Ob man GUI oder CLI präferiert muss jeder für sich selber entschieden. Ich persönlich habe die Trennlinie zwischen CLI und GUI auf die Grenze zum System gelegt: Bei allen Arbeiten die einen Eingriff mit Rootrechten erfordert bevorzuge ich CLI. Für die Arbeit mit Konfigurationsdateien nutzte ich nano, ein Terminalprogramm. Für das produktive Arbeiten benutzte ich ausschließlich GUI, es sei denn für ein Programm wurde noch keine GUI geschrieben…

Bei Fehlern oder Problemen mit einem grafischen Programm sollte man aber immer schauen, ob der Start in einem Terminal bessere Fehlermeldungen hervor bringt.

Über den Autor

kaputtniks Computerhistorie begann mit dem VC20 und damit einhergehend erste Erfahrungen mit Basic. Später folgten Rechner mit MSDOS, Windows for Workgroups, IBM os2 Warp und Windows 2000. Im Dezember 2007 kam Ubuntu Gutsy Gibbon zuerst auf den Laptop und dann auf den Desktoprechner. Inzwischen nutzt er Arch-Linux, einmal im Monat wird zwecks Buchführung das parallel installierte Windows 7 gestartet.

Veröffentlicht von Keba | 3. September 2013 12:55 | Kategorie: Kwami | # Fehler im Artikel melden

Inkane

1 3. September 2013 13:27

Ein weiterer der Vorteil CLI: Es lässt sich deutlich leichter automatisieren als GUIs. Noch zum Nachteil, dass für GUIs zwingend die Maus von Nöten wäre: Das lässt sich oft mit ein bisschen zusätzlicher Programmierarbeit von Seiten des Erstellers beheben: Taborder vernünftig setzen, Shortcuts für alle häufig benötigten Aktionen einführen, Möglichkeit einführen, eigene Shortcuts zu setzen, et cetera…

ingo2

Avatar von ingo2
2 3. September 2013 16:23

Gut dargestellt!

Beides, GUI und CLI haben ihre Berechtigung - und der Satz "Arbeitem als root am System mache ich per CLI" trifft auch meine Arbeitsweise auf den Kopf. Gilt natürlich nicht für mein NAS, das hat keine GUI.

Zur Historie:

auch ich bin mit dem "Ende" von OS/2 auf Linux gekommen und habe mit Feisty angefangen. Noch heute habe ich hier meinen alten PC mit Warp4 incl. aller Daten in einer VM unter VBox laufen - meistens spiele ich aber nur "Harfe" 😉

fuchsfuchsfuchs

Maskottchen

Avatar von fuchsfuchsfuchs
3 3. September 2013 17:45

Mh. Ein paar Gedanken dazu aus meiner Sicht (also etwas UX): (Einiges hat Inkane schon geschrieben)

Ein klarer Vorteil von CLI ist in meinen Augen die Effizienz. Vor allem wenn man eine repetitive Aufgabe anhand eines Musters ausführen will, z.B. das Kodieren, Umbenennen oder sonstige Manipulieren von bestimmten Dateien (Beispiel: alle JPEG Bilder unterhalb eines bestimmten VerzeichnisseS) ist man in der Regel deutlich effizienter, _wenn_ man die entsprechenden Befehle kennt.

Ein weiterer Vorteil ist, dass über Aus- und Eingabeumleitung (<>) inklusive Pipes (|) Kommandos sehr gut verschachtelt werden können. Moderne Shells, wie etwa Microsofts Powershell, ziehen das noch einmal deutlich weiter, da man nicht auf Text beschränkt ist sondern ganze Objekte hin- und hergereicht werden können.

Zu der Anmerkung, dass eine GUI quasi nur per Maus zu bedienen ist: dann wurde die schlicht und einfach schlecht konzipiert und/oder programmiert. Es ist heute allerdings so, das viele Tastenkombinationen (Tab zum Fokuswechsel, CTRL+Pfeiltasten, End/Home mit Shift oder Control ...) den meisten Leuten nicht mehr bekannt sind, weil es eben die Maus gibt. Gemäss dem GOMS Modell ist eine reine mausbasierte (vor allem wenn man hotspots berüchtigt) oder rein keyboard basierte Interaktion ziemlich schnell, der Wechsel zwischen den beiden dauert aber so lange, dass man das versucht zu reduzieren. Deswegen ärgere ich mich immer wieder, wenn in einen Programmen / Umgebungen vieles aber eben nicht ganz alles mit der Tastatur geht (Plasma ist da ein sehr gutes Negativbeispiel)

Das mit dem Automatisieren ist aber auch wieder nur bedingt korrekt. Es gibt Systeme, wo Controls eindeutige Identifkatoren haben und deswegen auch eine GUI problemlos automatisiert werden kann.

Ein Hauptproblem, sowohl bei CLI wie auch bei GUI, ist, dass es den meisten Entwicklern entweder an den Grundlagen für Usability fehlt oder der Unterschied zwischen Entwickler und Anwender zu gross ist.

Schlussendlich haben, wie in meinen Augen richtig dargestellt, beide Systeme nicht nur ihre Vor- und Nachteile, sondern auch ihr Anwendungsgebiet. Und es täte den meisten Leuten gut, beides ein wenig auszuprobieren um sich mit den jeweiligen Konzepten vertraut zu machen.

Fuchs

t.type

4 3. September 2013 18:19

Stimmt alles, ändert aber nichts daran, dass Bash u.ä. ein unfassbar hässliches Überbleibsel der 70er Jahre sind und hoffentlich irgendwann von Python in Rente geschickt werden.

Kätzchen

Avatar von Kätzchen
5 3. September 2013 19:34

Danke für den Artikel ☺ Ich bin dankbar das es GParted gibt....

ingo2

Avatar von ingo2
6 3. September 2013 20:09

@5:

Ich bin dankbar das es GParted gibt....

Bin ich genauso. Viele Dinge werden durch die Kommandozeile aber erst möglich. Ich denke da an kleine nützliche Bash-Scripte, mit denen man eine Menge machen und regelmäßig wiederkehrende Aufgaben automatisieren kann. Das ist ungeheuer nützlich und andererseits mit gutem Willen auch für Jedermann machbar.

Die Möglichkeiten des "Scripting" sind für mich das tollste Feature vom XFCE-Desktop, abgesehen von der gewohnten alten Struktur (oder Experience wie das ja jetzt heißt).

Wer's dann obendrein noch bunt haben will, gibt's "zenity" 😉

trollsportverein

Avatar von trollsportverein
7 3. September 2013 20:43

Mein Lieblingsscript zum aktuell halten: update.sh:

1
2
#!/bin/sh
sudo apt-get update && echo yes | sudo apt-get dist-upgrade

Ein dreifach Hoch auf die Bequemlichkeit. ☺

seahawk1986

8 3. September 2013 21:14

@7: Ist das nicht einfacher?

1
2
#!/bin/sh
sudo apt-get update && sudo apt-get -y dist-upgrade
        -y, --yes, --assume-yes
           Automatisches »Ja« auf Anfragen; Versucht »Ja« auf alle Anfragen zu
           antworten und ohne Eingaben zu laufen. Wenn eine unerwünschte
           Situation eintritt, wie ein gehaltenes Paket zu ändern, ein nicht
           authentifiziert Paket zu installieren oder ein essentielles Paket
           zu entfernen, dann wird apt-get abgebrochen. Konfigurationselement:
           APT::Get::Assume-Yes.

ingo2

Avatar von ingo2
9 3. September 2013 21:36

Kannst natürlich auch einfach das Paket "cron-apt" installieren und konfigurieren, dann braucht man garnix mehr zu tun. Info dazu (auf jedem debianoiden System) mit (antwortet sogar Deutsch!):

apt-cache show cron-apt

Jetzt kommen wir aber schon wieder in die Zwickmühle: Bequemlichkeit ←> Sicherheit+Kontrolle.

ingo2

Avatar von ingo2
10 3. September 2013 21:58

Aber hier noch ein nüzliches Beispiel:

Herausfinden der eigenen globalen IPv4-Adresse:

curl ifconfig.me

Developer92

Avatar von Developer92
11 3. September 2013 22:23

@4:

Stimmt alles, ändert aber nichts daran, dass Bash u.ä. ein unfassbar hässliches Überbleibsel der 70er Jahre sind und hoffentlich irgendwann von Python in Rente geschickt werden.

Bash ist eine Shell, Python eine zum Programmieren geschaffene Interpretersprache. Das beißt sich ein wenig. Wie wärs mit Zsh oder anderen Shells?

@10: Danke, wusste nicht, dass das so einfach geht.

Lasall

Ehemalige

Avatar von Lasall
12 3. September 2013 22:26

@9: cron-apt ist veraltet, man sollte besser unattended-upgrades nutzen, dass auch noch deutlich mehr Features hat.

Ice_Polar

Avatar von Ice_Polar
13 3. September 2013 22:34

@ingo2

Äh? "Die Anwendung »curl« ist momentan nicht installiert. Sie können sie durch folgende Eingabe installieren: sudo apt-get install curl"

Nun gut, ich bin ja vollkommen einverstanden mit den Erkenntnissen hier, aber einfach ist nichts, weder CLI noch GUI.

Wenn ich dabei mal auf die Diskussionen hier im Forum verweisen darf wo das alte GUI dermassen gelobt wird und das neue aktuelle Unity-GUI als untauglich eingestuft wird - schaut Euch mal Windows 8 an, dann seht Ihr Unity versöhnlicher! DAS ist der Weg; und es wird noch viel weiter gehen!

Ich bin mit Ubuntu 6.04 in die Linux-Welt eingestiegen und hatte mich vorher bereits seit Windows 3.11 mit GUI herumgeschlagen, auch OS/2 hatte ich installiert - davor gab's ja eh nur CLI. Als Applikation hatte ich früher sogar eine Textverarbeitung ohne GUI - WYSIWYG kam erst später... Zum Glück ist diese Zeit vorbei 😉

ingo2

Avatar von ingo2
14 3. September 2013 22:49

@13:

Äh? "Die Anwendung »curl« ist momentan nicht installiert. Sie können sie durch folgende Eingabe installieren: sudo apt-get install curl"

Sind nur 270kB und wird von anderen nützlichen Scripten und Tools fürs Netzwerken auch genutzt. Das kann aber unglaublich viel!

diesch

Avatar von diesch
15 4. September 2013 00:34

Ein paar Anmerkungen:

Am einfachsten für den Programmierer ist eine solche Ein- und Ausgabe per Kommandozeile zu realisieren, da er sich nicht um die Eigenheiten verschiedener Grafikbibliotheken, wie Qt oder GTK, zu kümmern braucht.

Das stimmt meiner Erfahrung nach nicht. Ob die Ein- und Ausgabe per GUI oder CLI einfacher ist, hängt davon ab, was für Daten ein- und ausgegeben werden sollen. Es kann z.B. sehr viel einfacher sein, sich eine simple GUI zusammenzuklicken, als sich einen Kommandozeilen-Argumente-Parser für die gleichen Daten zu schreiben.

Bei einer GUI muss man sich nicht um die Eigenheiten verschiedener Grafikbibliotheken kümmern, sondern nur um die eine, die man benutzt.

Arbeitet man mit „grafischen Programmen“, so nutzt man oft nur ein Frontend, die eigentliche Arbeit machen Konsolenprogramme im Hintergrund.

Das ist eigentlich nur recht selten der Fall. Viel häufiger sind die eigentlichen Funktionen in einer Bibliothek vorhanden, die von GUI und CLI genutzt wird.

Grafische Benutzerschnittstellen erhalten bei einem Fehler in der Regel nur einen Exit status in Form einer Nummer zurück.

Nein. Selbst wenn eine GUI-Programm ein CLI-Programm aufruft, kann es im Normalfall alle Meldungen lesen, die das CLI-Programm ausgibt. Es ist aber oft nicht einfach, die zu interpretieren, weil sie oft nicht sauber dokumentiert, nicht eindeutig und/oder versionsabhängig sind.

Das Beispiel "Software Center" ←> "apt-get" ist schlecht gewählt, da beide auf libapt aufsetzen (Software-Center nur indirekt über aptdaemon). libapt ruft in beiden Fällen dpkg auf, und weder Software-Center noch apt-get können dessen Ausgaben wirklich interpretieren.

apt-get gibt aber mehr davon an den Benutzer weiter. Für Benutzer, die sich etwas damit auskennen, ist das oft hilfreich, für Benutzer, die nichts mit den Meldungen anfangen können, oft eher abschreckend.

Software-Center gibt oft auf Verdacht Tipps zur Fehlerbehebung. Das funktioniert bei Standardproblemen oft ganz gut, führt bei exotischeren Problemen aber auch oft in die Irre.

Um eine Einstellung in einer Konfigurationsdatei ändern zu können, muss ich wissen, wo die Konfigurationsdatei liegt und wie sie heißt

Auch CLI-Programme können eine Möglichkeit anbieten, ihre Konfiguration per Programm zu ändern, so dass man die Konfigurationsdatei nicht von Hand ändern muss.

Und bei manchen GUI-Programmen lassen sich zumindest ein Teil der Konfigurationsmöglichkeiten nur in einer Konfigurationsdatei ändern.

Schreibarbeit ist mit der Gefahr von Syntaxfehlern bzw. Schreibfehlern verbunden und können bei potenziell gefährlichen Befehlen das System beschädigen.

Bei einer GUI ist das nicht wesentlich anders: Da kann man schnell mal eine falsche Option auswählen oder einen falschen Knopf drücken.

Der Hauptnachteil von CLI ist, dass man die meisten Befehle, Optionen und Argumente auch mit viel Hintergrundwissen nur selten erraten kann, sondern sie erst lernen muss, weil es nur sehr wenige verbreitete Standards gibt. Dadurch dauert es relativ lange, bis man mit einer Kommandozeile flüssig arbeiten kann.

Die programmierbare Befehls-Vervollständigung moderner Shells wie Bash oder zsh kann da aber sehr hilfreich sein.

Wenn man aber erst mal Übung mit der Kommandozeile hat, ist man oft schneller damit als mit einer GUI, vor allem, wenn man schnell tippen kann. Und man kann das erworbene Wissen oft direkt benutzen, um Vorgänge per Shellskript zu automatisieren, ohne erst zusätzliche Werkzeuge oder Makrosprachen lernen zu müssen.

Ich benutze recht undogmatisch das, womit ich glaube, einfacher oder schneller arbeiten zu können (nano gehört da nur sehr selten dazu 😉 )

Yanneck

Avatar von Yanneck
16 4. September 2013 00:59

Ich mache meine komplette Dateiverwaltung auf der Konsole und finde, dass mein Heimatverzeichnis wesentlich aufgeräumter daherkommt, seit ich das so handhabe. Natürlich ist Ordnung auch mit grafischen Dateiverwaltern möglich.

t.type

17 4. September 2013 10:48

@11: Irgendwann gibt es halt eine Python-Shell. Zsh hätte man auch Babash nennen können. Will doch alles niemand wirklich haben...

fuchsfuchsfuchs

Maskottchen

Avatar von fuchsfuchsfuchs
18 4. September 2013 12:57

@17: Gab es bereits (pysh) und aehnliche Konzepte gibt es bereits (ipython). Aber das hilft in der Tat alles nichts, wenn die meisten Anwendungen und das System das nicht nutzen / ausreizen.

Unter Windows hat man halt den Vorteil, dass alles von einem Hersteller kommt und dieser die Schnittstellen vorgibt. Die powershell wird dadurch zu einem weitaus mächtigeren Werkzeug als die bash (oder auch eine csh, korn shell, zsh ...) es sein kann. Dafuer gehen einige eigentlich alltaegliche Aktionen relativ schwerfaellig von der Hand.

Die Entwicklung ist auf jeden Fall interessant, mit meiner zsh bin ich aber vorerst groesstentteils zufrieden.

t.type

19 4. September 2013 13:29

@18: Genau, Pysh(ell). (Hatte ich nicht gefunden.) So etwas wird sich irgendwann durchsetzen. Bin ich mir sicher. Bis dahin Bash; weil Standard.

Danton

Avatar von Danton
20 5. September 2013 12:35

@17: Die frage ist was man tun will, für Dateiverwaltungsaufgaben ist die Shell(sh) mit ihren ganzen Shortcuts besser, wer mehr braucht kann auch die Bash oder Zsh nutzen. Wo bei die Zsh von vorne an einen anderen Ansatz zur Bourne Shell Kompatibilität gewählt hat: nämlich den das er nicht relevant ist und man besser aufräumt. Irgend wann ist noch der Punkt erreicht das man besser Perl oder Python nutzen sollte.

trollsportverein

Avatar von trollsportverein
21 7. September 2013 05:50

@ingo2: Wenn jemand zuguckt sieht das nach IP gucken aber mit eskaliertem grep Einsatz wichtiger aus:

1
echo "Die IP-Adresse ist: `wget http://www.wieistmeineip.de -U "" -qO - | egrep -o '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}' | uniq`"

ingo2

Avatar von ingo2
22 7. September 2013 12:13

@21: 👍