Por que cat x >> x loop?

Os seguintes comandos bash entram em um loop infinte:

$ echo hi > x
$ cat x >> x

Eu acho que isso catcontinua a ser lido xdepois que ele começou a escrever no stdout. O que é confuso, no entanto, é que minha própria implementação de teste de gato exibe um comportamento 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;
}

Se eu correr:

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

Ele faz não loop. Dado o comportamento cate o fato de que eu estou liberando para o stdoutanterior freadé chamado novamente, eu esperaria que esse código C continuasse lendo e gravando em um ciclo.

Como esses dois comportamentos são consistentes? Que mecanismo explica por que faz um catloop enquanto o código acima não funciona?

Em um sistema RHEL mais antigo que eu tenho, não/bin/cat faz loop para . dá a mensagem de erro "cat: x: arquivo de entrada é arquivo de saída". I pode enganar , fazendo isso: . Quando tento seu código acima, recebo o "loop" que você descreve. Também escrevi um "gato" baseado em chamada de sistema:cat x >> xcat/bin/catcat < x >> x

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

Isso dá laços também. O único buffer aqui (ao contrário do "mycat" baseado em stdio) é o que acontece no kernel.

Acho que o que está acontecendo é que o descritor de arquivo 3 (o resultado de open(av[1])) tem um deslocamento no arquivo de 0. O descritor arquivado 1 (stdout) tem um deslocamento de 3, porque o ">>" faz com que o shell de chamada faça um lseek()no descritor de arquivo antes de entregá-lo ao catprocesso filho.

Executar read()qualquer tipo, seja em um buffer stdio ou em uma planilha, char buf[]avança a posição do descritor de arquivo 3. Executar a write()avança a posição do descritor de arquivo 1. Esses dois deslocamentos são números diferentes. Por causa do ">>", o descritor de arquivo 1 sempre tem um deslocamento maior ou igual ao deslocamento do descritor de arquivo 3. Portanto, qualquer programa "semelhante a um gato" fará um loop, a menos que faça algum buffer interno. É possível, talvez até provável, que uma implementação stdio de a FILE *(que é o tipo dos símbolos stdoute fno seu código) inclua seu próprio buffer. fread()pode realmente fazer uma chamada do sistema read()para preencher o buffer interno fo f. Isso pode ou não mudar nada no interior de stdout. chamando fwrite()emstdoutpode ou não alterar nada dentro de f. Portanto, um "gato" baseado em stdio pode não ser repetido. Ou pode. Difícil dizer sem ler muitos códigos libc feios e feios.

Eu fiz uma straceno RHEL cat- ele só faz uma sucessão de read()e write()chamadas do sistema. Mas a catnão precisa funcionar dessa maneira. Seria possível para mmap()o arquivo de entrada, então faça write(1, mapped_address, input_file_size). O kernel faria todo o trabalho. Ou você pode fazer uma sendfile()chamada do sistema entre os descritores de arquivo de entrada e saída nos sistemas Linux. Dizia-se que os antigos sistemas SunOS 4.x faziam o truque de mapeamento de memória, mas não sei se alguém já fez um gato baseado em arquivo de envio. Em ambos os casos, o "loop" não aconteceria, pois ambos write()e sendfile()requerem um parâmetro de comprimento para transferir.

Uma implementação moderna de gato (sunos-4.0 1988) usa mmap () para mapear o arquivo inteiro e depois chama 1x write () para esse espaço. Essa implementação não será executada enquanto a memória virtual permitir mapear o arquivo inteiro.

Para outras implementações, depende se o arquivo é maior que o buffer de E / S.

Conforme escrito nas armadilhas do Bash , você não pode ler um arquivo e gravá-lo no mesmo pipeline.

Dependendo do que o seu pipeline faz, o arquivo pode ter um atrito (para 0 bytes ou possivelmente para um número de bytes igual ao tamanho do buffer de pipeline do sistema operacional) ou pode crescer até preencher o espaço em disco disponível ou atingir a limitação do tamanho do arquivo do seu sistema operacional, sua cota etc.

A solução é usar o editor de texto ou variável temporária.

Você tem algum tipo de condição de corrida entre os dois x. Algumas implementações de cat(por exemplo, coreutils 8.23) proíbem que:

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

Se isso não for detectado, o comportamento obviamente dependerá da implementação (tamanho do buffer, etc.).

No seu código, você pode tentar adicionar um clearerr(f);após o fflush, caso o próximo freadretorne um erro se o indicador de fim de arquivo estiver definido.