ripgrep 15.0

(github.com/BurntSushi)

2 puntos por GN⁺ 2025-10-19 | 1 comentarios | Compartir por WhatsApp

ripgrep 15.0 es una versión importante que incluye varias actualizaciones, como corrección de errores, mejoras de rendimiento y nuevas funciones
Se corrigieron varios errores relacionados con la aplicación de reglas de gitignore, y se realizó una optimización de memoria al procesar archivos grandes
Se agregó soporte para la plataforma Windows aarch64 y se retiró el soporte para powerpc64
Entre las nuevas funciones están la compatibilidad simultánea de --json y flags de reemplazo, y el soporte de llaves anidadas en globs
Las mejoras generales de rendimiento, correcciones de errores y mejoras de usabilidad aumentan la productividad de los desarrolladores

Resumen de ripgrep 15.0

ripgrep 15.0 es la versión mayor más reciente de ripgrep, centrada principalmente en correcciones de errores, pequeñas mejoras de rendimiento y la incorporación de nuevas funciones menores

ripgrep es una herramienta que busca recursivamente patrones de expresiones regulares por líneas en el directorio actual
De forma predeterminada sigue las reglas de gitignore y omite automáticamente archivos/directorios ocultos y archivos binarios

Cambios principales

Se corrigieron varios errores relacionados con el matching de gitignore
- Se resolvió un error reportado con frecuencia relacionado con la aplicación de reglas de gitignore de directorios superiores
Se solucionó un error de aumento en el uso de memoria al procesar archivos gitignore muy grandes
En rg -vf file, si file está vacío, ahora se hace match con todo
El flag -r/--replace ahora funciona correctamente junto con --json
Algunos repositorios de Jujutsu (jj) ahora también se reconocen como repositorios git, por lo que ripgrep sigue el gitignore de jj
Los globs ahora admiten llaves anidadas

Soporte de plataformas

Ahora se ofrecen nuevos binarios de lanzamiento para Windows aarch64
Ya no se ofrecen binarios de lanzamiento para powerpc64
- Se suspendieron por problemas en el workflow de releases de CI; se puede solicitar si se desea prueba y soporte
El binario de ripgrep se compila con LTO (optimización total en tiempo de enlace), lo que aporta una ligera mejora de rendimiento y reducción de tamaño

Mejoras de rendimiento

En Windows, si no se usa la opción -z/--search-zip, mejora el rendimiento al desactivar la búsqueda de binarios helper
En Windows, mejora la velocidad al omitir la normalización de rutas al mostrar hipervínculos
Mejora el rendimiento al manejar valores grandes con -A/--after-context

Corrección de errores

Se corrigieron múltiples problemas relacionados con gitignore, como la falta de aplicación del gitignore de directorios superiores
Se corrigió para que el comando rg -vf file sobre un archivo vacío haga match con todo
Se agregó procesamiento para ignorar el marcador UTF-8 BOM en .gitignore y similares
Optimización del uso de memoria al procesar archivos gitignore grandes
Se corrigió el error en la salida de bytes buscados al usar --stats
Se corrigió un error al procesar globs que terminan en .
Se resolvió el problema de mostrar exceso de coincidencias al usar la combinación -m/--max-count y -U/--multiline
Se cambió -r/--replace para que preserve el terminador de línea
Se resolvió el error de inversión del código de salida al usar la combinación -q --files-without-match
Se resolvió la inconsistencia de documentación entre -c/--count y --files-with-matches
Se corrigió un problema raro de panic con expresiones regulares grandes y entradas grandes
Se procesó el escape de guiones en los nombres de flags de opciones en la man page
Se habilitó la compilación estática de PCRE2 en la release de macOS aarch64
Se corrigió un error del filtro de ignorar directorios superiores al buscar archivos ocultos incluidos en whitelist
Se corrigió el problema de estadísticas de resumen incorrectas al usar el flag --json
Se corrigieron errores de procesamiento de gitignore al buscar con rutas absolutas y gitignore global
Se corrigió un problema de panic que ocurría al usar -U/--multiline junto con -r/--replace

Mejoras de funciones

El conjunto predeterminado de tipos de archivo fue ampliado y mejorado en gran medida
Se mejoró -r/--replace para que sea compatible con --json
Se mejoró el autocompletado de fish shell para que refleje el archivo de configuración de ripgrep
Se agregó italic a los atributos de estilo disponibles para --color
El directorio .jj ahora se trata como un repositorio git
Al usar multithreading, se agregó una función para programar la búsqueda siguiendo el orden de los archivos especificado en el CLI
Se agregaron artefactos de release aarch64 para Windows
Se agregó el tipo de color highlight, que permite aplicar estilo al texto no coincidente en líneas con coincidencias
Se agregó la función de alternativas anidadas en globs y en el crate globset
Se mejoró el autocompletado de --hyperlink-format en bash, fish y zsh

1 comentarios

GN⁺ 2025-10-19

Opiniones en Hacker News

