• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Sind less und vi(m) etc. noch zeitgemaess?

Vril

Well-Known Member
Themenstarter #1
Sind less und vi(m) etc. noch zeitgemaess
oder braucht man inzwischen ein virtuelles Windows mit Word um
die /etc/rc.conf zu ändern? ;-)
 

ralli

BSD Fanboy
#2
Sind less und vi(m) etc. noch zeitgemaess
oder braucht man inzwischen ein virtuelles Windows mit Word um
die /etc/rc.conf zu ändern? ;-)
Nach meiner Wahrnehmung sind diese kleinen Tools zeitlos und leisten auch heute noch gute Dienste. Auch grep in Verbindung mit less benutze ich öfters. Diese Tools aus dem Werkzeugkasten sind Juwelen und für echte UNIX Jünger unverzichtbar. Wenn ich mich irre, kann ich das auch verkraften.;)
 

mr44er

Well-Known Member
#3
Warum die Frage aufploppt ;)

Ich find den 'ee' für mich prima, weil intuitiv, immer vorinstalliert und für meinen Einsatz bisher ausreichend. Falls mal nix vorinstalliert ist, nutze ich 'nano' auf xBSD/Linux. :D
 
#4
Ich habe mir da ehrlich gesagt noch keine Gedanken gemacht. Ich nutze vi seit Mitte der 90er, weil im Buch "Linux in a Nutshell" damals das Kapitel "vi" vor "emacs" war und ich dann in meinen Linux Anfaengen einfach bei vi geblieben bin. Fuer vi user sind less oder auch die man-pages intuitiv bedienbar.

Inzwischen nutze ich auch intensiv emacs, weil er fuer mich in vielen Situationen der bessere Editor ist. Mein muskulaeres Gedaechtnis schaltet dann auch ohne Probleme zwischen emacs und vi keybindings um.

Das geht wohl den meisten BSD- und Linux-Entwicklern aehnlich und daher wird sich vermutlich auch nichts an diesen tools aendern. Die einzige Moeglichkeit waere wohl, patches fuer less & co einzureichen, um dann ueber spezielle flags in den configs die keybindings zu aendern.

Ich kann mir aber gut vorstellen, dass nicht jeder vi oder emacs mag und lieber klassisch mit den Cursortasten, der Maus und Windows-ueblichen shortcuts arbeiten moechte.

Wer moechte, kann natuerlich auch einen anderen pager nutzen oder nachinstallieren. Selbst emacs oder nano lassen sich als pager missbrauchen.
 

mr44er

Well-Known Member
#5
Ja, da ich auch ein starkes Gewohnheitstier bin, ist der easy editor irgendwie vom ersten Tag eingebrannt.

Falls mal irgendwann der Bedarf auf vi/vim/emacs fällt, dann brauchts nur ein wenig Umgewöhnungszeit. Bin z.B. zuletzt von pf auf ipfw gewechselt, da gab es einige WTF-Momente...junge, junge. :rolleyes:
'Das zieht sich bei' sagt man bei uns.
 

Andy_m4

Well-Known Member
#6
Man sollte vielleicht vorweg erwähnen, dass die Diskussion im Rahmen dieses Threads:
https://www.bsdforen.de/threads/wie...ta4-aktualisieren-ohne-neuinstallation.34670/

entstanden ist und dort auch schon Einiges dazu gesagt worden ist.

Sind less und vi(m) etc. noch zeitgemaess
Naja. Was heißt zeitgemäß. Die Bedienung der Tools unterscheidet sich eben von dem, was heute üblich geworden ist. Das hatte ich ja im verlinkten Thread schon thematisiert. Auch, dass man einige Möglichkeiten ungenutzt liegen lässt. Wie halt beim Pager less.

Aber wenn es schon ein eigenen Thread dazu gibt, würde ich das sogar noch erweitern in die Richtung: Wie modern ist die Kommandozeile?
Wir alle sind uns sicher einig, dass die Kommandozeile ein nützliches Werkzeug ist.
Was mich verwundert ist aber, dass man da wenig echte Weiterentwicklung sieht (korrigiert mich gerne, wenn ich falsch liege). Klar gibt es Verbesserungen. Ein Punkt liegt darin, dass man immer noch relativ strenge Trennung hat. Auf der einen Seite hat man halt die GUI-Welt. Auf der anderen Seite halt die Welt der Kommandozeile. Echte Interaktion gibt es wenig. Hier und da mal wie z.B. in der Terminal-Emulation, dass z.B. ein Link als Link erkannt wird und sich dann draufklicken lässt, um die Seite in einem Webbrowser zu öffnen. Bei solchen Gimmicks hörts dann aber meist schon auf.

