Der Autor wechselte von Vim/Neovim zu Helix, einem Texteditor, angezogen von der einfachen Integration von Language Servern. Nach Jahren des Kampfes mit komplexen Vim-Konfigurationen waren die integrierten Funktionen von Helix ansprechend. Die Such- und Schnellreferenzfunktionen von Helix sind besonders hilfreich und werden geschätzt. Der Autor passte sich bereitwillig an die Tastenkombinationen von Helix an, obwohl einige Vim-Gewohnheiten angepasst werden mussten. Der Autor fand die Mehrfachcursor und das Pufferwechseln von Helix besser als die Makros und Tabs von Vim. Allerdings bemerkt der Autor einige Ärgernisse, darunter Probleme beim Zeilenumbruch mit Listen und das Fehlen von persistentem Undo und autoreloading. Trotz dieser Frustrationen hat sich der Autor an Helix gewöhnt und empfand den Übergang als einfacher als erwartet. Die einfache Konfiguration des Editors ist ein großer Vorteil gegenüber der Komplexität seiner bisherigen Einrichtung. Der Autor nutzt Helix hauptsächlich in einem Terminal und organisiert Projekte mit dedizierten Fenstern. Der Autor ist nach drei Monaten Nutzung mit Helix zufrieden, bleibt aber offen für eine mögliche Rückkehr zu Vim.

Der Autor hat ein neues Zine namens „The Secret Rules of the Terminal“ veröffentlicht, das erklärt, wie das Terminal funktioniert, und Tipps und Tricks für die Verwendung von Terminalprogrammen gibt. Der Autor benutzt das Terminal seit 20 Jahren täglich, hatte aber immer noch viele Missverständnisse darüber, wie es funktioniert. Das Terminal weist viele kleine Inkonsistenzen auf, z. B. dass die Pfeiltasten manchmal zum Navigieren verwendet werden können und manchmal nicht. Die „Regeln“, wie das Terminal funktioniert, sind schwer zu verstehen, da es aus vielen verschiedenen Softwarekomponenten besteht. Das Zine erklärt, wie die vier Komponenten des Terminals (Shell, Terminal-Emulator, Programme und TTY-Treiber) zusammenwirken und vermittelt Kernkonventionen für die Funktionsweise im Terminal. Der Autor hat während des Schreibens des Zines erstaunlich viel gelernt, unter anderem, wie man seine Shell konfiguriert und Escape-Codes versteht. Das Zine ist als PDF oder Druckversion zum Kauf erhältlich, und ein 15er-Pack aller Zines des Autors ist ebenfalls verfügbar. Der Autor erhielt Hilfe von vielen Personen, darunter ein technischer Gutachter, der PuTTY geschrieben hat, und jemand, der die inneren Abläufe des Terminals versteht. Die Druckversion wird im August versandt, und der Autor muss auf eingehende Bestellungen warten, um zu bestimmen, wie viele Exemplare gedruckt werden sollen. Das Zine ist für 12 US-Dollar erhältlich, und der Autor hofft, dass es den Lesern helfen wird, das Terminal besser zu verstehen und zu nutzen.

Der Autor ist kein C-Programmierer, muss aber gelegentlich C/C++-Programme aus Quellcode kompilieren. Früher verließ er sich darauf, dass andere die Programme kompilierten, aber seit dem Wechsel zu einem Mac musste er lernen, wie man Programme selbst kompiliert. Um ein C-Programm zu kompilieren, muss man einen C-Compiler installieren, die Programmabhängigkeiten installieren, gegebenenfalls ./configure ausführen und make ausführen. Der Autor erklärt, wie man einen C-Compiler installiert, Abhängigkeiten installiert und ./configure ausführt. Er diskutiert auch häufige Probleme, die während des Kompilierungsprozesses auftreten können, wie z. B. Abhängigkeitsprobleme und Compilerfehler. Der Autor erklärt, wie man diese Probleme beheben kann, indem man Flags an den Compiler und den Linker übergibt. Er gibt auch Tipps, wie man bestimmte Dateien erstellt, sich ansieht, wie andere Paketierungssysteme dasselbe C-Programm erstellt haben, und das Binary installiert. Der Autor kommt zu dem Schluss, dass das Verständnis der Grundlagen der Funktionsweise von C-Programmen nützlich sein kann, auch wenn man kein C-Programmierer ist.

