Hallo zusammen,

ich besitze seit ca. einem Jahr wieder MAC-Hardware und genieße die Vorzüge, die alle Geräte miteinander haben. Im Internet habe ich mich bereits über viele meiner Fragen informiert und bin auch meistens fündig geworden.
Was ich nicht finden kann, sind Befehle, die ich im Terminal verwenden kann.
Es ist zwar schön, wenn Anleitungen veröffentlicht werden, in denen die Syntax steht.
Manchmal möchte ich dann doch noch mehr wissen. Gut, es gibt die Hilfe im Terminal, für mich aber zu umständlich zu lesen, da mir manche Erklärungen fehlen.
Kann mir da jemand bitte weiterhelfen? Am liebsten eine Anleitung in deutsch.

Vielen Dank im Voraus.

Folgende Google-Suche liefert viele passende Ergebnisse: "unix shell befehle".

Hallo,

erstmal vorneweg: das thema ist ziemlich komplex und alleine die Einführung der Begriffe und der Architektur sprengt den Rahmen hier.

Aber:

was du suchst ist oft unter "bash" Knowhow zu finden. googel nach "bash einführung" oder "bash tutorial deutsch".

Damit würde ich anfangen.

Genaugenommen ist es auch nicht bash, sondern zsh, aber das macht alles komplizierter und für den anfang, ist das was du unter "bash" findest für dich besser.

ohne konkrete Aufgaben die du im Terminal lösen möchtest, solltest du da als Newbie besser die Finger von lassen. Für die meisten Mac-User (MAC hieß es bei Apple noch nie!) ist das Terminal eigentlich eher nur der letzte (Aus)Weg, um ein Problem zu lösen. Und wer wie du sich so wenig damit auskennt, der sollte da besser die Finger von lassen. Kauf dir lieber ein Buch zum Thema…
Der Mac lebt von seine GUI und nich, weil man auch „was im Terminal“ machen kann

Hier ein kleiner Einstieg in MacOS-Terminal von der Zeitschrift Heise:

Ich möchte mich für die schnellen Antworten bedanken.
Da habe ich jetzt einiges zu lesen.

Also ich arbeite viel vom Terminal aus. Software-Entwicklung, teils Cross-Platform... da nutzt man eben GNUMake, CMake (mit Ninja) oder auch mal Python und BBEdit als Editor. Das ist dann unter Windows - ich kann manchmal nicht vermeiden, den Code auch da zu kompilieren - nicht anders, abgesehen davon dass cmd.exe deutlich "dümmer" ist und PowerShell äußerst unleserlich. Auf Linux findet man sich dann auch schnell zurecht.

Für Ottonormal-Nutzer hast du sicher recht.
Ich finde aber, dass gerade der Unix-Unterbau ein großer Vorteil von macOS ist. Die UX vom Mac lebt vom Unix-Fundament, auch wenn dieses den meisten Nutzern verborgen bleibt (was auch gut so ist).

Das ist ja auch eine ganze Welt für sich. Dein Satz ist ein bisschen so wie der Satz Was ich nicht finden kann, sind Wörter, die ich im Englischen benutzen kann.

Du kannst im Terminal alle Unix-Befehle verwenden. Das zu lernen ist in der Tat ein bisschen wie eine Sprache lernen: Syntax und Wörter (= Befehle). Das macht man nicht an einem Tag.
Die ist auch nicht zum Erlernen von Unix gedacht, sondern dreht sich um das Terminal-Programm in macOS.
Deutsch wird vermutlich schwierig, da ja die ganzen Befehle ohnehin englisch sind. Früher® gab’s für die Basics Bücher mit Titeln wie Shell Programming. Damit konnte man in ein paar Tagen leicht die Syntax und die allerwichtigsten Befehle lernen; das ist ja nicht allzu kompliziert. Vielleicht gibt’s heute sowas noch (an den Shell-Basics hat sich in den letzten 40 Jahren ja nichts geändert), ansonsten sollte es Online-Pendants geben. Ich fand für die Basics ein Buch zum immer wieder rasch Nachschlagen seinerzeit praktisch.

Wenn Du dir einmal das Grundgerüst draufgeschafft hast, geht es wie bei natürlichen Sprachen auch nur noch um den „Wortschatz“ und den lernt man am besten peu à peu anhand spezifischer Aufgabenstellungen, die man hat.

Neben den Standard-Unix-Befehlen gibt es auf dem Mac auch viele Mac-spezifische Befehle. Wenn man da nach etwas sucht, ist oft der Befehl
nützlich, der alle Befehle auflistet, die mit suchbegriff zu tun haben. Und dann kann man mit
Näheres erfahren.

