¿Por qué cat x >> x loop?

Los siguientes comandos bash entran en un bucle infinito:

$ echo hi > x
$ cat x >> x

Puedo adivinar que catcontinúa leyendo xdespués de que comenzó a escribir en stdout. Sin embargo, lo que es confuso es que mi propia implementación de prueba de cat exhibe un comportamiento diferente:

// mycat.c
#include <stdio.h>

int main(int argc, char **argv) {
  FILE *f = fopen(argv[1], "rb");
  char buf[4096];
  int num_read;
  while ((num_read = fread(buf, 1, 4096, f))) {
    fwrite(buf, 1, num_read, stdout);
    fflush(stdout);
  }

  return 0;
}

Si corro:

$ make mycat
$ echo hi > x
$ ./mycat x >> x

Lo hace no lazo. Dado el comportamiento caty el hecho de que me estoy volviendo loco stdoutantes fread, se espera que este código C continúe leyendo y escribiendo en un ciclo.

¿Cómo son consistentes estos dos comportamientos? ¿Qué mecanismo explica por qué se catrepite mientras que el código anterior no lo hace?

En un sistema más antiguo RHEL lo que tengo, /bin/catlo hace no lazo para cat x >> x. catda el mensaje de error "cat: x: el archivo de entrada es el archivo de salida". Puedo engañar /bin/catal hacer esto: cat < x >> x. Cuando pruebo su código anterior, obtengo el "bucle" que describe. También escribí una llamada al sistema basada en "cat":

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int
main(int ac, char **av)
{
        char buf[4906];
        int fd, cc;
        fd = open(av[1], O_RDONLY);
        while ((cc = read(fd, buf, sizeof(buf))) > 0)
                if (cc > 0) write(1, buf, cc);
        close(fd);
        return 0;
}

Esto también se repite. El único búfer aquí (a diferencia de "mycat" basado en stdio) es lo que sucede en el núcleo.

Creo que lo que está sucediendo es que el descriptor de archivo 3 (el resultado de open(av[1])) tiene un desplazamiento dentro del fichero de 0. 1 Filed descriptor (stdout) cuenta con un desplazamiento de 3, debido a que el ">>" hace que el shell que invoca a hacer una lseek()en el descriptor de archivo antes de entregarlo al catproceso secundario.

Hacer una read()de cualquier tipo, ya sea en un búfer stdio o en un plano, char buf[]avanza la posición del descriptor de archivo 3. Hacer un write()avance de la posición del descriptor de archivo 1. Esos dos desplazamientos son números diferentes. Debido al ">>", el descriptor de archivo 1 siempre tiene un desplazamiento mayor o igual que el desplazamiento del descriptor de archivo 3. Por lo tanto, cualquier programa "similar a un gato" se repetirá, a menos que haga un búfer interno. Es posible, incluso probable, que una implementación estándar de un FILE *(que es el tipo de símbolos stdouty fen su código) que incluya su propio búfer. fread()en realidad puede hacer una llamada read()al sistema para llenar el búfer interno fo f. Esto puede o no cambiar nada en el interior de stdout. llamando fwrite()enstdoutpuede o no cambiar nada en el interior de f. Por lo tanto, un "gato" basado en stdio podría no repetirse. O que podría hacerlo. Difícil de decir sin leer un montón de código libc feo y feo.

Hice una straceen la RHEL cat- sólo se hace una sucesión de read()y write()llamadas al sistema. Pero a catno tiene que funcionar de esta manera. Sería posible mmap()ingresar el archivo, luego hacer write(1, mapped_address, input_file_size). El núcleo haría todo el trabajo. O puede hacer una sendfile()llamada al sistema entre los descriptores de los archivos de entrada y salida en los sistemas Linux. Se rumoreaba que los viejos sistemas SunOS 4.x hacían el truco de mapeo de memoria, pero no sé si alguien había hecho un gato basado en sendfile. En cualquier caso, el "bucle" sería no ocurrir, ya que tanto write()y sendfile()requerir un parámetro de longitud a transferencia.

Una implementación cat moderna (sunos-4.0 1988) usa mmap () para mapear todo el archivo y luego llama a 1x write () para este espacio. Dicha implementación no se repetirá mientras la memoria virtual permita mapear todo el archivo.

Para otras implementaciones, depende de si el archivo es más grande que el búfer de E / S.

Como está escrito en las trampas de Bash , no puede leer un archivo y escribir en él en la misma tubería.

Dependiendo de lo que haga su canalización, el archivo puede estar bloqueado (a 0 bytes, o posiblemente a un número de bytes igual al tamaño del búfer de canalización de su sistema operativo), o puede crecer hasta que llene el espacio disponible en disco, o alcance la limitación de tamaño de archivo de su sistema operativo, o su cuota, etc.

La solución es usar un editor de texto o una variable temporal.

Tienes algún tipo de condición de carrera entre ambos x. Algunas implementaciones de cat(por ejemplo, coreutils 8.23) prohíben que:

$ cat x >> x
cat: x: input file is output file

Si esto no se detecta, el comportamiento obviamente dependerá de la implementación (tamaño del búfer, etc.).

En su código, puede intentar agregar un clearerr(f);después de fflush, en caso de que el siguiente freaddevuelva un error si se establece el indicador de fin de archivo.