Tại sao một số lệnh không được đọc từ đầu vào tiêu chuẩn của họ?

Tôi tự hỏi những gì khi chúng ta nên sử dụng đường ống và khi nào chúng ta không nên.

Ví dụ, để giết một số quy trình xử lý tệp pdf, các thao tác sau sẽ không hoạt động bằng cách sử dụng đường ống dẫn:

ps aux | grep pdf | awk '{print $2}'|kill

Thay vào đó, chúng tôi chỉ có thể làm điều đó với các cách sau:

kill $(ps aux| grep pdf| awk '{print $2}')

hoặc là

ps aux | grep pdf | awk '{print $2}'| xargs kill

Theo man bash(phiên bản 4.1.2):

The standard output of command is connected via a pipe to the standard input of command2.

Đối với kịch bản trên:

• stdin của greplà stdout của ps. Điều đó làm việc.
• stdin của awklà stdout của grep. Điều đó làm việc.
• stdin của killlà stdout của awk. Điều đó không hiệu quả.

Stdin của lệnh sau luôn nhận đầu vào từ thiết bị xuất chuẩn của lệnh trước.

• Tại sao nó không hoạt động với killhoặc rm?
• Có gì khác nhau giữa kill, rmđầu vào với grep, awkđầu vào?
• Có quy định nào không?

Có hai cách phổ biến để cung cấp đầu vào cho các chương trình:

• cung cấp dữ liệu cho STDIN của các quy trình
• chỉ định đối số dòng lệnh

killchỉ sử dụng đối số dòng lệnh. Nó không đọc từ STDIN. Các chương trình thích grepvà awkđọc từ STDIN (nếu không có tên tệp nào được đưa ra làm đối số dòng lệnh) và xử lý dữ liệu theo các đối số dòng lệnh của chúng (mẫu, câu lệnh, cờ, ...).

Bạn chỉ có thể chuyển sang STDIN của các quy trình khác, không thể ra lệnh đối số dòng.

Quy tắc chung là, các chương trình sử dụng STDIN để xử lý lượng dữ liệu tùy ý. Tất cả các tham số đầu vào bổ sung hoặc, nếu thường chỉ có một ít, được truyền bởi các đối số dòng lệnh. Nếu dòng lệnh có thể rất dài, ví dụ đối với awkcác văn bản chương trình dài , thường có khả năng đọc chúng từ các tệp chương trình bổ sung ( -ftùy chọn awk).

Để sử dụng STDOUT của các chương trình làm đối số dòng lệnh, sử dụng $(...)hoặc trong trường hợp có nhiều dữ liệu xargs. findcũng có thể điều này trực tiếp với -exec ... {} +.

Để hoàn thiện: Để viết các đối số dòng lệnh vào STDOUT, hãy sử dụng echo.

Đây là một câu hỏi thú vị và nó liên quan đến một phần của triết lý Unix / Linux.

Vì vậy, sự khác biệt giữa các chương trình như là những gì grep, sed, sorttrên một mặt và kill, rm, lsmặt khác? Tôi thấy hai khía cạnh.

Các bộ lọc khía cạnh

• Loại chương trình đầu tiên cũng được gọi là bộ lọc . Họ lấy một đầu vào, từ một tệp hoặc từ STDIN, sửa đổi nó và tạo ra một số đầu ra, chủ yếu là STDOUT. Chúng có nghĩa là được sử dụng trong một đường ống với các chương trình khác làm nguồn và đích.

• Loại chương trình thứ hai hoạt động trên một đầu vào, nhưng đầu ra mà chúng đưa ra thường không liên quan đến đầu vào. killkhông có đầu ra khi nó hoạt động thường xuyên, cũng không ls. Chỉ cần có một giá trị trở lại để hiển thị thành công. Họ thường không nhận đầu vào từ STDIN, nhưng chủ yếu cung cấp đầu ra cho STDOUT.

Đối với các chương trình như ls, khía cạnh bộ lọc không hoạt động tốt. Nó chắc chắn có thể có một đầu vào (nhưng không cần một đầu vào) và đầu ra có liên quan chặt chẽ với đầu vào đó, nhưng nó không hoạt động như một bộ lọc. Tuy nhiên, đối với loại chương trình đó, khía cạnh khác vẫn hoạt động:

Các ngữ nghĩa khía cạnh

• Đối với các bộ lọc, đầu vào của chúng không có ý nghĩa ngữ nghĩa . Họ chỉ đọc dữ liệu, sửa đổi dữ liệu, dữ liệu đầu ra. Không quan trọng đây là danh sách các giá trị số, một số tên tệp hoặc mã nguồn HTML. Ý nghĩa của dữ liệu này chỉ được cung cấp bởi mã bạn cung cấp cho bộ lọc: regex for grep, quy tắc cho awkhoặc chương trình Perl.

• Đối với các chương trình khác, thích killhoặc ls, đầu vào của họ có một ý nghĩa , một ngoại diên . killmong đợi số quá trình, lsmong đợi tập tin hoặc tên đường dẫn. Họ không thể xử lý dữ liệu tùy ý và chúng không có nghĩa. Nhiều người trong số họ thậm chí không cần bất kỳ đầu vào hoặc tham số, như ps. Họ thường không đọc từ STDIN.