Schließlich ein Wort zu bash und zsh. bash ist die Standard-Shell, die völlig kompatibel zu sh ist, der Ur-Shell, in der praktisch alle Skripte geschrieben werden. Apple mag aber bash wegen dessen Lizenz nicht und versucht, die Nutzer zur zsh zu bugsieren, die jedoch wegen einiger Inkompatibilitäten in der Syntax für Probleme sorgen kann, die gerade Einsteiger verwirren. Man kann im Terminal aber nach wie vor auch bash als Shell einstellen, was ich Dir raten würde, denn die allermeisten Infos und Anleitungen im Netz sind für bash bzw. sh.

Aber dann bleibt er doch auf ewig Newbie?
Ja, und das ist schade, weil das nochmal viele zusätzliche Möglichkeiten eröffnet. Umso erfreulicher, wenn Computator die Motivation hat, an dieser Stelle dazuzulernen. Warum willst Du ihm die nehmen???

Computator
Um eine Idee davon zu bekommen, wofür Du dich da interessieren möchtest, ist vielleicht der folgende Artikel ganz gut:

Unix-Philosophie

Ich habe solches Wissen bei meinem Einstieg in Unix als sehr hilfreich empfunden. Das Betriebssystem stammt halt aus der Zeit VOR graphischen Benutzeroberflächen. Terminal und Texteditor sind hier die Hauptwerkzeuge.

Und wenn Dir das nicht gefällt, dann bleibst Du halt bei macOS - ohne Probleme.

Eine Sache noch, die ich vergaß zu erwähnen, weil sie mir selbst so völlig selbstverständlich ist:

Zu der von mschue erwähnten Unix-Philosophie gehört insbesondere auch, dass (bis auf ein paar ganz elementare Ausnahmen, die in der Shell selbst implementiert sind) jedem Befehl ein Unix-Programm mit exakt demselben Namen entspricht; in Unix sind Programm und Befehl also zwei Worte für dieselbe Sache. (Merkwürdigerweise erwähnt das der verlinkte Wikipedia-Artikel nicht, sofern ich nichts übersehen habe. Dabei ist das das entscheidende Merkmal, mit dem ich Unix charakterisieren würde, wenn ich nur ein einziges Merkmal nennen dürfte – die Modularität ist darin ja implizit enthalten.)

Unix-Programme sind installiert in /bin (die wichtigsten Programme, die zu jedem Unix gehören), /usr/bin (nicht ganz so elementare Programme, die auch nicht auf jedem Unix-System alle vorhanden sein werden) und /usr/local/bin (für selbst installierte Programme).

Du kannst Dir also mit dem Befehl
bis auf wenige spezielle Ausnahmen alle Unix-Programme = mögliche Unix-Befehle auflisten lassen (ls steht für list).

Die Namen sind freilich sehr oft kryptisch, insbesondere weil stark abgekürzt zwecks einfacher Befehls-Eingabe (wie eben ls für list), sodass Du damit noch überhaupt nicht weißt, was Du damit anstellen kannst. Aber Du hast eine vollständige Liste, welche Befehle überhaupt möglich sind.

Was die einzelnen Programme = Befehle tun, erfährst Du dann mit

Ein kleines Beispiel - gerade passiert.

Wir haben eine - auf einem speziellen Rechner erstellte - Tabelle im CSV-Format, mit ca. 450.000 Zeilen und einer Gesamtlänge von knapp 2 GB. Jede Zeile hat in der ersten Spalte eine aufsteigende und eindeutige Zahl und in der letzten einen Hash über alle vorherigen Spalten der Zeile.

Aufgabe 1: schicke mir mal die ersten beiden Zeilen:
Aber wenn man Geduld hat, kann man auch versuchen eine 2 GB große Textdatei in einem Editor zu öffnen. Im Terminal ist es fertig, sobald man gedrückt hat.

Aufgabe 2: schicke mir mal die Tabelle, aber nur die erste und die letzte Spalte (die 22.):
Hier bräuchte man noch deutlich mehr Geduld, wenn man die Daten in Numbers, Excel oder Calc importieren möchte. Die überschüssigen Spalten zu löschen geht schnell, aber dann muss man die 2 Spalten wieder exportieren bzw. Speichern. Im Terminal hat das ca. 45 Sekunden gedauert.