ripgrep es una herramienta que de verdad me ha ahorrado muchísimo tiempo durante los últimos años; es de las primeras cosas que instalo cada vez que empiezo en un sistema nuevo, y es indispensable sobre todo al explorar bases de código antiguas. Lo único que me decepciona un poco es que, al usar la opción -F (tratar como literal), todavía hay algunos caracteres que se siguen tratando como especiales y requieren escape. No recuerdo exactamente cuáles eran, pero aun así me alegra cada vez que veo que ripgrep sigue actualizándose.
- Si das un ejemplo de qué carácter te causó problemas, puedo explicarlo con más detalle. -F/--fixed-strings desactiva al 100% las funciones de expresiones regulares en el patrón y lo trata solo como literal. Si hace falta escapar algo, probablemente se deba a que el shell lo exige.
rg es una herramienta que se siente casi como magia. En realidad, es el resultado de una ingeniería sobresaliente, mejoras constantes y de aprovechar al máximo el increíble rendimiento del hardware que todos usamos a diario. Además, es una innovación que abrió la puerta para que los desarrolladores puedan explorar y entender código más rápido, sin necesidad de crear por separado estándares como LSP.
- De verdad me intriga qué significa smithing en este contexto.
El codebase de ripgrep es el mejor ejemplo de "prepárate una bebida, siéntate en tu silla más cómoda y ponte a leer software de alta calidad". Uno se pone a hacer clic por todos los rincones del código y no deja de admirarlo.
- Esta entrada de blog también es una lectura excelente.
Igual que fd, rg es una herramienta de línea de comandos que da gusto usar. Me encantan este tipo de herramientas nuevas basadas en comandos.
- Hace poco me enteré de que los autores de ripgrep y fd trabajan en Astral. Con razón el software de Astral es tan bueno.
- Ambas herramientas funcionan por defecto exactamente como quiero el 99% de las veces, sin necesidad de opciones especiales. Ahorran muchísimo tiempo. Por ejemplo, muchas veces basta con escribir rg <string> o fd <string>.
Una función que personalmente me gustaría que añadieran es un flag de "extensión", que funcione como -g pero tratando los argumentos de entrada como extensiones (por ejemplo, algo como rg -e c,h). La mayoría de las veces que uso patrones glob, en realidad lo que quiero es hacer match por extensión.
- Me pregunto si ya viste el flag -t/--type; en un caso como tu ejemplo se puede usar como -tc. Si ripgrep no trae esa extensión, también puedes definir tu propio type.
ripgrep fue una de las razones principales por las que empecé a interesarme en Rust. Funciona con un nivel de pulido tan alto que me dio aún más curiosidad saber que estaba hecho en Rust. Incluso ahora, años después, sigo usando rg todos los días.
- nibbles fue la razón principal por la que me interesé en qbasic. Estaba tan bien hecho que me llamó la atención que estuviera escrito en qbasic, y gracias a eso terminé usando nibbles todos los días.
Hace poco descubrí la opción --replace y me impresionó bastante. La he estado usando junto con --type, y me dio un poco de pena no haber sabido antes que existían funciones tan buenas. De ahora en adelante pienso leer las release notes con más cuidado y estar más atento a las novedades. También me alegra la mejora de integración con jj.
Es una gran herramienta y además muy fácil de usar. Empecé usándola en Linux, pero ahora también la uso en Windows. Gracias a esta herramienta, ahora aplico expresiones regulares directamente en las búsquedas en vez de usar wildcards.
- Es mejor que grep básico, y el comando rg --files también es útil.
Esta semana hice una función de bash para ejecutar ripgrep solo sobre archivos rastreados por git.
```
  rgg() {
    readarray -d '' -t FILES < <(git ls-files -z)
    rg "${@}" "${FILES[@]}"
  }
```
En directorios con muchos archivos binarios o archivos dot, permite buscar mucho más rápido. Para buscar en archivos dot hace falta la opción -uu, pero esa opción también termina buscando en archivos binarios. Cuando hay cientos de archivos, git ls-files en sí mismo se vuelve lento.
- Me da curiosidad si tienes un ejemplo concreto donde hacerlo así haya sido más rápido. En general, ripgrep ya respeta las reglas de gitignore, así que se comporta de forma parecida a git ls-files. Como referencia, -uu le dice a ripgrep que ignore gitignore y los archivos ocultos, pero aun así sigue saltándose los archivos binarios. Para incluir también binarios hace falta -uuu. El mayor problema de tu función es que, si la usas en el repo del kernel de Linux, aparece el error de que la lista de argumentos es demasiado larga. Por eso lo cambié a xargs.
```
  $ 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
```
  Si tienes un ejemplo donde git ls-files -z | xargs -0 rg ... sea más rápido que simplemente rg ..., compártelo por favor.
- Después de escribir esto, volví a leer el manual y me di cuenta de que se puede usar el flag -. en lugar de -uu para buscar solo en archivos ocultos. Estaría bien poder buscar en archivos ocultos rastreados por git, pero el overhead de consultar la lista de archivos no es tan despreciable como para ignorarlo, incluso estando implementado en Rust.
- No sé si se me está escapando algo, pero ¿ripgrep no ignora por defecto los archivos que no están rastreados por git?
- Me pregunto si este enfoque es más rápido que git grep.
Uso ripgrep todos los días en el trabajo, tanto en la línea de comandos como al buscar desde vscode. Siempre lo uso. Gracias a burntsushi.