Práctica funcionalidad de BASH: sustitución de procesos [ENG]

Hace algún tiempo me surgió un problema en el trabajo donde tenía que comparar dos archivos descargados. La solución fue simple: descargar el primero archivo, descargar el segundo para finalmente ejecutar un diff entre ellos. Tres pasos: curl URL1 > file1; curl URL2 > file2; diff file1 file2. Pero antes de poder teclearlo, un compañero me quitó el teclado y escribió un raro código vudú que nunca había visto: diff <(curl URL1) <(curl URL2). ¿Qué rara sintaxis era esa? Más aún, ¿por qué iba el doble de rápido que mi solución?

[#3 skaworld]

"Pretty much everything useful I ever learned about UNIX shells was not from reading books or manuals, but by peering over someone’s shoulder and seeing something I’d never seen before. “Ooooh, what was that you just did?”"

Cuanta puta razón

[#8 Desactivado]

#3 Como todo el mundo que trabaje con sistemas Unix o "Unix", realmente

[#1 Desactivado]

¿por qué iba el doble de rápido que mi solución?
Pues porque no estás accediendo al sistema de archivos. Todo se hace en memoria y quién sabe si bash optimiza y mantiene una sección de memoria compartida.

[#2 Desactivado]

#1 No parece que esta solución cargue nada en memoria, en realidad, más allá de lo que carga la solución "normal" que iba a hacer el colega (el diff, cargando los dos ficheros es lo único que de carga en memoria en ambos casos, eso no cambia).

Accede también al sistema de archivos, puesto que lo que hace es crear dos descriptores de fichero Unix, uno para cada fichero descargado, y hacer que diff lea de esos descriptores como si fuesen ficheros de texto.

Va más rápido porque paraleliza las descargas de los dos ficheros a comparar, haciendo que se descarguen los dos a la vez al mismo tiempo que diff se abre y empieza a leer de los dos descriptores de fichero, en cada uno de los cuales se está volcando el flujo de datos.

En la solución "normal" que se plantea al principio, todo edo ocurre de manera secuencial.

[#4 Desactivado]

#2
Es bastante obvio lo que he dicho en mi mensaje, que es lo mismo que tu has dicho.

[#5 Desactivado]

#4 Ni de lejos (con cariño)

[#6 Desactivado]

#5
Si entendemos sistema de archivos como escritura a disco, sí.
Si entendemos optimizaciones como la no realización de operaciones innecesarias, también.
(Sin sarcasmo).

[#7 Desactivado]

#4 No creo entonces que hayas entendido mi explicación. Sin acritú lo digo, eh

[#9 Desactivado]

#7
Si vas a base de creencias es normal que no entiendas ni «j».

[#10 Desactivado]

#9 Pues venga makina, que tengas buen finde.

[#11 Desactivado]

#10
Ok.

[#16 Black_Diamond]

#2 También va más rápido porque en cuanto diff encuentre una diferencia (y eso puede ser el primer byte de un fichero muy largo) va a cerrar los "ficheros de entrada", y seguramente bash va a cancelar ambas descargas.

[#12 Aitor]

#1 Sí que estás accediendo al sistema de ficheros, estás almacenando cada descarga en un temporal. La clave de la rapidez en este caso es que realiza las dos descargas de forma paralela, cosa que sabrías si lo hubieras leído.

[#13 Desactivado]

#12
Eso es lo que he dicho.
No accede a disco para escritura, realiza todas las operaciones en memoria. Tampoco hace forks de procesos innecesarios.
Y por último, se crean los dos procesos de descarga curl al mismo tiempo.

[#14 Desactivado]

#13
Y nótese que digo creación de procesos curl al mismo tiempo, no lectura, puesto que la lectura de su salida es secuencial (diff no es multihilo), aunque comienza de manera inmediata sin esperar a que terminen los procesos curl., a diferencia de su ejecución secuencial.

[#15 Bourée]

Muy instructivos los comentarios ya que no sé inglés y soy usuario y defensor del software libre ( sin inglés es jodido pero voy tirando ) lo que no comparto son los votos negativos a@federico_gimeno. Un cordial saludo.