Warum nicht sowas wie: Ich gebe mit ls ein Verzeichnis aus und dann Klick ich auf deine Datei und öffne die oder zieh die meinetwegen in ein Dateimanager-Fenster, um sie zu kopieren/zuverschieben/whatever.
Mir ist natürlich klar, warum das so ohne Weiteres nicht geht. Weil das Terminalfenster nur eine Textausgabe ist und der Text nicht mit semantischer Bedeutung a-la "Dieses Element repräsentiert die folgende Datei" hinterlegt ist. Aber niemand sagt, dass es so sein muss.

Es gibt dann noch die Thematik, dass viele Kommandozeilenfunktionen zu kompliziert sind und/oder wo ein und die selbe Aufgabe in vielen Tools verteilt sind. Darauf möchte ich jetzt noch nicht so eingehen. Aber eine Sache, die mich seit längerem stört ist, dass man auf der Kommandozeile beim Daten weiterreichen immer wieder Ausgaben parsen muss. Weil es gibt nur Textausgaben. So in der Art "reich mal ein Datum weiter" gibts nicht. Der Empfänger ist gezwungen das Datum zu parsen, weils halt keine Datentypen oder gar Datenstrukturen gibt.
Auch das ist in der UNIX-Welt seit Jahr und Tag gleich und unverändert. Ironischerweise greift dann die Idee ausgerechnet Microsoft in ihrer PowerShell auf.
Es erleichtert halt vieles und minimiert Fehlerquellen. Manche Tools bieten ja durchaus die Möglichkeit an, dass sich z.B. Ausgaben in JSON ausgeben lassen und dergleichen. Aber das sich da mal richtig ein Standard herausbildet und man das auch versucht übergreifend umzusetzen, dass fehlt irgendwie.

Wie gesagt. Es gibt an vielen Stellen natürlich Verbesserungen und so weiter. Aber so richtig mal was Neues, wo man sich hinsetzt und sagt "nach all den Erfahrungen, wie würde man heute eine Kommandozeile und ihre Tools aufziehen wenn man noch mal neu anfangen würde" das sehe ich irgendwie gar nicht. Und das finde ich etwas verwunderlich, wo doch gerade die Kommandozeile als DAS DING also DAS WICHTIGE WERKZEUG in der UNIX-Welt hochgehalten wird. Da würde man ja vermuten, dass da auch am ehesten versucht wird, die Arbeitsumgebung zu optimieren.

Jetzt werden natürlich auch viele Leute kommen und Gründe nennen, warum es doch gut ist den alten Kram zu nutzen und wo solche Ansätze wie eben beschrieben sind nicht funktionieren.
Da kann ich nur sagen: Diese Einwände sind sicherlich durchaus berechtigt. Und ich sehe mich auch nicht in der Position, dass ich sage die Vorgehensweise ist die einzig Richtige. Ich sag nur, in manchen Szenarien würde es aus meiner Sicht Sinn machen. Und warum sollte ich darauf verzichten, wenns in manchen Szenarien nicht passt?
Und ich will ja die alten Tools auch nicht ersetzen. Es wäre wenn, dann nur eine alternative Möglichkeit.
 

medV2

Well-Known Member
#7
Interaktion zwischen GUI - Welt und Terminal will man halt auch nicht wirklich. Die meisten Unix Installationen sind ohne Gui, auf dem Server will/brauch ich keine GUI, in Jails/Containern schon gar nicht. Ich müsste für so fancy Funktionen also immer schauen: Hab ich hier ne Gui am laufen, bin ich ein "xterm" oder ähnliches? Und dann müssten beide Fälle unterschiedlich behandelt werden. Auch kann es sein, dass ich ein langsames Terminal habe (eben wirklich ein Terminal über serielles Kabel, oder auch ssh über scheiß 2G).

Zum Thema PowerShell stimm ich dir zu, damit lässt sich durch den objektorientierten Ansatz gut arbeiten, leider hat das Ding andere Macken. Bei *nix hast du halt den Vorteil/das Problem dass du ein Scribt für #!/bin/sh schreiben kannst, was dann auf so gut wie allem Funktioniert. Selbst ein Bash-Script funktioniert noch auf allen Systemen der letzten 20 Jahre auf denen sich ne Bash installieren lässt. Bei PowerShell siehts hier anders aus, ein Script für WinServer 2016 funktioniert wohl nicht mehr auf 2008.
 

