Búsqueda de ficheros. Terminal, ls y tree

En ocasiones es necesario encontrar ficheros que hemos utilizado -o no- en el pasado y que tenemos almacenados en el disco duro. Muchos años atras, cuando el disco duro tenía 40 MB y había 10 usuarios por ordenador los ficheros se guardaban en disquetes y eran fáciles de encontrar, pero hoy, con discos de hasta 4 TB, la información se almacena el disco duro y, con suerte, en una copia externa en otro disco duro. Este sistema nuevo de manejar la información nos pone ante discos duros con cientos de miles de ficheros en decenas de miles de directorios. Incluso el almacenamiento en la nube está saturado de decenas de miles. Como ejemplo, mi Dropbox, que tiene solo lo que estoy usando actualmente para trabajar ha llegado a 23 GB y decenas de miles de ficheros; véase

y el directorio de usuario tiene más de medio millón de ficheros

Por supuesto, cuando es necesario encontrar algún fichero de los trabajos de hace 20 años, o incluso 8, como me ha pasado a mi la semana pasada, a veces los ficheros no se encuentran fácilmente, bien por que ahora usamos una lógica distinta a la que usábamos antes para los nombres de los directorios o de los ficheros o por que los hemos recolocado una y otra vez a lo largo de los años. He estado toda la semana encontrando una solución en terminal, partiendo de una orden ls general, que luego tunelizaba hasta un filtro grep basándome con un pequeño grupo de caracteres que debieran estar en el nombre de esos ficheros.
Para verlo pondremos un ejemplo, partiendo de los ficheros CR2 que hemos estado utilizando para la entrada anterior; si tecleamos

ls -Rla | grep CR2

obtenemos lo siguiente,

Vemos los ficheros, pero no sabemos donde están. Cada letra de las opciones son para algo
R - orden recursiva. Así, mira todos los subdirectorios del directorio donde la hemos lanzado (en est aso, el home de usuario (más de 50.000 directorios y 600.000 ficheros)
l - nos da información de los permisos, el propietario y grupo del fichero, los inodos, su tamaño y nombre; sin embargo, no nos da la ruta absoluta
a - muestra todos los ficheros y directorios, incluidos los ocultos

Eso nos deja con la tranquilidad de ver que están, pero sin saber exactamente donde. Para ello debemos usar el comando tree (como muy amablemente me indicó ayer mi amigo hckorootx). Si ejecutamos

tree -afiR $PWD | grep CR2

obtenemos lo que queríamos, la ruta completa a los ficheros

Las opciones incluidas son:
a -  de nuevo incluye los ficheros ocultos
f - está es la opción que nos transmite las rutas completas de los ficheros
i - evita que la ruta quede dibujada en líneas de indentación de los directorios, que es difícil de leer
R - búsqueda recursiva en todos lo subdirectorios

Si no incluimos $pwd, obtenemos la ruta a partir del directorio base del usuario que ha ejecutado

Eso sí,Linux diferencia mayúsculas de minúsculas, así que si hubieramos pedido

tree -afiR $PWD | grep cr2

hubiera salido otra cosa

Para evitar eso, y teniendo enuenta que s muy difícil recordar que tipo de letra usábamos hace tiempo (y sobre todo en windows, que no diferencia mayúsculas y minúsculas), debemos incluir la opción -i en el filtrado realizado por grep


tree -afiR $PWD | grep -i cr2

Perfecto.

Lectura de ficheros con formato CHM en Linux

He tenido la necesidad de leer un fichero chm (ficheros de ayuda HTML compilados de Microsoft), que presentan siempre ciertas dificultades. Evince no los lee, y okular suele montar los párrafos entre si, con lo que se hace muy incómodo, aparte de que descoloca las tablas. Lo mejor, por supuesto, es disponer de un fichero con formato abierto, pero no siempre es posible y a veces los datos que necesitamos para hacer funcionar una máquina o un algoritmo está en ficheros chm. Buscando ayuda de nuestro gran amigo Internet, en esta página de linux.com dan varias aplicaciones que podemos utilizar. Me he centrado en dos:
1. KchmViewer - como la k indica, utiliza librerías qt y está integrada en el escritorio kde. Como tengo las librerías -uso k3b a veces- lo he probado.
2. ChmSee - a pesar de los defectos que señalan en la página de linux.com, realmente esta es una versión muy evolucionada y funciona muy bien.

Cualquiera de los dos han cubierto mis necesidades perfectamente y tienen una apariencia similar, con la apariencia de aplicaciones de KDE en kchmviewer y la visión más espartana de gnome en el otro.

Realmente, la razón para elegir es más el escritorio que estemos utilizando que otras características, ya que las dos funcionan adecuadamente. A vuestro gusto. Me ha faltado por probar GnoCHM, pero ya había cubierto mis necesidades.

Cheese, fotos en ráfaga y conversión a vídeo

He logrado, o mejor debemos decir hemos logrado, por que he tenido ayuda "experta", superar algunas de las dificultades del uso de cheese que decíamos aquí. En primer lugar, el apagado del monitor ha sido bastante simple, ejecutando estas ordenes:
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
tomadas de aquí.
Sin embargo, han aperecido otras dificultades. Cheese, además de limitarse a 10.000 imágenes, ha presentado otra dificultad; guarda los ficheros con unos nombres que dificultan la conversión a vídeo. Los ficheros, para poner un ejemplo, tienen unos nombres que muestran un cuerpo inicial común formado de la fecha de inicio y la hora, minutos y segundos de comienzo:
- Primero: 2012-02-17-173235_1.jpg
- Último: 2012-02-17-173235_10000.jpg
Luego se numeran desde el 1 en adelante, pero sin mantener un número común de caracteres. Esa falta de ceros a la izquierda de los números hace que el ordenador, y los programas que generan el vídeo desde las imágenes, los ordenen de manera equivocada, siendo por ejemplo el último el 2012-02-17-173235_9.jpg. Así, cada determinado número de frames hay una imágen equivocada que genera bastantes molestias.
Por suerte mi amigo hckorootx generó unos scripts para cambiar en masa el nombre de los ficheros, como podemos ver en los comentarios de esta entrada. En concreto, este script funcionó perfectamente (muchas gracias, hckorootx):

#!/bin/bash
for archivo in *.jpg; do
long_total=`expr length $archivo`
long_util=`expr $long_total - 18`
nombre_inutil=`expr substr $archivo 1 18`
nombre_util=`expr substr $archivo 19 $long_util`
if [ $long_util -eq 5 ]; then
ceros="0000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 6 ]; then
ceros="000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 7 ]; then
ceros="00"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 8 ]; then
ceros="0"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
fi
done

