Leyrer: Moderne Linux Kommandozeilenwerkzeuge - Edition "Allein zu Haus"

[@Heistergand]

00:00 Begrüßung 00:22 Sven Guckes 00:59 Leyrer 01:55 Danksagungen 02:38 Motivation für den Talk 03:17 Douglas Adams 04:27 Rear Admiral Grace Hopper 05:41 Kriterien der Toolauswahl / UNIX Philosophie 08:14 Hinweis auf vergangene Talks 10:21 Liste für heuer 10:58 xsv (jq für csv) 15:06 gron (transform json) 17:09 Helft mir! 19:20 Kelly Brazil über JSON 21:44 jc (JSONifyer) 23:00 fx (JSON viewer, bunt) 23:31 bat (cat clone mit syntax highlighting, naturgemäß bunt) 24:25 ccat (colorizing cat, bunt) 25:12 delta (Dateivergleicher, bunt) 26:10 diff-so-fanc (human readable diffs, auch bunt) 26:36 δyƒƒ /ˈdʏf/ (diff tool for yaml files) 27:32 skim (fuzzy finder like fzf) 28:40 choose (gemütliche Alternative zu cut, awk) 31:42 sd (vereinfachte sed Alternative) 33:07 map (input auf befehl mappen) 35:57 xonsh (python-powered shell) 37:24 crush (SQL-like shell) 38:25 xxh (portable shells and plugins) 40:39 starship (prompt customizer, bunt, benötigt nerdfonts) 41:37 ohmyposh (prompt customizer, sehr bunt) 42:31 q (DNS client, bunt) 44:04 gping (ping, aber als graph) 44:43 ioping (I/O latency Analyse) 46:13 broot (Verzeichnisbrowser, treeview, bisschen bunt) 46:50 ncdu (disk usage analyzer, bunt, nc interface) 47:24 duf (disk usage analyzer, auch bunt, mit Rahmen) 47:40 dust (disk usage analyzer, treeview, Klötzchengrafik, wenig bunt) 48:03 dutree (disk usage analyzer, treeview, Klötzchengrafik, super bunt) 48:17 lsd (ls deluxe, ein sehr buntes ls, bunt) 48:31 goto (navigate to aliased directories) 49:08 mcfly (shell history search replacement) 49:47 hyperfine (command-line benchmarking tool, natürlich auch bunt) 50:36 procs (ps replacement, human readable, durchsuchbar, bunt) 51:00 bottom (top alternative) 51:13 btop++ (resource monitor, bunt) 51:33 musiccube (music player, nc interface) 52:14 googler (google from command line) 53:05 viu (Bilder in der console betrachten, hübsch bunt oder half-block) 53:40 hexyl (hex viewer, bunt) 54:06 glow (markdown viewer) 54:30 falsisign (make a PDF look hand signed) 55:52 f*ck (korrigiert fehlerhafte Eingaben) 57:16 usbkill (nicht bunt) 57:43 Applaus 58:04 Fragerunde 59:04 Ponysay (cowsay mit lustigen bunten Ponys, bestimmt bunt)

[@xtra9996]

Ein jung gebliebener Nerd. Sehr sympathetic.

[@maeonlinux]

Leyrers Talks sind immer die besten, schön zu sehen, dass die Kommandozeilen-Tools wieder da sind :)

[@karli34]

Die waren nie weg ;-)

[@xmine08]

18:40 - Doch, gron hat --ungron um von gegronten Daten zurück zu JSON zu kommen. Zumindest laut deren README :) Das über JSON gejammert wird verstehe ich aber nicht .. Bitte nie wieder XML, da bekommt man beim Verarbeiten ja Würgreiz :|

[@asdfasdfasdf12]

habs mir auch gedacht nach 10 Sekunden auf github surfen ;-)

[@bloody_albatross]

Das einzige was XML besser macht als JSON: Es unterstützt Kommentare. "Aber man kann auch JSON parser verwenden die Kommentare unterstützen." Ja toll, gleich wieder vom Standard abweichen und was verwenden, was dann viele Tools nicht können. Also ich mag ja YAML, wenn man die dummen Teile weg lässt (deserialisieren von Objekten, was Code ausführt). Also für Sachen die man händisch schreibt. Wobei für so was wie HTML ist XML (oder JSX/TSX) schon gut. Also für Dinge, die mixed content benötigen.

[@alicethegrinsecatz1611]