SierraX

Well-Known Member
#8
Wer mal gesehen hat wie Word und andere Textverarbeitungen - Rohtext Dateien versauen wird wieder liebend gern auf einen Editor zurückgreifen.
Ich hatte gestern erst das Problem, das ich X nicht anständig starten konnte ... ohne Grundkenntnisse in grep, ausgaben umleitung und vi (ja gebe zu das ich hier aus Bequemlichkeit ein wenig verschwenderisch war... ed, ex oder vielleicht sogar sed hätten es auch getan) wäre ich wahrscheinlich aufgeschmissen gewesen. Als ich vor fast 17 Jahren mit der BSDlerei angefangen habe, brauchte ich auch noch so Sachen wie gedit um mal eine Config Datei umschreiben zu können.
Jetzt unterschreibe ich eher den Satz (den ich glaube in einem LaTex Buch gelesen zu haben) "Wer auf eine WYSIWYG Textverarbeitung angewiesen ist... hat nichts besseres als Word verdient"
Über all wo es eher um Inhalt als um Formatierung geht ist man IMHO mit einem Editor wesentlich besser bedient... Genauso mit den Viewern wie less oder more (kann meine DOS Vergangenheit halt doch nicht Verleugnen und benutze lieber more)
 

ralli

BSD Fanboy
#9
Ich käme niemals auch nur ansatzweise auf die Idee, die Daseinsberechtigung unserer UNIX Werkzeuge, und dazu gehören eben auch Vi(m) oder less auch nur im geringsten in Frage zu stellen oder anzuzweifeln. Schon deshalb, weil sie ein Teil der UNIX Philosophie sind. Tools, die sich als eierlegende Wollmilchsau präsentieren, waren zumindest ursprünglich nicht im Sinn der Erfinder.
 
#10
Und ich will ja die alten Tools auch nicht ersetzen. Es wäre wenn, dann nur eine alternative Möglichkeit.
Ich denke dass diese Probleme entstanden sind weil Terminal IO nicht wirklich weiter entwickelt worden sind, zum Teil aus nachvollziehbaren gründen. Aber Oberon hat schon vor vielen Jahren gezeigt das es auch anders ginge. Stattdessen ist man auf den GUI Zug aufgesprungen und jetzt hat man den Salat.
 

Andy_m4

Well-Known Member
#11
Interaktion zwischen GUI - Welt und Terminal will man halt auch nicht wirklich.
Wer ist "man" ?

Die meisten Unix Installationen sind ohne Gui, auf dem Server will/brauch ich keine GUI, in Jails/Containern schon gar nicht.
Keiner sagt was von GUI auf dem Server installieren (ich glaube, da wiederhole ich mich jetzt auch nicht zum ersten Mal). Aber auf Deine Server greifst Du ja nicht zu, in dem Du in den klimatisierten Keller gehst und Monitor und Tastatur an den ansprechenden Server anschließt, sondern von einer Workstation aus mit ssh. Und ich denke mal der Gedanke, dass auf dieser Workstation eine GUI ist, ist nicht allzu verwegen.

Und nu bin ich gerade vielleicht per ssh auf dem Server und nun fällt mir auf, dass da ja noch irgendwie ne Datei fehlt. Die hab ich zum Glück lokal hier. Müsste ich nur rüberkopieren. Nett wäre, wenn ich einfach nur in meinen Dateimanager gehe, die Datei auswähle und per Drag&Drop in die Konsole schiebe und sie dann genau in dem Verzeichnis landet, wo ich drin bin (pwd).
Klar geht es auch anders. Aber das ging halt flotter.

Ich müsste für so fancy Funktionen also immer schauen: Hab ich hier ne Gui am laufen, bin ich ein "xterm" oder ähnliches? Und dann müssten beide Fälle unterschiedlich behandelt werden.
Also Normalerweise hat man ja seine Arbeitsmaschine. Was Du beschreibst, ist ein generelles Problem. Wenn ich an einem anderen Rechner bin hab ich halt nicht meine gewohnte Umgebung. Nicht die Einstellungen, die ich gewohnt bin usw.
Das ist also nix, was speziell diese "fancy Funktionen" betrifft.