ANSI-Escape-Codes verbessern die Benutzerfreundlichkeit von Terminals, sind aber nicht vollständig standardisiert, was zu Zuverlässigkeitsproblemen führt. Der Autor lernte ANSI-Escape-Codes während des Studiums von Terminals kennen und wollte die sie umgebenden Standards verstehen. Escape-Codes werden von Terminalemulatoren zur Kommunikation mit Programmen verwendet und gibt es in zwei Arten: Eingabecodes für Tastendrücke und Mausbewegungen und Ausgabecodes für Aufgaben wie das Einfärben von Text und das Verschieben des Cursors. Der ECMA-48-Standard, veröffentlicht 1976, definiert allgemeine Formate für Escape-Codes und einige spezifische Codes, ist aber nicht vollständig. Xterm-Steuersequenzen sind eine weitere Gruppe von Escape-Codes, die von Terminalemulatoren weit verbreitet implementiert wurden, obwohl sie keinen formalen Standard darstellen. Die terminfo-Datenbank, verwaltet von ncurses, speichert Escape-Codes für verschiedene Terminals, und einige Programme verwenden sie, um zu bestimmen, welche Codes zu verwenden sind. Einige Programme verwenden jedoch nicht terminfo, sondern hartcodieren einen "gemeinsamen Standardsatz" von Escape-Codes, die in den meisten Terminalemulatoren funktionieren. Es besteht keine klare Übereinstimmung darüber, was dieser gemeinsame Satz ist, aber er enthält wahrscheinlich Codes aus VT100, ECMA-48 und xterm. Trotz der Herausforderungen könnte eine Standardisierung von ANSI-Escape-Codes zu einem reichhaltigeren Terminalerlebnis führen, und der Autor hofft, dass eine klarere Standardslandschaft Innovationen bei Terminalemulatoren und Anwendungen fördern könnte.

Um ein Verzeichnis zu Ihrem Pfad hinzuzufügen, müssen Sie zunächst ermitteln, welche Shell Sie verwenden, was durch Ausführen des Befehls ps -p $$ -o pid,comm= erreicht werden kann. Die Standard-Shell unter Linux ist bash, während es unter Mac OS zsh ist. Als Nächstes müssen Sie die Konfigurationsdatei Ihrer Shell finden, die normalerweise ~/.zshrc für zsh, ~/.bashrc für bash und ~/.config/fish/config.fish für fish ist. Beachten Sie jedoch, dass die Konfigurationsdatei von bash eine von drei Optionen sein kann: ~/.bashrc, ~/.bash_profile oder ~/.profile, und Sie möglicherweise testen müssen, welche verwendet wird. Nachdem Sie die Konfigurationsdatei Ihrer Shell gefunden haben, müssen Sie ermitteln, welches Verzeichnis Sie Ihrem Pfad hinzufügen möchten. Dies kann durch Überprüfen der Installationsanweisungen für das Programm, das Sie ausführen möchten, oder durch Verwenden eines Befehls, der speziell für den Installer ist, wie z.B. npm config get prefix für Node/npm, erreicht werden. Sobald Sie das richtige Verzeichnis gefunden haben, sollten Sie überprüfen, ob es korrekt ist, indem Sie versuchen, das Programm von diesem Verzeichnis aus auszuführen. Dann müssen Sie Ihre Shell-Konfigurationsdatei bearbeiten, um das Verzeichnis Ihrem Pfad hinzuzufügen. Die Syntax dafür variiert je nach Shell, wobei bash und zsh export PATH=$PATH:~/directory verwenden, und fish set PATH $PATH ~/directory verwendet. Schließlich müssen Sie Ihre Shell neu starten, damit die Änderungen wirksam werden. Wenn das Programm immer noch nicht funktioniert, müssen Sie möglicherweise das Verzeichnis an den Anfang Ihres Pfades anstatt an das Ende hinzufügen oder das Verzeichnis auf eine andere Weise Ihrem Pfad hinzufügen, wenn Sie das Programm von einer IDE oder einem Cron-Job ausführen. Darüber hinaus können einige Installer ein Skript bereitstellen, um Ihren Pfad automatisch einzurichten, das durch Hinzufügen einer Zeile zu Ihrer Shell-Konfigurationsdatei ausgeführt werden kann. Es ist jedoch möglich, dass Sie das Verzeichnis lieber manuell Ihrem Pfad hinzufügen möchten.