Ja, lolcat! Ganz wichtig! Wir wissen, RGB macht einen PC immer schneller, so wie Rennstreifen auf einem Auto. Natürlich ist dann ein Command mit RGB output einfach deutlich schneller. xD

[@mikestevens8852]

Das war vor 10 Jahren Mal ganz kurz eine Woche lustig. Ist es aber schon lange nicht mehr.

[@turun_ambartanen]

Unterstützt falsisign Scanartifakte von Xerox Geräten?

[@Dalmen]

Wenn du die Zahlentauscher meinst die sind "leider" gepatcht worden. Aber währe sonst ein schönes fun futurer.

[@StormStormMegaStylez]

LOL die Idee hätte meinem Hirn entsprungen sein sollen. Hut ab du hast meinen Tag gemacht

[@bloody_albatross]

Ich hab mir mal selber in Rust ein kleines Kommandozeilentool geschrieben: Einen Hex-Viewer (also kein Editor). Warum? Weil alle die ich ausprobiert hab die dümmsten einfachsten aber nützlichen Features nicht könne. Features: * verwendet mmap(), also kann auch *ganz* große Dateien (64bit Architektur vorausgesetzt, natürlich) * zeigt Daten am Cursor in 8, 16, 32, 64 bit integer und 32, 64 bit float an, wahlweise little und big endian * Sprung zu absoluten und relativen offsets * weil Kommandozeilentool kann man alle Werte kopieren (wie z.B. angezeigten Offset, was bei vielen GUI Editoren nicht geht und oft garnicht richtig angezeigt wird) * selektiere Bereiche -> zeigt matchende Bereiche an und man kann Selektion in eine neue Datei speichern * Suche nach: Selektion, UTF-8 Text, binary (hex string), 8, 16, 32, 64 bit integer und 32, 64 bit float in little und big endian * Search history (nicht persistiert) * Filename Autocompletion und History (nicht persistiert) * ist Rust üblich einfach zu kompilieren (hab ImHex z.B. nicht zum Funktionieren gebracht) Ja, das alles ist sehr simpel. Umso unverständlicher, dass ich mir das echt selber programmieren hab müssen! Und ja, Code ist etwas messy. Auch weil ich noch nie was mit ncurses o.Ä. gemacht hab. *Wenn jemand ein entsprechendes Tool für Linux kennt, dass das alles kann, bitte sagen!* Dann brauch ich das Tool nicht maintainen. github.com/panzi/rust-hox

[@ShenLong991]

08:15 - Bash und Python Skripte, wären die okay? Das Beispiel mit "dont do that". Bash und Python Skripte brauchen zwar einen Interpreter, aber diese sind doch immerhin üblicherweise standardmäßig installiert, oder?

[@marc.w.7692]

Ideen : alle Wünsch : keine Empfindung : wow Sonstiges : gespannt wie n flitzebogen

[@marc.w.7692]

Was Solln das ? Das ist wowiwow !!! Mag das mega gern, jedes Detail!

[@turun_ambartanen]

Die Python shell wird so funktionieren, wie die Python REPL funktioniert. Enter drücken nach: - einer Zeile, die auf ":" Endet -> neue Zeile Anfangen. - einer Zeile, die mit tab beginnt -> neue Zeile Anfangen. - ansonsten -> Befehl ausführen

[@karli34]

Kann mich bitte mal jemand erhellen: Bei mir liefert "file *" das Gleiche, wie das im Video bei Pos. 35:45 gezeigte, wesentlich kryptischere und durch die Pipe auch mehr System-Ressourcen nutzende "ls | ./map f 'file "$f"' - was habe ich übersehen? Davon abgesehen, vormatiert "file *" zwei schöne Spalten, die Version mit "map" nicht.

[@1Hippo]

Das ist nicht ganz equivalent und funktioniert nur weil file mehrere (beliebig viele) Argumente in einem Aufruf verarbeiten kann. Kann nicht unbedingt jedes tool. Finde das Beispiel aber auch nicht so gut, da gibt es sicher interessantere Anwendungen. Z.B. könnte man mit git log anfangen, filtern und dann mit map für jeden Commit weitere Infos von einem Server abfragen um damit die Beschreibung anreichern. Mit xargs geht das natürlich auch, besitzt nur etwas komplexere Syntax.

[@yahmk3978]

Vielen Dank!

[@NeverCodeAlone]

Sehr schön ich stehe ja total auf oh-my-zsh vor allem mit jump, z und dem autocompletion plugin ;)

[@bluejanis5317]

