ทำไม cat x >> x loop

คำสั่ง bash ต่อไปนี้จะเข้าสู่วง infinte:

$ 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เมื่อฉันลองโค้ดของคุณด้านบนฉันจะได้ "ลูป" ที่คุณอธิบาย ฉันยังเขียน "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;
}

ลูปนี้เช่นกัน บัฟเฟอร์เดียวที่นี่ (ซึ่งแตกต่างจาก stdio ตาม "mycat") คือสิ่งที่เกิดขึ้นในเคอร์เนล

ฉันคิดว่าสิ่งที่เกิดขึ้นคือ file descriptor 3 (ผลลัพธ์ของopen(av[1])) มี offset เป็นไฟล์ 0 Filed descriptor 1 (stdout) มี offset ของ 3 เพราะ ">>" ทำให้เชลล์ที่อ้างถึงทำlseek()บน file descriptor ก่อนส่งไปยังcatกระบวนการ child

การread()เรียงลำดับใด ๆ ไม่ว่าจะเป็นบัฟเฟอร์ stdio หรือธรรมดาจะchar buf[]เลื่อนตำแหน่งของไฟล์ descriptor 3 การทำwrite()ตำแหน่งของไฟล์ descriptor ขั้นสูง 1 การออฟเซ็ตทั้งสองนั้นเป็นตัวเลขที่แตกต่างกัน เนื่องจาก ">>" file descriptor 1 มักจะมี offset มากกว่าหรือเท่ากับ offset ของ file descriptor 3 ดังนั้นโปรแกรม "cat-like" ใด ๆ ก็ตามจะวนซ้ำจนกว่าจะมีการบัฟเฟอร์ภายใน อาจเป็นไปได้หรืออาจเป็นไปได้ว่าการใช้ stdio ของFILE *(ซึ่งเป็นประเภทของสัญลักษณ์stdoutและfในรหัสของคุณ) ที่มีบัฟเฟอร์ของตัวเอง fread()จริงอาจจะเรียกระบบที่จะเติมบัฟเฟอร์ภายในสำหรับread()fstdoutนี้อาจหรือไม่อาจมีการเปลี่ยนแปลงอะไรในอวัยวะภายในของCalling fwrite()บนstdoutfหรืออาจจะไม่เปลี่ยนอะไรภายในของ ดังนั้น "cat" ที่ใช้ stdio อาจไม่วนซ้ำ หรืออาจ ยากที่จะพูดโดยไม่ต้องอ่านรหัส libc ที่น่าเกลียดและน่าเกลียดมาก

ฉันทำstraceบน RHEL cat- มันเป็นการต่อเนื่องread()และการwrite()เรียกของระบบ แต่catไม่ต้องทำงานแบบนี้ มันจะเป็นไปได้ที่จะใส่ไฟล์แล้วทำmmap() write(1, mapped_address, input_file_size)เคอร์เนลจะทำงานทั้งหมด หรือคุณสามารถทำการsendfile()เรียกระบบระหว่างตัวอธิบายไฟล์อินพุตและเอาต์พุตบนระบบ Linux ระบบเก่า SunOS 4.x มีข่าวลือว่าทำเคล็ดลับการจับคู่หน่วยความจำ แต่ฉันไม่รู้ว่ามีใครทำแมวที่ใช้ sendfile หรือไม่ ในทั้งสองกรณี "ลูป" จะไม่เกิดขึ้นเนื่องจากทั้งคู่write()และsendfile()ต้องการพารามิเตอร์แบบยาวต่อการถ่ายโอน

การใช้ cat ที่ทันสมัย ​​(sunos-4.0 1988) ใช้ mmap () เพื่อแมปไฟล์ทั้งหมดแล้วเรียก 1x write () สำหรับพื้นที่นี้ การใช้งานดังกล่าวจะไม่วนซ้ำตราบใดที่หน่วยความจำเสมือนอนุญาตให้แมปไฟล์ทั้งหมด

สำหรับการนำไปใช้งานอื่น ๆ นั้นขึ้นอยู่กับว่าไฟล์มีขนาดใหญ่กว่าบัฟเฟอร์ I / O

ตามที่เขียนไว้ในข้อผิดพลาดทุบตี , คุณไม่สามารถอ่านจากไฟล์และเขียนไปในท่อเดียวกัน

ไฟล์อาจถูกอุดตัน (เป็น 0 ไบต์หรืออาจเป็นจำนวนไบต์เท่ากับขนาดของไพพ์ไลน์ของระบบปฏิบัติการของคุณ) หรืออาจขยายจนเต็มพื้นที่ดิสก์ที่มีอยู่หรือไปถึง ข้อ จำกัด ขนาดไฟล์ของระบบปฏิบัติการหรือโควต้าของคุณเป็นต้น

การแก้ปัญหาคือการใช้โปรแกรมแก้ไขข้อความหรือตัวแปรชั่วคราว

xคุณมีชนิดของสภาพการแข่งขันระหว่างทั้งบาง การใช้งานบางอย่างของcat(เช่น coreutils 8.23) ห้ามว่า:

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

หากไม่พบสิ่งนี้พฤติกรรมจะขึ้นอยู่กับการนำไปใช้อย่างชัดเจน (ขนาดบัฟเฟอร์ ฯลฯ )

ในรหัสของคุณคุณสามารถลองเพิ่มclearerr(f);หลังfflushในกรณีที่ต่อไปfreadจะกลับข้อผิดพลาดหากตัวบ่งชี้การสิ้นสุดของไฟล์ถูกตั้งค่า