Además, como se ve es muy explicativa por si misma. Menos mal, por que yo de script en bash no tengo ni idea, y eran casi 40.000 ficheros en 6 tandadas los que había que renombrar.
Una vez convertidos adecuadamente desde el primero 2012-02-17-173235_00001.jpg hasta el último 2012-02-17-173235_10000.jpg, ya solo quedaba dar una orden de conversión. Después de haber pensado en usar openshot, decidí usar directamente mencoder, por que el terminal es siempre más rápido.
Con esta orden,

$ mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4

que tendré que pulir leyendo más profundamente las guías modernas de mencoder, me salió un conjunto de vídeos de los que cortando trozos y pegando con VirtualDubMod a través de wine logré un total de 4minutos y 12 segundos bastante buenos (me ha felicitado mucha gente), a partir de algo más de 6300 imágenes del total de 40.000.
No, no enseñaremos aquí el vídeo, por que es un objeto científico, y hasta que sea publicado los científicos no compartimos nada de nada. Después de publicarlos los derechos dejan de ser nuestros y ya no podemos disponer de nuestros hallazgos para difundirlos y hay que pedírselos a editoriales como Elsevier, Springer y otras similares. Si me dejan ponerlo en Youtube, según el uso al que esté destinado, lo pondré también aquí, pero no prometo nada.
El siguiente paso sería aprender lo suficiente de motion para poder evitar esa limitación de 10.000 imágenes de cheese... pero esa será otra historia

Ficheros duplicados: fslint

En las últimas semanas he estado actualizando todos mis ordenadores a Ubuntu 10.10; solo me falta el principal de casa, por así decir, el más importante, el que tiene todo el trabajo guardado. Y digo todo, desde 1990. El conjunto de directorios en los que guardo copia de todo desde mis inicios en los ordenadores ocupa... 300GB de material, sin musica y películas, solo trabajo. Mucho material tenía que estar almacenado dos o tres veces, ya que por mi tipo de trabajo no sería normal acumular tanto volumen. Antes de pasarme a 10.10 decidí hacer una copia de seguridad en un dispositivo externo, pero esta vez más selectiva, eliminando al menos parte del material duplicado. En Linux, despues de revisar la red, encontré una utilidad adecuada a ello, fslint. Lo instalé en terminal (se puede instalar en Synaptic; está en los repositorios de Ubuntu):

$ sudo apt-get install fslint

El icono del programa aparece en Aplicaciones, Herramientas del sistema
pero se puede llamar también desde terminal fslint-gui, que como su nombre indica es una máscara gráfica que facilita su uso:

luego se selecciona el/los directorios a explorar y se le da la orden de búsqueda; tras un rato largo, sale una lista con los ficheros duplicados. De los más de 300.000 ficheros que llevo acumulados, alguno estaba repetido hasta 28 VECES. Solo trabajando un rato eliminé 50GB de información redundante. Seguiré en ello, por que solo me fijé en los más repetidos, pero aun hay mucho que eliminar. Una maravilla fslint y muy poco organizado yo, aunque los tengo visto peores. Aprovechando el momento eliminé cientos de utilidades que guardaba desde hace mucho tiempo para MS-DOS y Windows, ya que no suelo visitar esos mundos perdidos, y con ello liberé aun más espacio del disco principal. Cuando trabajaba con Windows llegue a usar 3 discos en cada ordenador, pero ahora con Linux suelo usar uno o dos y separo por particiones al menos home, donde voy almacenando las cosas.

Hacha o cat, segunda parte. Una mala memoria

Ayer me encontré con un pequeño "problema". Al bajar unos ficheros resulta que llegan como fichero.avi.1, fichero.avi.2 hasta cuatro y por lo visto tenía que unirlos con hacha. Conservo de aquellos tiempos remotos de windows un Hacha, pero al intentar usarlo a través de Wine de cuelga en el primer fichero y no responde. Ante las dudas pedí rápidamente el comodín del público (Google) donde unos mencionan Halle, el hacha de Linux; otros Hoz, el hacha de Linux. Ante tanta duda alguien nos recordó la maravilla de split/cat, y así, directamente con cat pudimos unir tales ficheros, como ya sabíamos, o debíamos saber. Como se ve perfectamente en VCL, deben haber sido partidos por Hacha v1.x, pero esto nos dice que, en general, Linux por si mismo tiene soluciones para casi todo; lo malo es que no siempre nos acordamos.

Documentos PDB; un formato más

Tenía la necesidad de un documento en particular, y buscando en la red encontré varios ficheros de diferentes tamaños, pero ninguno era exactamente el que quería. Finalmente encontré uno con formato PDB que según la descripción era exactamente el que quería, pero no era capaz de abrirlo o leerlo. En diferentes blogs encontré diferentes recomendaciones y las fui intentando una a una, de más a menos cómoda. El primer intento fue con ABIWORD; en teoría debería ser posible, según diferentes usuarios, pero al menos a mi no me funcionó; el segundo intento fue con calibre y luego fbreader –(recomendado en particular por algunos para este tipo de ficheros Palm, pero tampoco funcionaron. Finalmente recurrí a la penúltima opción (la última sería recurrir a la máquina virtual con Windows) instalando iSilo (versión Windows, que para Linux no hay) a través de WINE. Con el fui capaz de estraer un fichero txt completo y poder introducirlo en AbiWord (Writer me generaba algunos caracteres extraños) y poder exportarlo a PDF, que luego convertiré a MOBI con Calibre para poder usarlo en el Kindle. Llevó un cierto tiempo, por que el documento terminó teniendo más de 1400 páginas, pero ya lo tengo preparado. De todas formas, cuanta complicación para obtener un texto, cuantos formatos de más hay, y total, para nada. ¿Realmente es necesario tanto formato propietario? Cuantas ganas de fastidiar a los usuarios de electrónica.

División y unión de ficheros grandes

Recuerdo una época en que usaba Hacha en Windows para dividir ficheros en "trocitos" pequeños para poder moverlos entre ordenadores, y luego los volvíamos a "pegar". También usé compresores para dividir en trozos. Todo ello está incluido en Linux sin necesidad de nada añadido. Acabo de leer aquí esta maravilla.


"La manera más cómoda para mi ha sido utilizar 2 comandos fabulosos. Imaginemos que tenemos un archivo de 800 MB que se llama pelicula.avi y queremos cortar este archivo en pedazos de 100MB cada uno, pues solamente tecleamos:

split -b100m pelicula.avi pelicula_pedazos.@

esto nos va a crear pedazos de 100MB con el nombre pelicula_pedazos y que después pegaríamos con este otro comando:

cat pelicula_pedazos.* > pelicula_pegada.avi@

Con esto nos genera un archivo con la suma de todas las partes llamado pelicula_pegada.avi

Nota: El tamaño indíca los bytes con letras: b para 512, k para 1k, m para 1 Mega"

Quien necesita más utilidades teniendo Linux. Lo que hace falta es saber mucho, lo que es más difícil (menos mal que algunos saben más y nos lo escriben en los blogs)