Es wurde eine Umfrage durchgeführt, um Informationen über die frustrierendsten Aspekte der Terminalnutzung zu sammeln. 1600 Personen nahmen teil. Die Teilnehmer waren größtenteils erfahrene Benutzer: 40 % nutzten das Terminal seit über 21 Jahren und 95 % mindestens seit 4 Jahren. Zu den häufigsten Frustfaktoren gehörten das Erinnern an die Syntax, das Wechseln des Terminals, Farbprobleme, Tastenkombinationen und Probleme beim Kopieren und Einfügen. Weitere häufige Frustfaktoren waren Entdeckbarkeit, steile Lernkurve, Verlauf, schlechte Dokumentation und Probleme beim Zurückblättern. Einige Benutzer gaben auch an, dass sie sich bei der Verwendung des Terminals unwohl oder ängstlich fühlten, während andere Probleme mit Shell-Skripten, inkonsistenten Befehlszeilenargumenten und der Leistung hatten. Die Umfrage ergab auch, dass viele Benutzer Probleme damit haben, Dotfiles auf verschiedenen Systemen synchron zu halten und Fenster mit tmux-Tabs und Terminal-Tabs zu verwalten. Einige Benutzer gaben an, sich von den Funktionen des Terminals überwältigt zu fühlen und sich eine einfachere Erfahrung zu wünschen. Die Umfrageergebnisse werden zur Erstellung eines Magazins über das Terminal verwendet. Insgesamt unterstreicht die Umfrage die Komplexität und Herausforderungen der Terminalnutzung, selbst für erfahrene Benutzer.

Der Autor reflektiert darüber, was eine "moderne" Terminalerfahrung ausmacht. Dazu gehören Funktionen wie mehrzeilige Unterstützung für Kopieren und Einfügen, unbegrenzter Shell-Verlauf und 24-Bit-Farbunterstützung. Er räumt ein, dass das Erreichen dieses Erlebnisses aufgrund der vielen beteiligten Komponenten – Shell, Terminalemulator und Texteditor – schwierig sein kann. Der persönliche Ansatz des Autors zur Erreichung einer modernen Terminalerfahrung besteht in der Verwendung der Fish-Shell, eines Terminalemulators mit 24-Bit-Farbunterstützung und Neovim mit einer benutzerdefinierten Konfiguration. Für diejenigen, die nicht viel Zeit mit der Konfiguration verbringen möchten, schlägt der Autor die Verwendung von Fish oder Zsh mit Oh-My-Zsh, einem Terminalemulator mit 24-Bit-Farbunterstützung und einem Texteditor wie Micro oder Helix vor. Der Autor merkt jedoch an, dass selbst mit diesen Optionen das Erreichen einer modernen Terminalerfahrung aufgrund von Problemen mit der Shell, dem Texteditor und einzelnen Anwendungen schwierig sein kann. Die Shell kann besonders problematisch sein, da beliebte Shells wie Bash und Zsh Anpassungen benötigen, um ein zufriedenstellendes Erlebnis zu bieten. Der Texteditor kann ebenfalls ein Problem darstellen: Optionen wie Vim und Emacs erfordern eine umfangreiche Konfiguration, während Nano nur eingeschränkte Möglichkeiten bietet. Der Autor stellt fest, dass auch einzelne Anwendungen Probleme verursachen können und das Debuggen dieser Probleme zeitaufwendig sein kann. Letztendlich kommt der Autor zu dem Schluss, dass das Erreichen einer modernen Terminalerfahrung Geduld, Experimentierfreude und die Bereitschaft erfordert, kleine Änderungen vorzunehmen und sich an neue Tools und Konfigurationen anzupassen.

Programme im Terminal verhalten sich konsistent, obwohl es keine Standards gibt. Sie folgen bestimmten Regeln, wie zum Beispiel, dass nicht-interaktive Programme beenden, wenn Strg+C gedrückt wird, TUIs (Text-basierte Benutzeroberflächen) beenden, wenn 'q' gedrückt wird, und REPLs (Read-Eval-Print-Loops) beenden, wenn Strg+D auf einer leeren Zeile gedrückt wird. Die meisten Programme unterstützen readline-Tastenkombinationen, deaktivieren Farben, wenn sie in eine Pipe schreiben, und verwenden '-' um stdin/stdout zu bedeuten. Diese Regeln sind beschreibend, nicht vorschreibend, und das Verständnis von ihnen hilft dabei, Terminal-Programme effektiv zu nutzen.