Das sind natürlich schon relativ spezielle Aufgaben, denen sich auch nicht jeder stellen muss. Aber es zeigt, wie mächtig eine Shell mit den Tools ist. Daher ist es zu begrüßen, wenn sich jemand dafür interessiert - und da helfe ich auch gerne. Ich bin da noch weit weg von all-wissend - aber wenn man mal ein Gefühl dafür hat, dann findet man sehr elegante Lösungen und lernt weiter. Für die "awk" Zeile lies ich mich bei StackExchange inspirieren und ich habe noch einen großen Lernbedarf bei RegEx und wie man sie effizient bei "grep", "find" und "sed" nutzen kann. Man lernt nie aus - und es gibt Menschen, die genau daran auch ihren Spaß haben.

Top Beispiel! Mir geht es genau so. Ich mache regelmäßig wissenschaftliche Visualisierungen und bekomme Daten in ähnlichem Umfang wie du sie beschreibst. Ohne die genannten UNIX Tools wäre ich oft aufgeschmissen. In den Zeiten vor Mac OS X habe ich dafür noch regelmäßig eine Linux-Kiste, ganz früher eine Silicon Graphics Workstation "missbraucht". Heute geht alles auf einer Maschine, einer der Riesenvorteile von Macs und OS X für meine Arbeit.

Vielleicht ist dazu bwana noch ganz nett. Damit kannst Du bei Safari in das Adressfenster eingeben und du bekommst die man-page hübsch gerendert im Safari-Fenster - mit entsprechenden Scroll-Möglichkeiten für den schnellen Überblick, Tabs für mehrere man-pages gleichzeitig etc.

Kost' nix und ist m.E. ganz praktisch. Und es ist hübsch. Schließlich war das damals auch ein Grund, weswegen ich von Windows+FreeBSD auf macOS umgestiegen bin - neben dem Unix-"Untergrund".

Mir hat das Buch Linux Power vom Sybex Verlag sehr geholfen. Das gibt’s aber nur noch gebraucht.

Vieles im Buch ist auch für den Mac gültig, z. B. Einführung Bash, Rechte, Dateibefehle, Benutzerverwaltung, Editoren und vor allem: Ein-/Ausgabeumleitung und Piping (s. Beispiel von ssb). Und alles in deutsch.

Vielleicht kannst du ein Exemplar in ebay ergattern?

Da gibt's auch noch zwei neuere, aufeinander aufbauende Artikel

Ich glaube aber, dass sie deine Frage nicht vollständig klären. Ich selbst nutzte meist die Man-Pages über das Kontextmenü und suche im Zweifel bei Stackoverflow. Praktisch ist auch Fig , das zeigt dir zu Kommandos die verfügbaren Parameter oft mit einer Kurzbeschreibung an.

Wenn's auch Englisch sein darf, könnte das Take-Control-Book zur Shell interessant sein. Das wird sogar gelegentlich aktualisiert. Selbiges trifft auf das iBook von Armin Briegel zu .

Ansonsten stöbere ich auch gelegentlich in den von Weia genannten Ordnern. Eine Übersicht samt Kurzbeschreibung bekommst du hiermit:

Bei der bash hilft es einfach den Anfangsbuchstaben eines Befehls einzutippen und dann zweimal <Tab> zu tippen. Dann werden alle Befehle im Suchpfad mit diesem Anfangsbuchstaben nach Nachfrage angezeigt.

Mit help erhält man bei neueren Shells Hilfe für die internen Funktionen der jeweiligen Shell.
Die Ur-Shell ist die Thompson-Shell, die Bourne-Shell hat sie dann Ende der 1970er abgelöst. bash ist die Standard Shell des GNU Projektes und somit auch in Linux. Die Standard Shell der noch vorhandenen kommerziellen UNICES ist ksh (Korn Shell), aber meist gibt es die bash zum Nachinstallieren bzw. sie wird gleich mitgeliefert. Mittlerweile ist die ksh OpenSource. Die diversen BSD Varianten nutzen auch keine bash, da die die falsche Lizenz hat. IMHO gibt es da Weiterentwicklungen der pdksh (Public Domain ksh). Ältere Versionen von MacOS X nutzen die tcsh.

Cool! Auf die Idee, Liste und Kurzbeschreibungen zu kombinieren, bin ich irgendwie nie gekommen.