Außerdem trifft dann wieder die Sache zu, die ich schon mal nannte. Bloß weils mal Situationen gibt, wo es nicht funktioniert, heißt es ja nicht gleich, dass man darauf verzichtet. Geht ja auch keiner ständig zu Fuß zum einkaufen, weil es könnte ja der Fall eintreten das das Auto in der Werkstatt ist und dann müsste man ja zu Fuß gehen, also geht man lieber immer zu Fuß. Ist doch Quatsch.

Bei *nix hast du halt den Vorteil/das Problem dass du ein Scribt für #!/bin/sh schreiben kannst, was dann auf so gut wie allem Funktioniert. Selbst ein Bash-Script funktioniert noch auf allen Systemen der letzten 20 Jahre auf denen sich ne Bash installieren lässt.
Hör bloß auf mit Bash-Skripten. Kompliziert, fehleranfällig. Und ja, sie laufen überall. Wobei nicht mal das stimmt. Weil Bash-Skripte ja auch intensiven Gebrauch von externen Programmen macht. Ist eines davon nicht da oder da wurde irgendwas geändert, hast Du ein Problem. Das etwas nicht da ist, ist auch kein esotherisches Annahme. Man denke nur an die modernen Linux-Distributionen wo dann standardmäßig ifconfig nicht mehr installiert wird. Klar kann man das nachinstallieren. Muss man aber auch selber mit dran denken, da Bash-Programme kein Dependency-Management kennen.

Ich bin schon länger davon ab Shell-Skripte zu schreiben, wenns nicht absolut unumgänglich ist.

Bei PowerShell siehts hier anders aus, ein Script für WinServer 2016 funktioniert wohl nicht mehr auf 2008.
Mir gehts auch weniger um die PowerShell als solche, als um die angesprochene Funktionalität. Mir vielen in der ganzen Shell-Landschaft so ein wenig die frischen Ideen, was ich verwunderlich finde.

Ich käme niemals auch nur ansatzweise auf die Idee, die Daseinsberechtigung unserer UNIX Werkzeuge, und dazu gehören eben auch Vi(m) oder less auch nur im geringsten in Frage zu stellen oder anzuzweifeln. Schon deshalb, weil sie ein Teil der UNIX Philosophie sind. Tools, die sich als eierlegende Wollmilchsau präsentieren, waren zumindest ursprünglich nicht im Sinn der Erfinder.
Es geht ja auch nicht darum Wollmilchsäue aufzubauen. Die Idee kleiner Tools die sich verknüpfen lassen, soll ja auch gar nicht aufgeben, sondern eher noch ausgebaut werden.
 

-Nuke-

Well-Known Member
#12
Ich würde übrigens VI und VIM nicht in einen Topf werfen. Das sind schon zwei sehr unterschiedliche Programme in ihrer Arbeitsweise. VI ist ein kleiner Texteditor, während VIM eher in Richtung IDE geht. Das ist so als wenn man unter Windows Notepad mit Word in einen Topf werfen würde.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#13
Mir vielen in der ganzen Shell-Landschaft so ein wenig die frischen Ideen, was ich verwunderlich finde.
Weil Menschen Gewohnheitstiere sind. Die meisten Menschen sind mit Bourne-Shells aufgewachsen, haben ihre Funktion verinnerlicht, sitzen auf diversen Scripten und so weiter. Damit sie bereit sind eine andere Shell zu lernen, muss diese andere Shell so große Vorteile bieten, dass es den Aufwand umzulernen und vielleicht auch all die Millionen zwar oft widerlichen aber eben vorhandenen Shell-Sripte umzuschreiben, in all seinen Dimensionen wert ist. Und das war es bisher trotz durchaus guter Ansätze wie zum Beispiel fish, xonsh oder eben der Powershell bisher anscheinend nicht der Fall. Bis zu dem Ausmaß, dass Microsoft erst die Powershell einigermaßen "unix-like" gestaltet und dann schließlich sehr viel Aufwand investiert hat, um u.a. die GNU Bash auf Windows zu bringen. Oder anders gesagt: Es mag bessere Konzepte als die Bourne-Shell geben, aber die Bourne-Shell ist letztendlich gut genug.

fish: https://fishshell.com/
xonsh: https://xon.sh/
 

medV2

Well-Known Member
#14
Ehrlich?