"Pufferung ist in Terminal-Programmen üblich, um die Leistung durch Gruppierung von Ausgaben bis zu einer bestimmten Größe zu verbessern. Dies kann Probleme verursachen, wenn Daten langsam einem Pipe hinzugefügt werden, da Programme ihre Ausgaben puffern und nie schreiben. Grep und ähnliche Programme verwenden standardmäßig Block-Pufferung, wenn sie in Pipes schreiben, aber Zeilen-Pufferung, wenn sie in Terminals schreiben, was erklärt, warum der Befehl "tail -f /some/log/file | grep thing1 | grep thing2" möglicherweise keine Ausgabe anzeigt. Einige Befehle puffern ihre Ausgaben, darunter grep, sed, awk, tcpdump und jq, während Befehle wie tail, cat und tee keine Pufferung verwenden. Programmiersprachen wie C, Python, Ruby und Perl können auch ihre Ausgaben puffern, mit verschiedenen Methoden, um die Pufferung zu deaktivieren. Wenn Strg+C auf einer Pipe gedrückt wird, kann der Ausgabenpuffer eines Programms verloren gehen, da das Signal vor dem Fluschen des Puffers empfangen wird. Pufferung tritt auch auf, wenn auf eine Datei umgeleitet wird, aber sie verhält sich im Allgemeinen wie erwartet, mit dem Inhalt des Puffers, der vor dem Programm-Exit geschrieben wird. Um die Pufferung zu vermeiden, kann man ein Programm ausführen, das schnell beendet wird, den "--line-buffered"-Flag mit grep verwenden, den Befehl mit awk neu schreiben, stdbuf verwenden oder unbuffer verwenden, um das Programm zu zwingen, sich so zu verhalten, als würde es in ein Terminal schreiben. Die ideale Lösung hängt von der spezifischen Situation ab, wobei unbuffer eine zuverlässige Wahl für sein konsistentes Verhalten ist. Während Pufferung im Allgemeinen kein häufiges Problem ist, kann sie auftreten, wenn Daten langsam einem Pipe hinzugefügt werden. Eine Umgebungsvariable, um die Pufferung zu deaktivieren, könnte nützlich sein, aber ihr Design und ihre Implementierung stellen Herausforderungen dar."

Der Autor bevorzugt es, JavaScript ohne ein Build-System zu schreiben und teilt sein Erlebnis mit dem Importieren von Bibliotheken ohne ein Build-System. Er erklärt die drei Haupttypen von JavaScript-Dateien, die eine Bibliothek bereitstellen kann: "klassische" globale Variable-Dateien, ES-Module und CommonJS-Module. Der Autor zeigt, wie man die Dateien in einem Bibliotheks-NPM-Build findet und diskutiert das Verwenden von Importmaps, um ES-Module im Browser zu verwenden. Er erwähnt auch die Verwendung von esm.sh, um CommonJS-Module in ES-Module zu konvertieren. Der Autor bietet Beispiele für die Verwendung von Chart.js, @atcute/oauth-browser-client und @atproto/oauth-client-browser, diskutiert die verschiedenen Ansätze für jeden. Er weist darauf hin, dass die Verwendung von Importmaps Browsersupport erfordert, was ein Problem für ältere Browser sein könnte. Der Autor erwähnt auch die Verwendung von esbuild als Alternative zu Importmaps. Schließlich fasst er die drei Typen von JavaScript-Dateien und wie man sie identifiziert und verwendet, zusammen.

Der Autor hat einen neuen Abschnitt auf seiner Website erstellt, genannt "TIL" (Heute habe ich gelernt), um interessante Werkzeuge und Fakten zu speichern, die er auf sozialen Medien postet. Das Ziel ist es, einen Ort zu haben, um diese kleinen Informationen zu speichern, ohne einen vollständigen Blog-Beitrag schreiben zu müssen. Der Autor postet oft "coole Dinge" auf Mastodon und Bluesky, aber hatte keinen Ort, um sie zu speichern. Dieser neue Abschnitt ist von Simons Willisons TIL-Blog inspiriert, aber die Beiträge des Autors sind viel kürzer. Der Autor hat einen neuen Ordner für den TIL-Abschnitt erstellt, benutzerdefiniertes Styling hinzugefügt und einen separaten RSS-Feed eingerichtet. Der TIL-Abschnitt ist hauptsächlich für den eigenen Gebrauch des Autors gedacht, als eine Möglichkeit, nützliche Links und Werkzeuge zu speichern. Der Autor hat den Abschnitt seit ein paar Wochen verwendet und hat festgestellt, dass er gut funktioniert. Der Autor ist ein Fan der "POSSE"-Idee (posten auf deiner eigenen Website, auf anderen Plattformen teilen), aber findet es einfacher, bestimmte Kategorien von Inhalten zu identifizieren, die er auf seiner eigenen Website speichern möchte. Der Autor hat E-Mail-Listen und RSS-Feeds für seine Blog-Beiträge und Comics und könnte möglicherweise eine Zusammenfassung der TIL-Beiträge in seinen Newsletter aufnehmen. Der Autor bevorzugt es, bestimmte Inhalte wie Umfragen und Witze ephemeral zu halten und nur bestimmte Kategorien von Inhalten zu archivieren.

