Ranger: «Too many files: Disabling open_all_images temporarily»

Utilizo ranger junto con nsxiv. Ranger tiene una opción open_all_images en rc.conf:

# .config/ranger/rc.conf
# Open all images in this directory when running certain image viewers
# like feh or sxiv?  You can still open selected files by marking them.
set open_all_images true 

Con esta opción, Ranger abre en nsxiv la imagen resaltada en el cursor, pero envía además todas las demás imágenes del directorio. De esta manera, al pulsar atrás/adelante en nsxiv veremos las imágenes en el mismo orden en el que las presenta ranger. Ese orden puede ser alfabético, por fecha de modificación, sólo imágenes seleccionadas con la tecla espacio…

Hace unos días me saltó el error mostrado en el título. En mi directorio de imágenes lo único que había cambiado era su cuantía: 1753. No son muchos pero la mayoría son imágenes de danbooru.donmai.us, con esta estructura:

__akebi_komichi_akebi_chan_no_serafuku_drawn_by_anno_masato__f6eede4403c829a33cd5d0e1c7247545.jpg

Esto es el nombre del personaje + nombre de la serie + dibujante + hash MD5. Me gusta ese detallismo, pero al pasar muchas imágenes con ese tipo de nombre, puede que lleguemos al la longitud máxima de argumentos:

https://github.com/ranger/ranger/pull/1490

Como explica ahí, el error que devuelve Linux a ranger es «Argument list too long», errno 7. La variable que establece el límite es ARG_MAX. Evidentemente, no quería recompilar el kernel sólo para solventar esta tontería… la alternativa que encontré es este pequeño script: nsxiv-rifle. Está basado en sxiv-rifle. Busca la lista de imágenes del directorio actual con find y se la pasa a nsxiv mediante fichero. Este método no presenta problemas de longitud. El inconveniente es que la ordenación no es la que muestra ranger, sino la que busca el comando find del script. En el README se explica cómo modificarlo para buscar por fecha de modificación descendiente, que es mi preferencia. Puesto que en otros directorios no tengo ni tantas imágenes, ni con nombres tan largos, prefiero que sea ranger el que pase las imágenes en esos casos. Para tener ambos comportamientos:

*1* He dejado igual la línea de

# .config/ranger/rifle.conf
mime ^image, has sxiv,      X, flag f = sxiv -- "$@"
# No poner mime ^image, has nsxiv, X, flag f = /usr/local/bin/nsxiv-rifle -- "$@"

NOTA: pone sxiv y no nsxiv porque ranger tiene hardcodeado internamente open_all_images a sxiv. Lo «engaño» poniendo:

# /usr/local/bin/sxiv
#!/bin/zsh
i3-swallow nsxiv -s f "$@"

*2* …y he dejado nsxiv mapeado a la tecla «i»:

# .config/ranger/rc.conf
map i open_with nsxiv-rifle f    # f hace "fork" del proceso

De esta manera, utilizo la tecla «i» en el directorio problemático, y «enter» en los demás directorios. Hay que tener cuidado de no usar «enter» en el directorio problemático.

*3* (opcional) modificar /usr/local/bin/nsxiv-rifle para que utilice i3-swallow:

[...]
if [ -n "$count" ]; then
    i3-swallow nsxiv -i -n "${count%%:*}" "$@" -- < "$tmp"
else
    # fallback incase file didn't have a valid extension, or we couldn't
    # find it inside the list
    i3-swallow nsxiv "$@" -- "$file"
fi
[...]

NOTA: Antes utilizaba esta configuración:

# .config/ranger/rc.conf
map i shell i3-swallow nsxiv-rifle %f

…pero al salir de nsxiv y volver a kitty, éste se colgaba. Ver aquí. Con open_with no he tenido este problema.