Keiner sagt was von GUI auf dem Server installieren (ich glaube, da wiederhole ich mich jetzt auch nicht zum ersten Mal). Aber auf Deine Server greifst Du ja nicht zu, in dem Du in den klimatisierten Keller gehst und Monitor und Tastatur an den ansprechenden Server anschließt, sondern von einer Workstation aus mit ssh. Und ich denke mal der Gedanke, dass auf dieser Workstation eine GUI ist, ist nicht allzu verwegen.

Und nu bin ich gerade vielleicht per ssh auf dem Server und nun fällt mir auf, dass da ja noch irgendwie ne Datei fehlt. Die hab ich zum Glück lokal hier. Müsste ich nur rüberkopieren. Nett wäre, wenn ich einfach nur in meinen Dateimanager gehe, die Datei auswähle und per Drag&Drop in die Konsole schiebe und sie dann genau in dem Verzeichnis landet, wo ich drin bin (pwd).
Klar geht es auch anders. Aber das ging halt flotter.


Also Normalerweise hat man ja seine Arbeitsmaschine. Was Du beschreibst, ist ein generelles Problem. Wenn ich an einem anderen Rechner bin hab ich halt nicht meine gewohnte Umgebung. Nicht die Einstellungen, die ich gewohnt bin usw.
Das ist also nix, was speziell diese "fancy Funktionen" betrifft.

Außerdem trifft dann wieder die Sache zu, die ich schon mal nannte. Bloß weils mal Situationen gibt, wo es nicht funktioniert, heißt es ja nicht gleich, dass man darauf verzichtet. Geht ja auch keiner ständig zu Fuß zum einkaufen, weil es könnte ja der Fall eintreten das das Auto in der Werkstatt ist und dann müsste man ja zu Fuß gehen, also geht man lieber immer zu Fuß. Ist doch Quatsch.
Das von dir beschriebene Beispiel ist eine Sache, die deine Gui vornehmen könnte - ein scp der Datei im Hintergrund. Hat mit der Serverseite aber nichts zu tun, und um die ging es ja ursprünglich. Auf Desktopseite kann man reinpacken was man will.

Es geht darum das man auf der Serverseite nicht unbedingt Sachen reinpacken sollte, die sich negativ auswirken, wenn man mal nicht auf der tollen Workstation ist. Z.b. Der kalte Keller oder die fricklige Notkonsole diverser Serverhersteller, oder oder..

Um bei deinem Autobeispiel zu bleiben: Nur weil die meisten mit dem Auto ins Einkaufszentrum fahren mauert das EZ auch nicht den normalen Eingang vom Bürgersteig zu, weil eh alle übers Parkhaus kommen.


Hör bloß auf mit Bash-Skripten. Kompliziert, fehleranfällig. Und ja, sie laufen überall. Wobei nicht mal das stimmt. Weil Bash-Skripte ja auch intensiven Gebrauch von externen Programmen macht. Ist eines davon nicht da oder da wurde irgendwas geändert, hast Du ein Problem. Das etwas nicht da ist, ist auch kein esotherisches Annahme. Man denke nur an die modernen Linux-Distributionen wo dann standardmäßig ifconfig nicht mehr installiert wird. Klar kann man das nachinstallieren. Muss man aber auch selber mit dran denken, da Bash-Programme kein Dependency-Management kennen.

Ich bin schon länger davon ab Shell-Skripte zu schreiben, wenns nicht absolut unumgänglich ist.
Ein Bashscript ist nicht komplizierter als ein PowerShellscript oder ein PerlScript. Ist einfach eine frage dessen, was du gewohnt bist. Man kann in Bashscripten, die Programme abseits von den coreutils brauchen auch einen kurzen Header vorstellen, der die Abhängigkeiten aufführt. Aber es ist doch eher eine Stärke, dass man nicht alles was benötigt wird selbst mitbringen und reinkompilieren muss.
Wenn du zu viele externe Programme brauchst ist vielleicht ein BashScript auch schlicht die falsche Wahl.

Zu deinem ifconfig in "modernen" Linux Distros: ifconfig war knappe 10 Jahre in allen großen Enterprise Distros als deprecated markiert. Trauert dem Programm nicht noch länger nach, ip hat einige Vorteile.

Aber ja es wäre wünschenswert wenn Ausgaben in einer ähnlichen Form als Objekte behandelt werden könnten wie es bei powerShell üblich ist.
 

Vril

Well-Known Member
Themenstarter #15
Interaktion zwischen Terminal und GUI gibt es z.B. ansatzweise im MacOS.

