Cho ví dụ tối thiểu này

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; )

nó xuất ra LINE 1và sau đó, sau một giây, đầu ra LINE 2, như mong đợi .

Nếu chúng ta đặt cái này vào grep LINE

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; ) | grep LINE

hành vi giống như trong trường hợp trước, như mong đợi .

Nếu, thay vào đó, chúng tôi dẫn đường này đến cat

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; ) | cat

hành vi lại giống nhau, như mong đợi .

Tuy nhiên , nếu chúng ta dẫn đến grep LINE, và sau đó cat,

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; ) | grep LINE | cat

không có đầu ra cho đến khi một giây trôi qua và cả hai dòng xuất hiện trên đầu ra ngay lập tức, điều mà tôi không mong đợi .

Tại sao điều này xảy ra và làm thế nào tôi có thể làm cho phiên bản cuối cùng hoạt động giống như ba lệnh đầu tiên?

Khi đầu ra của (ít nhất là GNU) grepkhông phải là một thiết bị đầu cuối, nó sẽ đệm đầu ra của nó, đó là nguyên nhân gây ra hành vi mà bạn nhìn thấy. Bạn có thể tắt tùy chọn này bằng tùy chọn grepcủa GNU --line-buffered:

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; ) | grep --line-buffered LINE | cat

hoặc stdbuftiện ích:

( echo "LINE 1" ; sleep 1 ; echo "LINE 2" ; ) | stdbuf -oL grep LINE | cat

Tắt bộ đệm trong đường ống có nhiều hơn về chủ đề này.

Giải thích đơn giản

Giống như nhiều tiện ích, đây không phải là một thứ gì đó đặc biệt với một chương trình, grepthay đổi đầu ra tiêu chuẩn của nó giữa được đệm dòng và được đệm hoàn toàn . Trong trường hợp trước, thư viện C đệm dữ liệu đầu ra trong bộ nhớ cho đến khi bộ đệm chứa các dữ liệu đó được điền hoặc ký tự linefeed được thêm vào nó (hoặc chương trình kết thúc sạch), sau đó nó gọi write()để thực sự ghi nội dung bộ đệm. Trong trường hợp sau, chỉ có bộ đệm trong bộ nhớ trở nên đầy (hoặc chương trình kết thúc sạch) mới kích hoạt write().

Giải thích chi tiết hơn

Đây là lời giải thích nổi tiếng, nhưng hơi sai. Trong thực tế, đầu ra tiêu chuẩn không phải là bộ đệm dòng mà là bộ đệm thông minh trong thư viện GNU C và thư viện BSD C. Chuẩn đầu ra là cũng đỏ ửng khi đọc tiêu chuẩn đầu vào làm cạn kiệt của nó đệm trong bộ nhớ (đầu vào trước khi đọc) và thư viện C có gọi read()để lấy một số đầu vào nhiều hơn và nó được đọc đầu một dòng mới. (Một lý do cho việc này là để ngăn chặn sự bế tắc khi một chương trình khác tự kết nối với cả hai đầu của bộ lọc và hy vọng có thể vận hành từng dòng một, xen kẽ giữa việc ghi vào bộ lọc và đọc từ nó; như "coprocesses" trong GNU awkví dụ.)

Ảnh hưởng thư viện C

grepvà các tiện ích khác thực hiện việc này - hoặc, đúng hơn, các thư viện C mà họ sử dụng thực hiện việc này, bởi vì đây là một tính năng được xác định của lập trình bằng ngôn ngữ C - dựa trên những gì họ phát hiện ra đầu ra tiêu chuẩn của họ. Nếu (và chỉ nếu) nó không phải là một thiết bị tương tác, họ chọn bộ đệm đầy đủ, nếu không họ chọn bộ đệm thông minh. Một đường ống được coi là không phải là một thiết bị tương tác, bởi vì định nghĩa là một thiết bị tương tác, ít nhất là trong thế giới của Unix và Linux, về cơ bản là isatty()cuộc gọi trả về đúng cho bộ mô tả tệp có liên quan.

Giải pháp để vô hiệu hóa bộ đệm đầy đủ

Một số tiện ích như grepcó các tùy chọn idiosyncratic như --line-bufferedthay đổi quyết định này, mà bạn có thể thấy là đặt tên sai. Nhưng một phần nhỏ của các chương trình lọc mà người ta có thể sử dụng thực sự có một tùy chọn như vậy.

Tổng quát hơn, người ta có thể sử dụng các công cụ đào sâu vào các phần bên trong cụ thể của thư viện C và thay đổi việc ra quyết định (có vấn đề về bảo mật nếu chương trình bị thay đổi là set-UID và cũng cụ thể cho các thư viện C cụ thể, và thực tế là cụ thể đối với các chương trình viết bằng hoặc lớp trên đầu trang của ngôn ngữ C), hoặc các công cụ như ptybandagerằng không thay đổi bên trong của chương trình mà chỉ đơn giản xen một pseudo-thiết bị đầu cuối như đầu ra tiêu chuẩn để quyết định đi ra là "tương tác", để ảnh hưởng đến điều này.

đọc thêm

• /unix//a/407472/5132
• /unix//a/249801/5132

Sử dụng

grep --line-buffered

để làm cho grep không đệm nhiều hơn một dòng cùng một lúc.