9:00 Wäre nett gewesen kurz zur erklären, was die Dinger machen.

[@michaelb2047]

Muss du dir wohl die talks anschauen ;)

[@thebamplayer]

@@michaelb2047 Oder einen Talk halten.

[@aim__freakz8499]

wirklich toller talk! :)

[@batcat9k]

Danke! Sehr cool! 🚀

[@Kraja111]

wenn jemanden eine objekt shell in unix interessiert kann ich die nushell empfehlen. Ich hoffe leyrer ließt dass, aber ich kann mir gut vorstellen, dass ers schon kennt

[@porky1118]

8:00 Ich würde der Unix-Philosophie nicht zustimmen. Also eigentlich nur dem dritten Punkt. Text streams sollten kein universelles interface sein.

[@DuRoehre90210]

RIP Sven. RIP Schily. RIP Ian (Debian-Ian).

[@W00PIE]

Ich verstehe nicht ganz, was er meint, wenn er sagt, dass er sich mit JSON nicht so gut auskennt - was gibt es denn da groß zu kennen? Nach 5 Minuten weiß man alles darüber 🤔

[@lewddrip5383]

sympathischer Mann

[@toniferic-tech8733]

Es geht auch ohne „map“ mit Metaprogrammierung auf der shell: ls | awk ‘{print “file “$0}‘ | bash

[@Am6-9]

TMTOWTDI: for file in $(ls) ; do file $file; done

[@marloelefant7500]

Was ist mit "find -exec"?

[@toniferic-tech8733]

@@marloelefant7500 "find -exec" ist das Ideale Werkzeug wenn es ums Dateisystem geht. Was wenn nicht? Beispiel: Mehrere Logdateien nach Suchbegriffen filtern, aus den gefundenen Zeilen Dateinamen herausfiltern, Befehle ausführen für jeden der so erzeugten Dateinamen.

[@marloelefant7500]

@@toniferic-tech8733 Das wiederum klingt nach einem Fall für "grep | xargs". Auf jeden Fall finde ich das gegebene Beispiel problematisch, da der im Beispiel beschriebene Anwendungsfall 1. einfacherer und 2. sicherer mit find geht. Die Ausgabe von ls in irgendwas rein zu pipen lässt auf jeden Fall meine Alarmglocken anschlagen.

[@unbekannter_Nutzer]

Alle falsch! statt ls | ./map f 'file "$f"' einfach file * , Ihr Minigolfer! ;) Und `file` ist ja keine Ausnahme unter den coreutils. Vielmehr können die meisten Programme, bei denen man sich wünscht, mehrere Dateien zu übergeben, das schon. Es ist im Gegenteil schwierig ein Programm zu finden, das das nicht kann.

[@christianschneider4926]

Egal was kommt... Sven Guckes!

[@kilrath929]

Thank you so much! It work!

[@Enkaptaton]

Bin per "nächstes Video abspielen" völlig random hier gelandet und völlig fachfremd. Es gibt also einen Guru für Kommandozeilenfunktionen... aha... eine solche heißt ...Gulasch? wtf

[@richy2837]

plötzlich und unerwartet gestorben hört man relativ häufig in letzter Zeit

[@wumwum42]

ich nutze überall zoxide (cd mit automatoschen index) Man kann dann wenn man den order ~/programme/abc einfach z abc von home aus machen. ist extrem geil.

[@OliverBusse]

Mega!

[@marc.w.7692]

Integrated future !!!

[@marc.w.7692]

Zumindest ist alles für alles bereit ... bin in Gedanken schon dort und probier mal rum ...

[@marc.w.7692]

Der dirtcode !!! Wie liebevoll und dann noch in PDF rumfuhrwerken dürfen ... das wird chic chic chic chic chic chic ... absenden und klick

[@Detyrious]

Damn, was ist das für eine Shell? Die History-Suggestions sind mal richtig cool. Jemand eine Ahnung?

[@alphaomega522]

Ohmyzsh ?

[@marc.w.7692]

Wird mir grad bewusst : ihr habt teile eurer Kultur aufgegeben, also die Logik visuell näher an den Code gerückt ... bin sprachlos !!! Freu freu freu

[@marcello4258]

2018: Ranger.. naja das ist schon mal kein standalone bin

[@marc.w.7692]

Didaktisch 1

[@TheHelltrasher]

@Sven #PlötzlichUndUnerwartet

[@TheSubsven]

Hui, "export PATH=./:$PATH" - die so denkbar schlechteste Idee ...

[@schn33w0lf8]