Z.B. kann man (ich zitiere mal:)
-Starten Sie zunächst das Terminal
-Geben Sie ein cd gefolgt von einem Leerzeichen ein
-Als nächstes wechseln Sie in den Finder und ziehen den Ordner, in den Sie im Terminal wechseln wollen auf das Terminalfenster.
-Anschließend erscheint der ausgeschriebene Pfadname des Ordners im Terminalfenster.
-Klicken Sie zurück in das Terminal-Fenster und drücken auf die Taste [Return]. Damit wechseln Sie in den Ordner.

ich persönlich halte sowas für untauglichen Krampf - die sollten besser den Finder mal praxistauglich machen!
 

Andy_m4

Well-Known Member
#16
Weil Menschen Gewohnheitstiere sind.
Wenn das die ultimative Antwort wäre, gäbe es gar keine Weiterentwicklung.

Damit sie bereit sind eine andere Shell zu lernen, muss diese andere Shell so große Vorteile bieten, dass es den Aufwand umzulernen
Man muss es auch nicht gleich zu übertrieben sehen. Es geht ja gar nicht darum etablierte Shells vollständig zu verdrängen oder so was.
Es geht nur um mehr Diversität (bzw. die Verwunderung darüber, dass sie fehlt). Denn in anderen Bereichen hat man die ja auch. Man denke nur an Desktopumgebungen. Da gibts GNOME, KDE, XFCE usw. Als Shell wird dann aber in den allermeisten Fällen die Bash eingesetzt? Das find' ich halt merkwürdig.

und vielleicht auch all die Millionen zwar oft widerlichen aber eben vorhandenen Shell-Sripte umzuschreiben, in all seinen Dimensionen wert ist.
Man muss unterscheiden. Die Shell in ihrer Eigenschaft als interaktive Schnittstelle und als Skriptsprache.
Klar. Bewährte Shellskripte neu zu schreiben macht vielfach keinen Sinn. Muss man aber auch nicht. Schreibt ja auch keiner z.B. C Programme um, wenns vielleicht bessere Möglichkeiten als C gibt or whatever. Warum sollten da Bash-Skripte eine Ausnahme sein.

wie zum Beispiel fish, xonsh oder eben der Powershell bisher anscheinend nicht der Fall.
Ja. Die fish ist eigentlich ein ganz gutes Beispiel wie eingängig eine Shell sein kann ohne erst viel herum konfigurieren zu müssen.

Microsoft erst die Powershell einigermaßen "unix-like" gestaltet
Ich halte das auch für eine der großen Probleme der PowerShell. Das die eben zu unix-like oder besser gesagt: zu traditionell gehalten ist.
Das ist natürlich auch dem geschuldet die Leute damit zu "kriegen", weils ihnen halt bekannt vor kommt. Aber ist auch ne verpasste Chance.

Ja. Oder meinst Du ich frag zum Spaß?

Das von dir beschriebene Beispiel ist eine Sache, die deine Gui vornehmen könnte - ein scp der Datei im Hintergrund. Hat mit der Serverseite aber nichts zu tun, und um die ging es ja ursprünglich.
Naja. Was heißt, darum gings ursprünglich. Das war Deine Interpretation. Und ich sagte ja auch nicht zum ersten Mal, dass es darum eben gerade nicht ging.

Es geht darum das man auf der Serverseite nicht unbedingt Sachen reinpacken sollte, die sich negativ auswirken, wenn man mal nicht auf der tollen Workstation ist.
Dagegen hab ich ja auch nix gesagt. Im Gegenteil!

Ein Bashscript ist nicht komplizierter als ein PowerShellscript oder ein PerlScript. Ist einfach eine frage dessen, was du gewohnt bist.
Auf die PowerShell geh ich nicht ein, weil ich bereits mehrfach gesagt hatte, was der interessante Aspekt der Powershell war und der Rest davon eigentlich irrelevant ist.
Ansonsten hat ich ja schon ein paar Sachen genannt. Dependency-Problematik. Parsing-Problematik.
Die Abhängigkeit von externen Programmen macht es zusätzlich kompliziert, weil jedes wieder irgendwie seine Eigenheiten in den Kommandozeilen-Parameter mitbringt (schöner sind Bibliotheken mit klaren einheitlichen Schnittstellen).
Aber es gibt auch schon auf einfacherer Eben viele Probleme. Ein Zugriff auf eine Variable der keinen Wert zugewiesen wurde, erzeugt keinen Fehler. Ein einfacher Tippfehler kann daher schon zu Bugs führen, die nicht so einfach nachzuvollziehen sind.
Die elendige Problematik um Leerzeichenbehaftete Dateinamen.
Dann noch so Sachen die in anderen Sprachen anders (einfacher) sind. Ich denk da nur an Geschichten wie
if [ $x -gt $y ]
vs.
if x < y

