Pourquoi le chat x >> x fait-il une boucle?

Les commandes bash suivantes entrent dans une boucle infinie:

$ echo hi > x
$ cat x >> x

Je peux deviner que la catlecture continue xaprès avoir commencé à écrire sur stdout. Ce qui est déroutant, cependant, c'est que ma propre implémentation de test de cat présente un comportement différent:

// 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 je cours:

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

Il ne boucle pas . Étant donné le comportement de catet le fait que je vidais stdoutavant freadest appelé à nouveau, je m'attendrais à ce que ce code C continue à lire et à écrire dans un cycle.

Comment ces deux comportements sont-ils cohérents? Quel mécanisme explique pourquoi les catboucles alors que le code ci-dessus ne fonctionne pas?

Sur un ancien système RHEL que j'ai, /bin/catne fait pas de boucle cat x >> x. catdonne le message d'erreur "cat: x: le fichier d'entrée est le fichier de sortie". Je peux tromper /bin/caten faisant ceci: cat < x >> x. Lorsque j'essaie votre code ci-dessus, j'obtiens le "bouclage" que vous décrivez. J'ai également écrit un "chat" basé sur les appels système:

#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;
}

Cela boucle aussi. La seule mise en mémoire tampon ici (contrairement à "mycat" basé sur stdio) est ce qui se passe dans le noyau.

Je pense que ce qui se passe est que le descripteur de fichier 3 (le résultat de open(av[1])) a un décalage dans le fichier de 0. Le descripteur de fichier 1 (stdout) a un décalage de 3, car le ">>" fait que le shell appelant fait un lseek()sur le descripteur de fichier avant de le transmettre au catprocessus enfant.

Faire un read()de n'importe quelle sorte, que ce soit dans un tampon stdio ou un simple, char buf[]avance la position du descripteur de fichier 3. Faire un write()avance la position du descripteur de fichier 1. Ces deux décalages sont des nombres différents. En raison du ">>", le descripteur de fichier 1 a toujours un décalage supérieur ou égal à l'offset du descripteur de fichier 3. Ainsi, tout programme "semblable à un chat" bouclera, à moins qu'il ne fasse un tampon interne. Il est possible, voire probable, qu'une implémentation stdio d'un FILE *(qui est le type des symboles stdoutet fdans votre code) qui inclut son propre tampon. fread()peut en fait faire un appel système read()pour remplir le tampon interne fo f. Cela peut ou ne peut rien changer à l'intérieur de stdout. Appel fwrite()surstdoutpeut ou ne peut rien changer à l'intérieur de f. Un "chat" basé sur stdio peut donc ne pas boucler. Ou peut-être. Difficile à dire sans lire beaucoup de code libc laid et laid.

Je l' ai fait un stracesur la RHEL cat- il fait juste une succession de read()et write()appels système. Mais un catne doit pas fonctionner de cette façon. Il serait possible pour mmap()le fichier d'entrée, alors faites write(1, mapped_address, input_file_size). Le noyau ferait tout le travail. Ou vous pouvez faire un sendfile()appel système entre les descripteurs de fichiers d'entrée et de sortie sur les systèmes Linux. Les vieux systèmes SunOS 4.x étaient censés faire l'affaire de mappage de la mémoire, mais je ne sais pas si quelqu'un a déjà fait un chat basé sur sendfile. Dans les deux cas, le "bouclage" ne se produirait pas, car les deux write()et sendfile()nécessitent un paramètre de longueur à transférer.

Une implémentation de chat moderne (sunos-4.0 1988) utilise mmap () pour mapper le fichier entier, puis appelle 1x write () pour cet espace. Une telle implémentation ne boucle pas tant que la mémoire virtuelle permet de mapper le fichier entier.

Pour les autres implémentations, cela dépend si le fichier est plus grand que le tampon d'E / S.

Comme écrit dans les pièges de Bash , vous ne pouvez pas lire à partir d'un fichier et y écrire dans le même pipeline.

Selon ce que fait votre pipeline, le fichier peut être clobé (à 0 octet, ou éventuellement à un nombre d'octets égal à la taille de la mémoire tampon du pipeline de votre système d'exploitation), ou il peut augmenter jusqu'à ce qu'il remplisse l'espace disque disponible ou atteigne la limitation de la taille des fichiers de votre système d'exploitation, ou votre quota, etc.

La solution consiste à utiliser l'éditeur de texte ou une variable temporaire.

Vous avez une sorte de condition de concurrence entre les deux x. Certaines implémentations de cat(par exemple coreutils 8.23) interdisent que:

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

Si cela n'est pas détecté, le comportement dépendra évidemment de l'implémentation (taille du buffer, etc.).

Dans votre code, vous pouvez essayer d'ajouter un clearerr(f);après le fflush, au cas où le suivant freadretournerait une erreur si l'indicateur de fin de fichier est défini.