kannst du mich erleuchten? weiß nichtmal, was die path variable macht ':D nie gebraucht

[@TheSubsven]

@@schn33w0lf8 Die PATH-Variable gibt an, wo die Shell die Executables zu Kommandos sucht, als eine Abfolge von Verzeichnissen mit abnehmender Priorität. Da steht z.B. u.a. "/bin" drin, wenn Du "ls" eingibst, wird es typischerweise dort gefunden. Wenn Du allerdings an erster Stelle "./" in diese Liste im PATH schreibst, wird immer zuerst im aktuellen Verzeichnis gesucht. D.h. wenn Du z.B. nach "/tmp" wechseln und Dir dessen Inhalt mittels "ls" einzeigen lassen willst, aber irgend ein anderer User auf dem System unter dem Namen "ls" dort ein Executable abgelegt hat, dann wuerde nicht mehr das offizielle "/bin/ls" , sondern jetzt "/tmp/ls", also ein vollkommen fremdes Programm, ausgefuehrt. Und das kann natuerlich alles Beliebige machen, z.B. Deine SSH-Keys irgendwo hinkopieren, und danach noch brav das eigentliche "ls" ausfuehren, damit Du nicht einmal merkst, dass sich jemand reingeschummelt hat. Deswegen ist das eine schlechte Idee und deswegen ist's eher unhuebsch, sowas in einem Vortrag zu sehen, sonst denkt da noch jemand "oh, das ist ja praktisch!", ohne sich der security implications bewusst zu sein. (Und zu meinem Beispiel: Ja, /tmp sollte noexec gemounted sein, aber es gibt ja auch andere Verzeichnisse, in denen sowas passieren kann ...)

[@merkdirwas]

@@TheSubsven wenn du aber genau nicht auf bash internals oder deinem system pfuschen willst, ist das doch genau so richtig - die demotools liegen dabei im aktuellen Verzeichnis und laufen so nur in dieser Shell. Generell sollte man sowas weniger tun, hier ist es mM. das genau richtige.

[@turun_ambartanen]

@@merkdirwas Nur kurz, wenn man eh schon weiß was alles im directory liegt, ist es nicht schlimm, ja. export PATH=$PATH:./" wäre aber auf jeden fall besser gewesen. Dann wird /bin/ls gefunden, bevor /tmp/ls gefunden wird.

[@TheSubsven]

@@merkdirwas Fuer so einen Fall waere doch ein statisches Verzeichnis "~/mydemos" praktischer. Mir geht's aber eher darum, sowas in einem Vortrag "einfach so" zu zeigen, weil ggf. ein Unix-Neuling denkt "oh, das ist total sinnvoll - wie damals bei DOS!", ohne die Auswirkungen zu erkennen.

[@SierraX369]

Nehme dir immer noch das "jetzt wird systemd in Linux verwendet, lebt damit" von vor ein paar Jahren übel, gerade wenn hier im Video auf die Unix Philosophie eingegangen wird, der Systemd ja sowas von widerspricht

[@btom1990]

Kann zu dem Thema immer nachfolgendes Video empfehlen, wenn mal wieder völlig unreflektiert "systemd verstößt gegen UNIX" gerufen wird: kzbin.info/www/bejne/pZCkeqpvl6yindE

[@1Hippo]

3:40 - Punkt 3 ist zutreffend

[@maximiliankalhofer8539]

NO HATE: können wir mal über seine Männerbrüste reden? Ist das krankhaft? wie kann man ihm helfen?

[@karli34]

Wem soll das helfen, wenn *wir* darüber reden? Frag' ihn doch direkt - und zwar via persönlichem Kontakt.

[@unbekannter_Nutzer]

Worauf Du nun wieder achtest! Ob das noch ganz gesund ist?

[@milahu]

xclip ... xargs ... mmv ... direnv ... subdl ... sponge ... pv ... nix-locate ... speedtest-cli ... torsocks ...

[@marloelefant7500]

Wenn ich auf alle Dateien eine Operation ausführen möchte, verwende ich üblicherweise find . -exec op {} \;

[@UlrichRoss]

Das startet pro Zeile mindestens einen neuen Prozess. xargs übergibt hunderte Dateinamen auf einmal. Für die Kommandozeile geht beides, für cron besser xargs.

[@unbekannter_Nutzer]

@@UlrichRoss Mit `find . -exec cmd {} +` geht das auch mit find (GNU-find). Bei `file` geht aber auch einfach `file *`.