Man kann in Bashscripten, die Programme abseits von den coreutils brauchen auch einen kurzen Header vorstellen, der die Abhängigkeiten aufführt.
Und durch welche Magie werden dann die Abhängigkeiten installiert?

Aber es ist doch eher eine Stärke, dass man nicht alles was benötigt wird selbst mitbringen und reinkompilieren muss.
Dagegen sagt ja auch keiner was. Nur wenn es Abhängigkeiten gibt, dann sollten die auch irgendwie gehandelt werden können. Möglichst auch automatisierbar. Denn überall wo ich automatisieren kann, erpare ich mir das potentiell fehlerträchtige von Hand machen.

Zu deinem ifconfig in "modernen" Linux Distros: ifconfig war knappe 10 Jahre in allen großen Enterprise Distros als deprecated markiert. Trauert dem Programm nicht noch länger nach, ip hat einige Vorteile.
Ähm. Es war doch Dein Argument, dass 20 Jahre alte Bash-Skripte problemlos überall laufen.

ich persönlich halte sowas für untauglichen Krampf
Ja. Eine eigentlich praktische Funktion schlecht umgesetzt. Da kann man nix machen. :-)
 
#17
Wenn man bedenkt, dass der Trend wieder in Richtung Retro geht und Retro momentan wieder modern ist, dass könnte ich mir vorstellen, dass vi(m) und less auch wieder modern sind oder werden. :-) Die analoge Photographie beispielsweise scheint ja auch bei vielen jüngeren Menschen wieder "hip" zu sein.

So ein systemweites drag & drop fände ich persönlich auch ganz gut auf dem Desktop. Ich stelle mir das allerdings unter *BSD und Linux schwer umzusetzen vor. Das fängt bei der schon oben erwähnten Magie bei den Anhängigkeiten an, die dann alle möglichen shells, Paketsysteme und Versionen berücksichtigen müssten, damit das auch distributionsübergreifend kompatibel ist. Dann funktioniert drag & drop auch teilweise zwischen den verschiedenen Grafikbibliotheken (Qt4/5, Gtk2/3, WxWidgets, Tk, usw.) nicht.

Dieser Dschungel an API's, Distributionen, DE's, Grafikbibliotheken, usw. mag ja flexibel und individuell sein, allerdings geht dadurch aber die Einfachheit und Übersichtlichkeit verloren. Es gibt keine einheitliche GUI, keine Designrichtlinien, keine einheitlichen shortcuts, usw.

Junge Menschen streben nach Individualität und Anderssein. Diese können sich unter *BSD und Linux austoben. Ältere Menschen mit langer Computererfahrung im *nix-Bereich sind dieses gewohnt und werden nichts anderes wollen. Alte Bäume verpflanzt man nicht mehr. Ältere Neueinsteiger landen allerdings wohl eher bei Windows oder Apple und auch die Smartphone-Generation nutzt kaum noch PCs, außer zum zocken. Um langfristig "auf dem Desktop" erfolgreich zu werden, benötigt es viel Arbeit und vor allem Standards, um allen Altersgruppen und Erfahrungsstufen gerecht zu werden.
 

mr44er

Well-Known Member
#19
Die analoge Photographie beispielsweise scheint ja auch bei vielen jüngeren Menschen wieder "hip" zu sein.
Die Große meiner Freundin fährt da gerade voll drauf ab. Auch die Mode. Vinyl haben wir am Wochenende gekauft, zum Geburtstag jetzt gibts einen Plattenspieler.
Der Versuch mit Linux war gut. Als bei ihr jedoch das iphone einzog, musste Windows aufs Laptop. Somit ist an vi nicht zu denken. :)

Häääh, ist das so? Ich beobachte da eher eine gewisse Uniformierung und Surfen auf dem Zeitgeist oder den Standarts der jeweiligen Subkultur. Wirkliche Individualität muss man sich leisten können, und das ist in jungen Jahren eher nicht der Fall...
Ja...die Individualität wird angestrebt. Ohne dass diejenigen es merken, bleibt es aber beim Anstreben. Das kommt erst mit dem Alter, denn eine schwarze Handyhülle erzeugt noch keinen Individualisten. ;)
 
