Eso es justo lo que cat fue hecho para. Dado que es una de las herramientas GNU más antiguas, creo que es muy poco probable que otra herramienta lo haga mejor o más rápido. Y no es tubería - solo está redirigiendo la salida.
Bajo el capó
No existe una forma más eficiente que copiar el primer archivo, luego copiar el segundo archivo después, y así sucesivamente. Ambos DOS copy y cat haz eso.
Cada archivo se almacena independientemente de otros archivos en el disco. Casi todos los sistemas de archivos diseñados para almacenar datos en un dispositivo similar a un disco funcionan por bloques. He aquí una presentación muy simplificada de lo que sucede:el disco se divide en bloques de, digamos, 1kB, y para cada archivo el sistema operativo almacena la lista de bloques que lo componen. La mayoría de los archivos no tienen un número entero de bloques, por lo que el último bloque solo está parcialmente ocupado. En la práctica, los sistemas de archivos tienen muchas optimizaciones, como compartir el último bloque parcial entre varios archivos o almacenar "bloques 46798 a 47913" en lugar de "bloque 46798, bloque 46799,...". Cuando el sistema operativo necesita crear un nuevo archivo, busca bloques libres. Los bloques no tienen que ser consecutivos:si solo los bloques 4, 5, 98 y 178 están libres, aún puede almacenar un archivo de 4kB. El uso de bloques en lugar de bajar al nivel de bytes ayuda a encontrar bloques libres para un archivo nuevo o en crecimiento considerablemente más rápido, y reduce los problemas debidos a la fragmentación cuando crea o aumenta y elimina o reduce una gran cantidad de archivos (dejando un número cada vez mayor de archivos). agujeros).
Podría admitir bloques parciales en medio del archivo, pero eso agregaría una complejidad considerable, especialmente al acceder a archivos de forma no secuencial:para saltar al byte 10340, ya no podría saltar al byte 100 del bloque 11, tendría que para verificar la longitud de cada bloque intermedio.
Dado el uso de bloques, no puede simplemente unir dos archivos, porque en general el primer archivo termina a la mitad del bloque. Claro, podría tener un caso especial, pero solo si desea eliminar ambos archivos al concatenar. Eso sería un manejo muy específico para una operación rara. Tal manejo especial no vive por sí solo, porque en un sistema de archivos típico, se accede a muchos archivos al mismo tiempo. Entonces, si desea agregar una optimización, debe pensar detenidamente:¿qué sucede si algún otro proceso está leyendo uno de los archivos involucrados? ¿Qué sucede si alguien intenta concatenar A y B mientras alguien está concatenando A y C? Y así. Con todo, esta rara optimización sería una gran carga.
En general, no puede hacer que unir archivos sea más eficiente sin hacer grandes sacrificios en otros lugares. No vale la pena.
Sobre dividir y unir
split y cat son formas sencillas de dividir y unir archivos. split se encarga de producir archivos nombrados en orden alfabético, de modo que cat * funciona para unirse.
Una desventaja de cat para unirse es que no es robusto contra los modos de falla comunes. Si uno de los archivos está truncado o falta, cat no se quejará, solo obtendrá una salida dañada.
Existen utilidades de compresión que producen archivos de varias partes, como zipsplit y rar -v . No son muy unixy, porque comprimen y empaquetan (ensamblan varios archivos en uno) además de dividir (y por el contrario descomprimen y descomprimen además de unir). Pero son útiles porque verifican que tiene todas las piezas y que las piezas están completas.
Parece que debería haber una forma más eficiente que canalizar todo el contenido a través del stdin del sistema. / stdout
Excepto que eso no es realmente lo que está sucediendo. El shell está conectando la salida estándar de cat directamente al archivo abierto, lo que significa que "pasar por la salida estándar" es lo mismo que escribir en el disco.