Der Autor untersucht das Konzept von Steuerungssequenzen in der Konsole, wie z.B. Strg+A, Strg+C und Strg+W, und wie sie funktionieren. Es gibt 33 ASCII-Steuerungszeichen, die in drei Kategorien eingeteilt werden können: Codes, die vom Terminaltreiber des Betriebssystems verarbeitet werden, Codes, die Literalen Tastenanschlägen entsprechen, und Codes, die von readline verwendet werden. Der Autor bemerkt, dass es keine echte Struktur gibt, in die die Codes eingeteilt sind, da sie organisch entstanden sind. Es gibt nur 33 Steuerungssequenzen, was bedeutet, dass die Verwendung von Strg+1 als Tastenkürzel nicht sinnvoll ist, da es dem Drücken der 1-Taste entspricht. Der Autor bemerkt auch, dass Strg+Shift+C keine Steuerungssequenz ist und ihr Verhalten vom Terminal-Emulator abhängt. Die offiziellen ASCII-Namen für Steuerungssequenzen sind nicht sehr nützlich, da sie ursprünglich für Telegrafenmaschinen definiert wurden und seitdem umfunktioniert wurden. Der Autor findet es schwierig, Strg+M und Strg+I als Tastenkürzel zu verwenden, da sie den Enter- bzw. Tab-Tasten entsprechen. Der Autor stellt ein Python-Skript zur Verfügung, um zu identifizieren, welche Steuerungssequenzen gesendet werden, wenn verschiedene Tastenkombinationen gedrückt werden. Der Autor bemerkt, dass einige Steuerungssequenzen, wie z.B. Strg+W und Strg+U, je nachdem, ob die Konsole im kanonischen oder nicht-kanonischen Modus ist, unterschiedlich verarbeitet werden können. Schließlich räumt der Autor ein, dass es viele Einschränkungen und Konflikte bei Steuerungssequenzen gibt und dass nicht alle dieser Informationen unbedingt in der Praxis nützlich sind.

Der Autor von Mess With DNS hatte Probleme damit, dass das Programm wegen Speichermangels abstürzte und vom Betriebssystem (OOM) getötet wurde, was wiederum Probleme mit dem Backup-Skript verursachte. Um dies zu lösen, entschied sich der Autor, Mess With DNS so anzupassen, dass es weniger Speicher benötigt. Das Programm lädt eine Datenbank von IP-Adressen in den Speicher, was etwa 117 MB Speicher beanspruchte. Der Autor versuchte drei verschiedene Ansätze, um den Speicherverbrauch zu reduzieren. Der erste Ansatz bestand darin, SQLite zu verwenden, um die Daten auf der Festplatte zu speichern, was das ursprüngliche Speicherziel erreichte, aber Probleme bei der Speicherung von IPv6-Adressen aufwarf und 500 Mal langsamer war als die ursprüngliche binäre Suche. Der zweite Ansatz bestand darin, einen Trie zu verwenden, aber dieser benötigte mehr Speicher und war langsamer als die ursprüngliche binäre Suche. Der dritte Ansatz bestand darin, das Array so anzupassen, dass es weniger Speicher benötigt, indem die Felder Name und Land dupliziert wurden, was den Speicherverbrauch von 117 MB auf 65 MB reduzierte, und dann den Wechsel zu netip.Addr anstelle von net.IP, was weitere 20 MB Speicher einsparte, so dass insgesamt 46 MB erreicht wurden. Der Autor konnte insgesamt 70 MB Speicher einsparen.