#20
Häääh, ist das so? Ich beobachte da eher eine gewisse Uniformierung und Surfen auf dem Zeitgeist oder den Standarts der jeweiligen Subkultur. Wirkliche Individualität muss man sich leisten können, und das ist in jungen Jahren eher nicht der Fall...
Ok, das war jetzt auch eher auf die mir bekannten jungen Linux-Nutzer bezogen. Das sind dann oftmals auch die größten Windows-Hater, einfach weil sie sich von der Masse abheben und anders sein wollen. Das sind jedenfalls meine Erfahrungen.
 

Azazyel

Well-Known Member
#21
VI ist ein kleiner Texteditor, während VIM eher in Richtung IDE geht.
Ich hätte eher ein Projekt wie Atom als Texteditor mit IDE-Ambitionen gesehen, auch wenn man Vim als IDE light verwenden kann. Der Abstand zu Visual Studio Code oder gar ausgewachsenen IDEs ist schon enorm.

Die meisten Menschen sind mit Bourne-Shells aufgewachsen, haben ihre Funktion verinnerlicht, sitzen auf diversen Scripten und so weiter.
Die Verwendung nur einer Programmiersprache für einen Anwendungsfall hat zweifelsohne seine Vorteile.

Unabhängig davon sitzen viele Zeitgenossen der "sunk cost fallacy" auf und sind deswegen emotional so an ihre Tools gebunden, dass jede mögliche Alternative - egal wie sehr sie bei Lichte betrachtet besser sein mag - kategorisch abgelehnt wird.

Es mag bessere Konzepte als die Bourne-Shell geben, aber die Bourne-Shell ist letztendlich gut genug.
Wahre Worte.

Häääh, ist das so? Ich beobachte da eher eine gewisse Uniformierung und Surfen auf dem Zeitgeist oder den Standarts der jeweiligen Subkultur.
Ich möchte genauso individuell sein wie die anderen! ;)

Das sind dann oftmals auch die größten Windows-Hater, einfach weil sie sich von der Masse abheben und anders sein wollen. Das sind jedenfalls meine Erfahrungen.
Als Nutzer von Linux auf Desktop und Server (beides beruflich wie privat) kann ich das leider nur bestätigen.
 

turrican

Well-Known Member
#22
Hatte seit vor knapp 20 Jahren mit HP-UX, SGI IRIX, IBM AIX und Solaris (gut, jetzt schon länger nimmer, diese OS spielen heutzutage eh keine so große Rolle mehr, nur noch in Nischen, bzw Irix eigentlich gar nicht mehr) zu tun und der kleinste gemeinsame Nenner war immer - vi

Irgendwie mag ich mich ned in was anderes einarbeiten, wobei ich auch trotz der langen Zeit nur einen sehr eingeschränkten Teil der ganzen Befehle parat habe - ich kann damit das machen, was so anfiel, mehr brauchte ich halt ned zu verinnerlichen :D

Ich nehm vi, mir egal was grad hip ist oder was andere sagen.

Es soll jeder nach seiner Fassong glücklich werden, gell.
 

Vril

Well-Known Member
Themenstarter #23
Hatte seit vor knapp 20 Jahren mit HP-UX, SGI IRIX, IBM AIX und Solaris (gut, jetzt schon länger nimmer, diese OS spielen heutzutage eh keine so große Rolle mehr ...
Man sollte diese ganzen Unix OS und deren Ableger nicht unterschätzen.
Z.b. dürfte das weltweit mit am häufigsten eingesetzte Betriebssystem Minix sein.

Warum?
Nun es ist das Betriebssystem der Intel Management Engine ;-)
 
#24
Unabhängig davon sitzen viele Zeitgenossen der "sunk cost fallacy" auf und sind deswegen emotional so an ihre Tools gebunden, dass jede mögliche Alternative - egal wie sehr sie bei Lichte betrachtet besser sein mag - kategorisch abgelehnt wird.
Das liegt zu einem guten Teil aber auch an den Tools die sich nicht auf etablierte Konventionen einstellen und die dann evtl auch noch schlecht dokumentiert und begründet sind. Jede Veränderung erfordert Zeit und Energie, insofern ist ein gewisser Konservatismus oft angemessen. Auf ausgetretenen Wegen stolpert man nicht so leicht...