ripgrep 15.0

 (github.com/BurntSushi)
2 Punkte von GN⁺ 2025-10-19 | 1 Kommentare | Auf WhatsApp teilen
  • ripgrep 15.0 ist ein großes Release mit vielfältigen Updates, darunter Bugfixes, Performance-Verbesserungen und neue Funktionen
  • Zahlreiche Bugs bei der Anwendung von gitignore-Regeln wurden behoben, und die Speichernutzung bei der Verarbeitung großer Dateien wurde optimiert
  • Unterstützung für die Windows-Plattform aarch64 wurde hinzugefügt, während die Unterstützung für powerpc64 eingestellt wurde
  • Zu den neuen Funktionen gehören unter anderem die gleichzeitige Unterstützung von --json und Ersatz-Flags sowie verschachtelte geschweifte Klammern in Globs
  • Durch umfassende Performance-Verbesserungen, Fehlerbehebungen und bessere Bedienbarkeit steigt die Produktivität von Entwicklern

Überblick über ripgrep 15.0

ripgrep 15.0 ist die neueste Hauptversion von ripgrep und enthält vor allem Bugfixes, kleinere Performance-Verbesserungen und einige neue Funktionen

ripgrep ist ein Tool, das im aktuellen Verzeichnis rekursiv zeilenbasiert nach regulären Ausdrücken sucht
Standardmäßig beachtet es gitignore-Regeln und überspringt versteckte Dateien/Verzeichnisse sowie Binärdateien automatisch

Wichtige Änderungen

  • Mehrere Bugs beim gitignore-Matching wurden behoben
    • Ein häufig gemeldeter Bug bei der Anwendung von gitignore-Regeln aus übergeordneten Verzeichnissen wurde gelöst
  • Ein Bug mit erhöhter Speichernutzung bei der Verarbeitung sehr großer gitignore-Dateien wurde behoben
  • Bei rg -vf file wird jetzt alles gematcht, wenn file leer ist
  • Das Flag -r/--replace funktioniert jetzt korrekt zusammen mit --json
  • Einige Jujutsu(jj)-Repositorien werden nun wie Git-Repositorien erkannt, sodass ripgrep die gitignore-Regeln von jj befolgt
  • Globs unterstützen jetzt verschachtelte geschweifte Klammern

Plattformunterstützung

  • Es werden nun Release-Binaries für Windows aarch64 bereitgestellt
  • Für powerpc64 werden keine Release-Binaries mehr bereitgestellt
    • Grund dafür sind Probleme im CI-Release-Workflow; bei Bedarf an Tests und Support kann dies angefragt werden
  • Die ripgrep-Binaries werden mit LTO (Link Time Optimization) kompiliert, was kleine Performance-Gewinne und eine geringere Größe bringt

Performance-Verbesserungen

  • Unter Windows wurde die Performance verbessert, indem die Suche nach Helper-Binaries deaktiviert wird, wenn -z/--search-zip nicht verwendet wird
  • Unter Windows wird die Ausgabe mit Hyperlinks schneller, da die Pfadnormalisierung übersprungen wird
  • Die Performance bei großen Werten für -A/--after-context wurde verbessert

Bugfixes

  • Zahlreiche gitignore-bezogene Probleme wurden behoben, darunter die fehlende Anwendung von gitignore-Regeln aus übergeordneten Verzeichnissen
  • Der Befehl rg -vf file für leere Dateien wurde so geändert, dass alles gematcht wird
  • In .gitignore usw. werden UTF-8-BOM-Marker jetzt ignoriert
  • Die Speichernutzung bei der Verarbeitung großer gitignore-Dateien wurde optimiert
  • Ein Fehler bei der Ausgabe der Anzahl durchsuchter Bytes mit --stats wurde behoben
  • Ein Fehler bei der Verarbeitung von Globs, die mit . enden, wurde behoben
  • Ein Problem mit der Anzeige überschrittener Match-Anzahlen bei der Kombination von -m/--max-count und -U/--multiline wurde gelöst
  • Bei Verwendung von -r/--replace werden Zeilenendungen jetzt beibehalten
  • Ein Fehler mit invertiertem Exit-Code bei der Kombination -q --files-without-match wurde behoben
  • Eine Diskrepanz in der Dokumentation von -c/--count und --files-with-matches wurde behoben
  • Ein selten auftretender Panic bei großen regulären Ausdrücken und großen Eingaben wurde behoben
  • Auf der Manpage wurden Bindestriche in Optionsnamen korrekt escaped
  • Im macOS-aarch64-Release wird PCRE2 statisch kompiliert
  • Ein Bug beim Ignorierfilter für übergeordnete Verzeichnisse bei der Suche nach freigegebenen versteckten Dateien wurde behoben
  • Ein Problem mit falschen zusammenfassenden Statistiken bei Verwendung des Flags --json wurde behoben
  • Fehler in der gitignore-Verarbeitung bei absoluten Pfaden und globalen gitignore-Suchen wurden behoben
  • Ein Panic bei der Kombination von -U/--multiline und -r/--replace wurde behoben

