Чому цикл x >> x?

Наступні команди bash переходять у нескінченний цикл:

$ echo hi > x
$ cat x >> x

Я можу здогадатися, що catпродовжує читати з xтого часу, коли він почав писати до stdout. Що бентежить, це те, що моя власна тестова реалізація кота проявляє різну поведінку:

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

Якщо я біжу:

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

Це не циклічно. Враховуючи поведінку catта те, до чого я звертаюся до stdoutтого fread, як я знову закликаюсь, я б очікував, що цей код C продовжить читання та запис у циклі.

Наскільки ці дві поведінки послідовні? Який механізм пояснює, чому catциклі, тоді як наведений вище код не робить?

На старій системі RHEL я отримав, /bin/catробить НЕ петля для cat x >> x. catвидає повідомлення про помилку "cat: x: вхідний файл - вихідний файл". Я можу обдурити /bin/cat, роблячи це: cat < 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;
}

Ця петля теж. Єдине буферування тут (на відміну від "mycat" на основі stdio) - це те, що відбувається в ядрі.

Я думаю , що це відбувається, що дескриптор файл 3 (результат open(av[1])) має зміщення в файл 0. подати дескриптор 1 (STDOUT) має зміщення 3, тому що «>>» призводить до того , що посилається оболонці , щоб виконати команду lseek()на дескриптор файлу, перш ніж передавати його catдочірньому процесу.

Рухається read()будь-якого роду, будь то в STDIO буфер, або циліндричне char buf[]досягнення положення дескриптора файлу 3. Ведення write()переміщує позицію дескриптора файлу 1. Ці два зсуву різних чисел. Через ">>" дескриптор 1 файлу завжди має зсув, більший або рівний зміщенню дескриптора файлу 3. Отже, будь-яка програма "схожа на кішку" буде циклічною, якщо вона не виконує внутрішню буферизацію. Можливо, можливо, навіть ймовірно, що stdio-реалізація FILE *(що є типом символів stdoutта fу вашому коді), що включає власний буфер. fread()може фактично зробити системний виклик read()для заповнення внутрішнього буфера fo f. Це може або не може нічого змінити у внутрішніх сторонах stdout. виклик fwrite()наstdoutможе або не може нічого змінити всередині f. Отже, "кішка" на основі stdio може не зациклюватися. Або може. Важко сказати, не читаючи багато потворних, потворних кодів libc.

Я зробив straceна RHEL cat- він просто робить послідовність read()і write()системні дзвінки. Але catне потрібно працювати таким чином. Можна було б mmap()ввести файл, тоді зробіть write(1, mapped_address, input_file_size). Ядро зробило б всю роботу. Або ви могли б зробити sendfile()системний виклик між дескрипторами вхідного та вихідного файлів у системах Linux. За старими системами SunOS 4.x, по чутках, було зроблено трюк картографічної пам'яті, але я не знаю, чи хтось коли-небудь робив кота на основі sendfile. У будь-якому випадку , «зациклення» б не сталося, так як обидва write()і sendfile()вимагають параметра довжини до передачі.

Сучасна реалізація котів (sunos-4.0 1988) використовує mmap () для відображення всього файлу, а потім викликає 1x write () для цього простору. Така реалізація не буде циклічною, поки віртуальна пам'ять дозволить зіставити весь файл.

Для інших реалізацій це залежить від того, чи більший файл буфера вводу / виводу.

Як написано в підводних каменах Баша , ви не можете прочитати з файлу і записати в нього тим же конвеєром.

Залежно від того, що робить ваш конвеєр, файл може бути клоберованим (до 0 байт або, можливо, на кількість байтів, рівним розміру буфера конвеєра вашої операційної системи), або він може зростати, поки він не заповнить доступний простір на диску або не досягне обмеження розміру файлу вашої операційної системи або квоти тощо

Рішення полягає у використанні текстового редактора або тимчасової змінної.

У вас є певна умова гонки між обома x. Деякі реалізації cat(наприклад, coreutils 8.23) забороняють:

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

Якщо цього не виявити, поведінка, очевидно, буде залежати від реалізації (розмір буфера тощо).

У своєму коді ви можете спробувати додати clearerr(f);після fflush, у випадку, якщо наступний freadповерне помилку, якщо встановлено індикатор кінця файлу.