Allerdings gibt es einen kleinen Haken aufgrund des Programms/Befehls mit dem seltsamen Namen [, der für die Shell eine besondere Bedeutung hat und sie daher bei dieser Auflistung verwirrt:
Diese Fehlermeldung kann man zwar getrost ignorieren, die Beschreibung für den Befehl [ fehlt dann aber halt und schön ist es nicht. Außerdem werden von ls auch auch die drei Verzeichnisse selbst (/bin, /usr/bin und /usr/sbin) in der Liste in je einer Zeile aufgeführt, bei denen whatis dann meckert, dass es keine Manpage = Hilfeseite dafür gibt (nothing appropriate). Das sollte natürlich nur als Meldung für tatsächliche Befehle kommen, für die keine Manpage existiert.

All diese Kleinigkeiten glätten und noch /usr/local/bin hinzufügen, das Du ausgelassen hattest, und man bekommt folgenden Befehl:
Man sieht, wenn man ins Detail geht, können Unixbefehle schnell fizzelig werden, insbesondere Sonderzeichen, die nicht als Befehle interpretiert werden dürfen, und reguläre Ausdrücke zum Filtern.

Diese Monsterzeile kann sich niemand mehr merken, weshalb es sich anbietet, sie zu einem kleinen Unix-Programm zu machen:
Diese reine Textdatei in /usr/local/bin als lc (list commands) sichern, mit chmod 755 /usr/local/bin/lc ausführbar machen und schon hat man sein erstes eigenes Unix-Programm geschrieben und kann zukünftig durch Eingabe von lc in die Shell jederzeit die Liste aller Befehle bekommen.

In einem Shellskript, das in einer Textdatei gespeichert wird, muss man natürlich nicht alles in eine Zeile quetschen und kann das auch schöner schreiben:

Das stimmt; ich wollte nicht gleich mit zu vielen Möglichkeiten verwirren. (Aber lc und nicht ls am Anfang!)

~/.zshrc gilt allerdings nur für die Z-Shell, bei der ich wiederum nicht überprüft habe, ob der Befehl so funktioniert. Diese ewigen potentiellen Inkompatibilitäten zwischen Shellskripten mit #!/bin/sh und Shell-Eingaben in eine Z-Shell ist einer der Gründe, warum ich so wütend über Apples Umstellung auf die Z-Shell (zsh) bin und jedem empfehlen würde, stattdessen weiterhin bash zu verwenden.

Und Du musst mit den Anführungszeichen aufpassen, weil Du den Gesamtbefehl in Anführungszeichen setzt, die aber auch innerhalb des Befehls vorkommen; das wird so, wie Du es geschrieben hast, nicht funktionieren. Da musst Du dann innerhalb des Befehls mit \" escapen, was alles noch unübersichtlicher macht.

Ich würde daher gerade Einsteigern empfehlen, bei der eigenen Befehls-Datei lc zu bleiben. Das ist einfacher, sauberer und demonstriert die Unix-„Philosophie“ 1 Programmdatei pro Befehl wunderbar.

Das habe ich auch festgestellt und den Beitrag noch entfernt. Ich wollte schauen, was ich korrigieren muss. Das sieht Dein geübter Blick schneller.
Mit einem Skript ist man also auf der sicheren Seite.

Yep. 1 Datei pro Befehl ist das mächtige Unix-Modularitätsprinzip.

Weia: Danke für die Verbesserung des hingerotzten Kommandos.

Die Fehlermeldungen würde ich einfach ins Nirvana laufen lassen. Zudem ließen sich die Pfade gleich aus der PATH-Variable holen, dann sind MacPorts oder Homebrew gleich mit berücksichtigt.

Hier meine neue Variante, die auch gleich die builtins rausfiltert:

${(s[:])PATH} macht aus der PATH-Variable anhand des Doppelpunkts ein Array.

Fehlermeldungen zu unterdrücken ist ein bisschen Geschmacksache; kann man natürlich tun, wenn man sich ganz sicher ist, dass keinerlei relevante Fehler auftreten. Ich behebe lieber die Fehler.
Dass spezielle zusätzlich Pfade mit berücksichtigt werden, kann man wollen oder aber gerade nicht. Bei mir würden z.B. dann lauter X11-Befehle auftauchen, die manche Apps brauchen, die ich aber nie selbst würde verwenden wollen.
… die aber nur in zsh funktioniert!
Das ist eine gute Idee, da die gleich mehrfach auftauchen, uniq zum Trotz (keine Ahnung, warum). Einmal würde ich sie dann aber manuell hinzufügen, denn die Info als solche gehört zum Auflisten aller möglichen Befehle ja dazu – ebenso wie [.

Im Rahmen unseres Wettbewerbs Unser Shellskript soll schöner werden hier also meine um Deine Anregungen aktualisierte Variante:
Ich habe noch ein paar „Verschönerungen“ eingebaut, hauptsächlich eine Sortierung der Befehle und ein Entfernen der nothing appropriate-Bleiwüsten bei Befehlen ohne Manpage.

umask habe ich als Schlüsselwort für builtin genommen, da Letzteres auch noch an anderer Stelle vorkommt.

Da hoffen ich mal, dass die Schönheitsoperationen am Script mit dem Alias den TE nicht abschrecken
So gut und wichtig die Ergänzungen sind.

In vielen Fällen (wie bei meiner "awk" - Zeile) hilft auch einfach die Verwendung einer Suchmaschine beginnend mit "bash" und dann dem Problem, das man lösen will. Fundstellen bei StackExchange ist oft schon ein guter Startpunkt. Danach kommt man oft mit den Manpages und Trial & Error zum Ziel.

Ich würde - auch wenn dann Unmengen an zusätzlichen Tools erscheinen - dennoch $PATH verwenden, weil dann alle Tools aufgelistet werden, die in der Shell verfügbar sind, auch die zusätzlich/nachträglich installierten, über welche Quelle auch immer.

Für die Standard-Tools finde ich gerade als Anfänger die Cheat-Sheets praktisch als Orientierung. Zur Not mal eines Ausdrucken und neben die Tastatur legen, bis die wichtigsten Tools besser sitzen.

Ungeachtet dessen - nettes Skript und vielen Dank dafür.

Ja, das habe ich mir auch überlegt.

Andererseits, wir hatten die grundsätzlichen Dinge ja zuvor geklärt und vielleicht ist das sogar eine schöne Demonstration, wie sich aus einer simplen Aufgabenstellung und Lösungsidee über die Zeit ein immer komplexeres kleines Progrämmchen entwickelt.

Und da das Skript nichts Gefährliches tut, kann es Computator, falls er mag, es einfach in eine Textdatei kopieren und dann damit herumspielen, was in dem Skript wofür sorgt, indem er testweise etwas aus dem Skript löscht und guckt, was dann nicht mehr geht, sprich, wofür das Gelöschte gut war. (Vielleicht erstmal nur mit /bin, damit die Ausgabe nicht zu lang wird.)

Ich würde mich an deine Stelle jedenfalls nicht mit der «bash» befassen, sondern mit der «zsh» die seit macOS 12.15 «Catalina» der Standard bei Apple ist.
Es bringt nichts hier zu diskutieren, was die bessere Shell ist – zsh | bash | fish – dafür würden die Meinungen sich dann zu weit vom Thema hier entfernen. Fakt ist, die Z Shell ist einfacher konfigurierbar, moderner, hochgradig mit der «bash» kompatibel, und seit einigen Jahren eben die macOS Default Shell.
Ich empfehle Dir außerdem Tabby als Alternative zur  Terminal app. Viele verwenden auch iTerm2. Außerdem empfehle ich ZIM als Config Framework anstatt «oh-my-zsh»
Tutorials: YouTube
Bücher: «ZSH. Die magische Shell»

Ja - die einfachsten Probleme benötigen oft die komplexesten Lösungen (und manchmal wird die Lösung Teil des Problems)

Tutorials, Cheat Sheets und so weiter können das "Learning by Doing" nicht ersetzen, nur unterstützen. Am Ende läuft es immer in Richtung Trail & Error. Mit wachsender Erfahrung braucht man dann weniger Trial, weil man auch weniger Error erlebt. So lange man dabei nichts kaputt macht, wie im Falle dieses Skripts, ist das ungefährlich und fördert das Lernen aus Fehlern.
Vorsichtig sollte man dann werden, wenn wegen Fehlern beim Zusammenbau von Pfaden (mal Quotes vergessen, Sonderzeichen nicht escaped) plötzlich ein "rm -rf /" raus kommt.

Viele Tools, die das was anstellen können, bieten dafür dann die "--dry-run" Option an. Oft vorteilhaft, diese auch zu nutzen, gerade wenn die Tools was am Dateisystem ändern. (Da war ich mit rsync beispielsweise vorsichtig).

Der Standard bei Beispielen im Internet ist aber bash bzw. sh und das ist viel wichtiger.
Warum machst Du es dann?
Eben nicht. Bereits hier bei dem simplen Skriptbeispiel hört die Kompatibilität auf.
Das ist doch völlig wurscht. Man kann sie problemlos umstellen.

Richtest Du Dich immer nach Apples Defaulteinstellungen? Ich praktisch nirgendwo.

Und wenn Apples Motiv ein rein politisches ist, dann schon gleich gar nicht.
Wieso das denn? Terminal ist eine der besten macOS-Apps überhaupt, perfekt in macOS integriert. Tabby ist cross-platform 🤮.

Mit dieser Einstellung kommen wir nie über die Umstellung der Standart Shell hinweg.
Nicht ich diskutiere, sondern du.
Auch dafür gibt es eine ganz simple Lösung: «bash» vermeiden
Genau, aber man sollte lieber von Bash auf Zsh umstellen.
Nein, ich konfiguriere gerne. Es gibt für alles Gründe, warum man sich auf einen "Default" verständigt hat. Bei jeder App, bei jeder Software-Schmiede.
Bestimmt, trotzdem gehen viele erfahrene Anwender auf eine Alternative, aus diversen Gründen. Du bleibst lieber beim Default - wen sollte das stören. Ich kann empfehlen, was ich will.
Das ist für viele ein Grund es auszuwählen. Für dich offenbar ein Hindernis - du wirst deine Gründe haben. Trotzdem kann ich es empfehlen.

Fazit:
Ohnehin ist es hier egal, wer was wie warum hier schreibt, denn Weia weiß nun mal alles besser und seine Meinung ist auch wichtiger als meine und die aller anderen.

Warum sollten wir das auch?

Du scheinst zsh besser zu finden, was ja völlig OK ist. Es aber einem Einsteiger zu empfehlen, der immer wieder im Internet nach Code-Beispielen suchen und in aller Regel welche für bash, aber nicht für zsh finden wird, halte ich für wenig sinnvoll. Dass Apple die zsh aus Lizenzgründen durchboxen will, ist in diesem Kontext jedenfalls ganz sicher kein Argument.
Wie meinen?↔︎In einem Satz zu schreiben, etwas bringe nichts, um im unmittelbar darauffolgenden Satz genau das zu tun – das muss man auch erstmal fertig bringen.

Ich hatte bislang in diesem Thread nicht über das Thema Shell diskutiert.
Das geht aber eben nicht, wenn geschätzte 95% der Code-Beispiele im Internet sich auf bash beziehen. Das ist für einen Einsteiger wichtig. Eigentlich sollte das nicht so schwer zu verstehen sein.
Das müssen aber keine guten Gründe sein.
Bist Du jetzt in der Trotzphase oder Argumenten noch zugänglich? Falls Letzteres, wäre es schön, Du würdest wenigstens ab und an eins nennen.
Cross-Platform-Apps sind prinzipbedingt in ihren Fähigkeiten reduziert auf den größten gemeinsamen Nenner. Wenn ich ein Betriebssystem seiner Vorzüge wegen bewusst ausgewählt habe, ist es unsinnig, Apps zu bevorzugen, die viele seiner Vorteile gerade nicht ausnutzen können, es sei denn, es gäbe andere gewichtige Gründe für eine solche App.
Kannst Du, nur ohne jedes Argument dafür ist das vollkommen bedeutungslos.
Oje, die Leier wieder. Mir wäre lieber, ich wüsste nicht immer alles besser, denn dann könnte ich auch mal was lernen.
Es geht eben nicht um Meinungen; dieser Rückzug auf Meinungen ist ja eine regelrechte Pest geworden. Meinungen sind völlig uninteressant. Es geht um Aussagesätze, die wahr oder falsch sein können. Um festzustellen, was sie sind, braucht man Argumente. Jede Aussage von mir ist mit einem oder mehreren Argumenten unterfüttert. Die können natürlich falsch sein, aber wenn jemand nicht dagegen argumentiert, sondern lediglich eine widersprechende Meinung äußert – sorry, ja, das ist dann „weniger wichtig“.

Bezüglich Tabby schließe ich mich Weia an.

Tabby ist eine Electron App. Electron ist ein Framework, mit dem sich Anwendungen basierend auf Web-Technologien (HTML, JavaScript, CSS) zusammen basteln lassen. Das macht noch Sinn, wenn man eine App baut, mit der man auf server-basierte Dienste zugreift - Chat Clients wie Slack, RocketChat etc. - und dabei noch einen Mehrwert bieten kann - verglichen zur Verwendung in einem Browser.

Eine App zu verwenden, die lokal Webtechnologien benutzt, um via WebKit und Erweiterungen auf den Unterbau des Betriebssytems zugreifen zu können, das ist wie - lass mich nach einem Vergleich suchen... das Bild einer Webcam auf das iPhone zu streamen, die auf den Fernseher im gleichen Raum ausgerichtet ist. Oder wie auf einer Webseite nachzuschauen, ob es gerade draußen regnet - statt einfach aus dem Fenster zu sehen.

Inwieweit das zudem ein Sicherheitsrisiko sein kann (Electron-Exploits) sei dabei gar nicht betrachtet.

Früher habe ich definitiv iTerm2 dem Apple Terminal vorgezogen. Ist aber schon eine Weile her als dass ich mich an jedes Detail erinnere. Alleine schon der Visor Mode oder die als Profil abspeicherbaren Split Panes Konfigurationen waren gute Gründe für iTerm2. Zumindest in früheren MacOS Versionen (ich kenn die aktuellsten Terminal Versionen nicht mehr so richtig) war so etwas nicht möglich mit dem Apple Terminal. Auch Look & Feel bzw. Themes waren glaub eine Zeit lang gar nicht möglich im Terminal (wenn ich mich recht entsinne). Für schnelle Interaktion ist das Apple Terminal ausreichend, wenn das Terminal aber ein gewichtiger Bestandteil im Arbeitsalltag / bei Workflows darstellt, lernt man zusätzliche Features zu schätzen, die man aber in anderen Produkten als dem Apple Terminal (zumindest in früheren Versionen) findet.

Bei Electron-Apps bekomme ich ähnliche Bauchschmerzen.
Aber spätestens bei Lösungen, die lokal ein Node.js/npm benötigen. Der JavaScript Rotz vom Frontend, der "serverseitig" gewandert ist und dann für lokale Apps eingesetzt wird

p.s. VS Code ist übrigens auch Electron-basiert
Zählt aber immerhin dem Hörensagen nach zu den performantesten der Electron-App-Gattung.

Es ist kein Zufall, dass ich auch VSCode nicht nutze - liegt nicht nur daran, dass es von Microsoft kommt.

Als Editor nutze ich BBEdit, dem ich seit System 9 treu geblieben bin. Man kann das daran erkennen, dass ich von der WWDC 2015 das "It still doesn't suck" T-Shirt heim gebracht habe und seither pfleglich behandle.

Ich kenne das nicht, habe es mir jetzt aber mal angesehen, und das ist von den Features her natürlich ein ganz anderes Kaliber und zudem wohl ein richtiges Cocoa-Programm, sodass ich mal davon ausgehe, dass sowas wie Drag&Drop von Dateien vom Finder ins Terminal-Fenster problemlos funktioniert. Das ist dann sicher eine Alternative, wenn auch eher nicht für Einsteiger angesichts der vielen Möglichkeiten.

Vieles, was Du damals bei Terminal vermisst hast, kann es mittlerweile, aber mit der Feature-Menge von iTerm kann es sicher nicht mithalten. Das ist dann Geschmacksache; ich arbeite auch fast täglich mit dem Terminal, aber mir sind einfachere Apps meist lieber – viel ist nicht zwingend besser, mir wird es schnell zu überladen.

Eine Sache, die ich an Terminal liebe und noch nirgendwo anders gesehen habe, ist, dass ich im Terminal mit einem einfachen Kommandozeilen-Befehl jeden beliebigen Text als Fenstertitel eingeben kann, sodass ich auch bei endlos vielen offenen Fenstern im Fenster-Menü sofort das richtige finden kann (ich bin ein Fenster-Junkie und habe meist > 50 Fenster offen). Darauf würde ich nicht mehr verzichten wollen; sonst brauche ich nicht viel.

Ich nutze auch iTerm2. Im Grunde deshalb, weil es allenthalben hieß, dass das Programm gut sei.
Seit ein paar Tagen teste ich Warp . Es reagiert schnell und hat wirklich nette Funktionen. Ein Beispiel: Mit einem Kommando zeige ich mir regelmäßig eine Liste von gefilterten Zeilen aus Markdown-Dateien an. Im Warp-Fenster kann ich die Datei direkt anklinken und öffnen.

Doch, eines habe ich noch vergessen, weil mir das so selbstverständlich bei allen Apps ist, die ich nutze, dass ich gar nicht mehr daran denke, dass das nicht alle können: Die automatische Wiederherstellung aller beim Schließen geöffneten Fenster samt Inhalt (und im Falle von Terminal auch fensterspezifischer History).

Haben iTerm und Warp das implementiert? Das ist ein Feature, ohne das ich bei keiner App leben könnte.

yep.

Mehr solcher Threads hier. Fantastischer Einsatz der üblichen Verdächtigen. Danke.

Ich bin ja weitestgehend bei Dir, aber bei Compilern hört das z.B. ganz schnell auf. Ich habe in den letzten 10 Jahren u.a. damit mein Geld verdient HP-UX Server zu betreiben, weil meine Firma FORTRAN-Programme mit HPs Compiler geschrieben hat (und dessen Features genutzt hat) und ich durfte noch 2019 neue HP-UX Itanium(!)-Server kaufen, weil diese Programme unverzichtbar waren.

Also vorsicht: Stellenweise dünnes Eis...

Dieser Punkt gehört schon lange in die öffentliche Diskussion!
Danke Weia, Du hast ja soo Recht.

Gar nicht – ich habe ja extra geschrieben es sei denn, es gäbe andere gewichtige Gründe für eine solche App. Und das wäre bei dem von Dir Genannten ja klar der Fall. Ich habe notgedrungen selbst etliche cross-platform-Software auf meinem Mac; genau deshalb weiß ich ja, in wie vielerlei Hinsicht die gegenüber Cocoa-Apps abstinkt. Wann immer es also eine gleichwertige oder nur mit verschmerzbaren Einschränkungen versehene Cocoa-App gibt, ziehe ich die cross-platform-Apps vor.

Es gibt eine Microsoft freie Version von VSCode. Das sollte also nicht das Problem sein.
Ich nutzte damals Alpha, weil mir BBEdit nicht zusagte. Ich weiß nicht wie gut BBEdit mittlerweile ist, aber VSCode ist nicht mehr nur ein Editor sondern mit den vielen Erweiterungen de facto eine vollständige IDE. Man kann damit Projekte bauen, Debuggen, Versionsverwaltung machen, … Es gibt also kaum noch Dinge, die eine „vollständige“ IDE besser kann. Ein GUI-Editor (Editor zum Bauen von GUIs) ist nicht dabei, aber da VSCode nicht an ein bestimmtes FrameWork gekoppelt ist, wäre das auch sonderbar.

Unter Linux ist die Performance auch gut bis sehr gut. Ich nutzte vorher Eclipse als IDE für einige Dinge, und das ist im Vergleich relativ träge. Demgegenüber ist VSCode ein deutlicher Fortschritt.

Na ja, die Diskussion "Standards vs. Features" ist ja schon ziemlich alt, wenn nicht so alt wie die EDV selbst. Man sollte halt aufpassen, wem man aus welchen Gründen "auf den Leim" geht und welche Konsequenzen das u.U. haben könnte. Das war es, worauf ich hinweisen wollte.

Korrekt, es besteht die Gefahr des Vendor-Lock-Ins. Mich wundert nur wie ihr von HP Fortran abhängig gewesen sein konntet. Was war/ist daran so speziell, dass man das nicht auf eine andere Fortran Version portieren konnte?

Gibt es die Möglichkeit, eine andere Shell - z.B. fish - auszuprobieren ohne gleich alles umzustellen? Also nur im Terminal statt gleich als Login-Shell in Systemeinstellungen/Benutzer.../Erweiterte Optionen? Ich denke, wenn etwas mal völlig schief läuft, ist es besser der Standard für Rettungsaktionen ist dann doch zsh oder bash.

Einfach den Befehlsnamen im Terminal der betreffenden Shell eintippen, und schon übernimmt die andere Shell.

Beim zweiten Lesen habe ich es verstanden Den Befehlsnamen für die Shell, also "fish" oder "bash".
Danke.

Da zeigt sich wieder sehr hübsch das modulare Unix-Grundprinzip: Alles ist ein eigenes Programm und Befehlsname und Programm sind dasselbe. Das klingt so simpel, ist aber sehr mächtig. Wenn Du das einmal verinnerlicht hast, verstehst Du das schon beim nullten Lesen.

Das weiß ich nicht so genau, da ich nur der Admin war und die Programmierung in der Fachabteilung erfolgte. Es war aber wohl eben nicht Fortran77 und - ehrlich gesagt - waren die ursprünglichen Programmierer mittlerweile "weggestorben" bzw. nicht mehr in der Firma und niemand hat sich daran getraut, die Programme zu portieren und ggf. alte Fehler zu tilgen bzw. neue Fehler zu implementieren. Fortran gibt's halt schon lange...

Fand ich ganz spannend, solchen selbstentwickelte Software über so einen langen Zeitraum zu beobachten. Softwaremaintenance über Jahrzehnte ist schon eine Aufgabe...

Wenn das noch nicht einmal Fortran77 ist (die erste Norm war Fortran66 und davor gab es den Wildwuchs), dann muss der Code wirklich alt sein. Ich kenne nur Programme, die spezielle g77 Erweiterungen nutzen (der alte GNU Fortran Compiler), die von vielen Compiler unterstützt werden. Und die Programme mussten wirklich lange nicht mehr angefasst worden sein, wenn das nur mit einem HP Compiler übersetzt werden konnte.

Na ja, es war "im Prinzip" schon F77, aber eben - wie Du schreibst - mit genutzten HP-Fortran Erweiterungen. Die sind natürlich anders als die g77-Erweiterungen. Wir wollten ja genau auf FreeBSD migrieren und dort g77 nutzen...

Und klar waren die alt - aber die Physik hat sich in den letzten paar Jahrhunderten ja nicht geändert.