Một người có thể có thể kết hợp hai khía cạnh này: Bộ lọc là một chương trình có đầu vào không có ý nghĩa ngữ nghĩa cho chương trình.

Tôi chắc chắn tôi đã đọc về triết lý này ở đâu đó, nhưng tôi không nhớ bất kỳ nguồn nào vào lúc này, xin lỗi. Nếu ai đó có một số nguồn hiện tại, xin vui lòng chỉnh sửa.

Không có "quy tắc" nào như vậy. Một số chương trình lấy đầu vào từ STDIN, và một số thì không. Nếu một chương trình có thể lấy đầu vào từ STDIN, thì nó có thể được dẫn đến, nếu không, nó không thể.

Thông thường bạn có thể biết liệu một chương trình sẽ nhận đầu vào hay không bằng cách suy nghĩ về những gì nó làm. Nếu công việc của chương trình là bằng cách nào đó thao tác các nội dung của một tập tin (ví dụ như grep, sed, awkvv), nó thường có đầu vào từ STDIN. Nếu công việc của mình là để thao tác các tập tin riêng của mình (ví dụ như mv, rm, cp) hoặc một quá trình (ví dụ kill, lsof) hoặc thông tin trở về một cái gì đó (ví dụ top, find, ps) sau đó nó không.

Một cách nghĩ khác về nó là sự khác biệt giữa các đối số và đầu vào. Ví dụ:

mv foo bar

Trong lệnh trên, mvkhông có đầu vào như vậy. Những gì nó đã được đưa ra là hai đối số. Nó không biết hoặc quan tâm những gì trong một trong hai tệp, nó chỉ biết đó là những đối số của nó và nó nên thao túng chúng.

Mặt khác

sed -e 's/foo/bar/' < file
--- -- ------------   ----
 |   |       |          |-> input
 |   |       |------------> argument        
 |   |--------------------> option/flag/switch
 |------------------------> command

Ở đây, sedđã được đưa ra đầu vào cũng như một đối số. Vì nó nhận đầu vào, nó có thể đọc nó từ STDIN và nó có thể được dẫn đến.

Nó trở nên phức tạp hơn khi một đối số có thể là đầu vào. Ví dụ

cat file

Đây filelà lý lẽ đã được đưa ra cat. Nói chính xác, tên tập tin filelà đối số. Tuy nhiên, vì catlà một chương trình thao túng nội dung của các tệp, nên đầu vào của nó là bất cứ thứ gì bên trong file.

Điều này có thể được minh họa bằng cách sử dụng strace, một chương trình theo dõi các cuộc gọi hệ thống được thực hiện bởi các quy trình. Nếu chúng tôi chạy cat fooqua strace, chúng tôi có thể thấy rằng tệp foođược mở:

$ strace cat foo 2| grep foo
execve("/bin/cat", ["cat", "foo"], [/* 44 vars */]) = 0
open("foo", O_RDONLY)     

Dòng đầu tiên ở trên cho thấy rằng chương trình /bin/catđã được gọi và các đối số của nó là catvà foo(đối số đầu tiên luôn luôn là chính chương trình). Sau đó, đối số foođược mở trong chế độ chỉ đọc. Bây giờ, so sánh điều này với

$ strace ls foo 2| grep foo 
execve("/bin/ls", ["ls", "foo"], [/* 44 vars */]) = 0
stat("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(1, "foo\n", 4foo

Ở đây cũng vậy, lslấy chính nó và foolàm đối số. Tuy nhiên, không có opencuộc gọi, đối số không được coi là đầu vào. Thay vào đó, hãy lsgọi statthư viện của hệ thống (không giống với statlệnh) để lấy thông tin về tệp foo.

Tóm lại, nếu lệnh bạn đang chạy sẽ đọc đầu vào của nó, bạn có thể chuyển sang lệnh đó, nếu không, bạn không thể.

• Tại sao nó không hoạt động với kill hoặc rm?

killvà rmkhông cần STDIN.

• Có gì khác nhau giữa đầu vào kill, rm với đầu vào grep, awk?

Đối với killvà rm, người dùng cung cấp thông tin tùy chỉnh của họ làm đối số và $(cmd)giúp lấy STDOUT của cmdvà chuyển đổi đối số thông tin.

Đối với grepvà awk, người dùng cung cấp các đối số và ngoài ra, STDINhoặc một tệp thông thường sẽ được xử lý bằng lệnh. STDINcó thể được thông qua với đường ống |hoặc bằng cách nhập thủ công.

• Có quy định nào không?

Đọc hướng dẫn hoặc mã nguồn. Và nếu bạn không tìm thấy gì mình cần, bạn có thể thực hiện một bài kiểm tra đơn giản nhưng có thể nguy hiểm:

Chỉ cần nhập lệnh bạn tò mò, với các đối số mà bạn đã hiểu và xem liệu lệnh tạm dừng (không có gì xảy ra). Nếu nó tạm dừng, nó thực sự đang chờ STDIN (bạn có thể thử catvà echoxem khác nhau). Bạn nhập thủ công Ctrl-Dvà lệnh đi trước (hiển thị kết quả hoặc lỗi) và trả về. Lệnh như vậy cần STDIN trong tình huống đó (với các đối số bạn cung cấp).

Lệnh tương tự có thể không cần STDIN trong các tình huống khác nhau (ví dụ: catđợi STDIN nhưng cat file.txtkhông).