Funktionsverbesserungen

  • Die standardmäßige Menge an Dateitypen wurde deutlich erweitert und verbessert
  • -r/--replace wurde so verbessert, dass es mit --json kompatibel ist
  • Die Completion von fish shell berücksichtigt jetzt die ripgrep-Konfigurationsdatei
  • Für --color wurde das Stilattribut italic hinzugefügt
  • Das Verzeichnis .jj wird als Git-Repository behandelt
  • Bei Nutzung von Multithreading wurde eine Funktion hinzugefügt, die die Suche in der auf der CLI angegebenen Dateireihenfolge einplant
  • Release-Artefakte für Windows aarch64 wurden hinzugefügt
  • Ein neuer highlight-Farbtyp ermöglicht das Styling von nicht übereinstimmendem Text in gematchten Zeilen
  • Für Globs und die globset-Crate wurde Unterstützung für verschachtelte Alternativen hinzugefügt
  • Die Autovervollständigung für --hyperlink-format wurde in bash, fish und zsh verbessert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-19
Hacker-News-Kommentare

  • ripgrep ist ein Tool, das mir in den letzten Jahren wirklich unglaublich viel Zeit gespart hat. Es ist ein unverzichtbares Werkzeug, das ich bei jedem neuen System als Erstes installiere, und besonders beim Erkunden alter Codebasen ist es nicht wegzudenken. Ein kleiner Wermutstropfen ist, dass bei der Verwendung der Option -F (als Literal behandeln) manche Zeichen wohl trotzdem noch als Sonderzeichen behandelt werden, die escaped werden müssen. Ich erinnere mich aber nicht mehr genau, welche Zeichen das waren. Trotzdem freue ich mich jedes Mal, wenn ich sehe, dass ripgrep weiter aktualisiert wird.

    • Wenn du ein Beispiel nennen kannst, bei welchem Zeichen es Probleme gab, kann ich es genauer erklären. -F/--fixed-strings deaktiviert Regex-Funktionalität im Pattern zu 100 % und behandelt es nur als Literal. Wenn Escaping nötig ist, liegt die Ursache wahrscheinlich eher an der Shell.

  • rg ist ein Tool, das sich fast wie Magie anfühlt. In Wirklichkeit ist es das Ergebnis hervorragender Ingenieursarbeit, kontinuierlicher Verbesserungen und der maximalen Nutzung der beeindruckenden Hardwareleistung, die wir alle täglich verwenden. Es ist außerdem eine Innovation, die Entwicklern ermöglicht hat, Code schneller zu durchsuchen und zu verstehen, ganz ohne dass dafür ein separater Standard wie LSP nötig gewesen wäre.

    • Ich frage mich wirklich, was „smithing“ in diesem Kontext bedeuten soll.

  • Die ripgrep-Codebasis ist ein Paradebeispiel für „sich ein Getränk zu holen, sich in den bequemsten Sessel zu setzen und hochwertige Software zu schmökern“. Man klickt sich durch alle Ecken des Codes und kommt aus dem Staunen nicht heraus.

  • Wie fd ist auch rg ein Kommandozeilen-Tool, dessen Nutzung einfach Freude macht. Ich liebe diese neuen, befehlsbasierten Tools.

    • Ich habe erst vor Kurzem erfahren, dass die Autoren von ripgrep und fd bei Astral arbeiten. Da dachte ich mir: Kein Wunder, dass Astral-Software so gut ist.
    • Beide Tools verhalten sich schon ohne besondere Optionen in 99 % der Fälle genau so, wie ich es will. Das spart enorm viel Zeit. Zum Beispiel reicht oft einfach rg <string> oder fd <string>.

  • Eine Funktion, die ich mir persönlich wünschen würde, ist ein „Erweiterungs“-Flag. Es würde wie -g funktionieren, aber das Eingabeargument als Dateierweiterung behandeln (zum Beispiel rg -e c,h). Der Zweck von Glob-Patterns ist schließlich meistens das Matchen von Erweiterungen.

    • Ich würde fragen wollen, ob du das Flag -t/--type schon gesehen hast. Im Beispiel könntest du also -tc verwenden. Wenn es in ripgrep keinen passenden Erweiterungstyp gibt, kannst du auch selbst einen Type definieren.

  • ripgrep war für mich einer der Hauptgründe, mich überhaupt für Rust zu interessieren. Es funktionierte so ausgereift, dass mich die Tatsache, dass es in Rust geschrieben wurde, noch neugieriger gemacht hat. Auch Jahre später benutze ich rg immer noch jeden Tag.

    • Nibbles war für mich der Hauptgrund, mich für QBasic zu interessieren. Es war so ausgereift, dass ich es spannend fand, dass es in QBasic geschrieben war, und deshalb benutze ich Nibbles bis heute jeden Tag.

  • Vor Kurzem habe ich die Option --replace entdeckt und war ziemlich beeindruckt. Zusammen mit --type genutzt fand ich es schade, dass ich gar nicht wusste, dass es solche großartigen Funktionen gibt. Künftig will ich Release Notes sorgfältiger lesen und stärker auf neue Features achten. Auch die verbesserte Integration mit jj freut mich.

  • Ein großartiges Tool, das zugleich sehr einfach zu benutzen ist. Anfangs habe ich es unter Linux verwendet, inzwischen nutze ich es auch unter Windows. Dank dieses Tools verwende ich bei der Suche jetzt direkt reguläre Ausdrücke statt Wildcards.

    • Besser als das normale grep, und auch der Befehl rg --files ist nützlich.

  • Diese Woche habe ich als Bash-Funktion eine Funktion gebaut, die ripgrep nur auf von Git verfolgten Dateien ausführt.

      rgg() {
    readarray -d '' -t FILES < <(git ls-files -z)
    rg "${@}" "${FILES[@]}"
  }

    In Verzeichnissen mit vielen Binärdateien oder Dotfiles kann man damit deutlich schneller suchen. Um Dotfiles zu durchsuchen, braucht man die Option -uu, aber mit dieser Option werden auch Binärdateien durchsucht. Wenn es Hunderte von Dateien gibt, wird schon git ls-files selbst langsam.

    • Mich würde interessieren, ob es dafür ein konkretes Beispiel gibt, bei dem es tatsächlich schneller war. Normalerweise respektiert ripgrep bereits gitignore-Regeln und verhält sich daher ähnlich wie git ls-files. Zur Referenz: -uu bedeutet, dass ripgrep gitignore und versteckte Dateien ignorieren soll, aber Binärdateien trotzdem noch überspringt. Um auch Binärdateien einzubeziehen, braucht man -uuu. Das größte Problem der Funktion ist, dass im Linux-Kernel-Repo der Fehler „argument list too long“ auftritt. Deshalb habe ich es mit xargs umgebaut. 
        $ git ls-files -z | time xargs -0 rg APM_RESUME
  ...

  real  0.638
  user  0.741
  sys   1.441
  maxmem 29 MB
  faults 0
  $ time rg APM_RESUME
  ...

  real  0.097
  user  0.399
  sys   0.588
  maxmem 29 MB
  faults 0
      Falls es eine Situation gibt, in der git ls-files -z | xargs -0 rg ... tatsächlich schneller ist als einfach rg ..., würde ich mich freuen, wenn du sie teilst.
    • Nachdem ich diesen Beitrag geschrieben hatte, habe ich das Handbuch noch einmal gelesen und festgestellt, dass ich statt -uu auch das Flag -. verwenden kann, das nur versteckte Dateien durchsucht. Es wäre schön, in Git verfolgte versteckte Dateien durchsuchen zu können, aber der Overhead beim Abfragen der Dateiliste ist selbst in Rust nicht zu vernachlässigen.
    • Vielleicht übersehe ich etwas, aber ignoriert ripgrep nicht standardmäßig ohnehin Dateien, die nicht von Git verfolgt werden?
    • Ich frage mich, ob diese Methode schneller ist als git grep.

  • Ich nutze ripgrep jeden Tag bei der Arbeit, sowohl in der Kommandozeile als auch bei der Suche in VS Code. Danke an burntsushi dafür.