Sự đồng thuận chung về việc sử dụng mèo vô dụng của mèo là gì?

Khi tôi đặt nhiều lệnh unix như grep, sed, tr, v.v. Tôi có xu hướng chỉ định tệp đầu vào đang được xử lý bằng cat. Vì vậy, một cái gì đó như cat file | grep ... | awk ... | sed ....

Nhưng gần đây sau khi một vài bình luận để lại câu trả lời của tôi chỉ ra rằng đây là cách sử dụng mèo vô dụng, tôi nghĩ tôi sẽ đặt câu hỏi ở đây.

Tôi đã xem xét vấn đề và tình cờ thấy bài viết của Wikipedia về UUOC và Giải thưởng sử dụng mèo vô dụng và đối với tôi, dường như các lập luận đưa ra là từ góc độ hiệu quả.

Câu hỏi gần nhất tôi gặp ở đây là câu hỏi này: Thật lãng phí khi gọi mèo? - nhưng nó không hoàn toàn như những gì tôi yêu cầu.

Tôi đoán những gì trại UUOC gợi ý là sử dụng cmd1 args < file | cmd2 args | cmd3 ..hoặc nếu lệnh có tùy chọn đọc từ tệp sau đó chuyển vào tệp dưới dạng đối số.

Nhưng với tôi cat file | cmd1 ... | cmd2có vẻ dễ đọc và dễ hiểu hơn nhiều. Tôi không phải nhớ các cách khác nhau để gửi các tệp đầu vào đến các lệnh khác nhau và quá trình này chảy một cách hợp lý từ trái sang phải. Đầu vào đầu tiên, sau đó là quá trình đầu tiên ... và như vậy.

Có phải tôi không hiểu những lập luận nào được đưa ra về việc sử dụng con mèo vô dụng? Tôi hiểu rằng nếu tôi đang chạy một công việc định kỳ chạy cứ sau 2 giây mà xử lý nhiều thì trong trường hợp đó, con mèo có thể sẽ lãng phí. Nhưng nếu không thì sự đồng thuận chung về việc sử dụng mèo là gì?

Điều đó là vô ích theo nghĩa là sử dụng nó như thế sẽ không hoàn thành bất kỳ điều gì khác, có thể các tùy chọn hiệu quả hơn không thể (nghĩa là tạo ra kết quả phù hợp).

Nhưng catlà cách mạnh mẽ hơn chỉ cat somefile. Tham khảo man cathoặc đọc những gì tôi đã viết trong câu trả lời này . Nhưng nếu bạn hoàn toàn tích cực chỉ cần nội dung của một tệp duy nhất, bạn có thể nhận được một số lợi thế về hiệu suất từ ​​việc không sử dụng catđể lấy nội dung tệp.

Về khả năng đọc, điều này phụ thuộc vào thị hiếu cá nhân của bạn. Tôi thích cating các tập tin vào các lệnh khác vì lý do tương tự, đặc biệt là nếu các khía cạnh hiệu suất là không đáng kể.

Nó cũng phụ thuộc vào những gì bạn đang viết kịch bản. Nếu đó là phương thức tiện lợi và vỏ riêng của bạn cho máy tính để bàn, không ai ngoại trừ bạn sẽ quan tâm. Nếu bạn vấp phải trường hợp công cụ tiếp theo trong chuỗi sẽ tốt hơn có thể tìm kiếm và phân phối phần mềm này như một phần mềm được sử dụng thường xuyên trên một số hệ thống Linux tối thiểu trên bộ định tuyến hiệu suất thấp hoặc thiết bị tương tự có giới hạn thực khả năng xử lý, đó là khác nhau. Nó luôn luôn phụ thuộc vào bối cảnh.

Trong mỗi dòng lệnh sử dụng, nó không thực sự khác biệt nhiều. Bạn đặc biệt sẽ không nhận thấy bất kỳ sự khác biệt về tốc độ vì thời gian trên CPU tránh bằng cách không sử dụng cat, CPU của bạn sẽ không hoạt động. Ngay cả khi bạn lặp đi lặp lại hàng trăm hoặc hàng ngàn (thậm chí hàng trăm nghìn) vật phẩm, nó sẽ không tạo ra nhiều khác biệt, trừ khi bạn đang ở trên một hệ thống rất tải (Tải CPU trung bình / N> 1).

Nơi cao su gặp đường là hình thành thói quen tốt và ngăn chặn những điều xấu. Để kéo ra một khuôn mẫu sáo rỗng, ma quỷ là trong các chi tiết. Và đó là chi tiết như thế này tách biệt tầm thường với vĩ đại.

Giống như trong khi lái xe, tại sao lại rẽ trái khi bạn chỉ có thể thực hiện ba quyền thay thế? Tất nhiên bạn có thể, và nó hoạt động hoàn hảo. Nhưng nếu bạn hiểu sức mạnh của rẽ trái thì ba quyền chỉ có vẻ ngớ ngẩn.

Đây không phải là về việc lưu một xử lý tệp, 17k RAM và 0,004 giây thời gian CPU. Đó là về toàn bộ triết lý sử dụng UNIX. "Sức mạnh của rẽ trái" trong hình minh họa của tôi không chỉ đơn thuần là chuyển hướng đầu vào, đó là triết lý UNIX. Hoàn toàn mò mẫm điều này sẽ khiến bạn nổi trội hơn nhiều so với những người xung quanh và bạn sẽ thu hút được sự tôn trọng từ những người hiểu.

Tôi thường sử dụng cat file | myprogramtrong các ví dụ. Đôi khi tôi bị buộc tội sử dụng mèo vô dụng ( http://www.iki.fi/era/unix/award.html ). Tôi không đồng ý vì những lý do sau:

• Thật dễ hiểu những gì đang diễn ra.

  Khi đọc lệnh UNIX, bạn mong đợi một lệnh được theo sau bởi các đối số theo sau là chuyển hướng. Nó là tốt để đặt chuyển hướng bất cứ nơi nào nhưng nó hiếm khi được nhìn thấy - do đó mọi người sẽ có một thời gian khó đọc ví dụ. tôi tin

  cat foo | program1 -o option -b option | program2
  

  dễ đọc hơn

  program1 -o option -b option < foo | program2
  

  Nếu bạn di chuyển chuyển hướng đến điểm bắt đầu, bạn sẽ nhầm lẫn những người không quen với cú pháp này:

  < foo program1 -o option -b option | program2
  

  và các ví dụ nên dễ hiểu.

• Nó rất dễ thay đổi.

  Nếu bạn biết chương trình có thể đọc từ mèo, thông thường bạn có thể cho rằng nó có thể đọc đầu ra từ bất kỳ chương trình nào xuất ra STDOUT, và do đó bạn có thể điều chỉnh chương trình theo nhu cầu của riêng mình và nhận được kết quả có thể dự đoán được.

• Nó nhấn mạnh rằng chương trình không thất bại, nếu STDIN không phải là một tệp.

  Sẽ không an toàn khi cho rằng nếu program1 < foohoạt động thì cat foo | program1cũng sẽ hoạt động. Tuy nhiên, nó là trong thực tế an toàn để giả định ngược lại. Chương trình này hoạt động nếu STDIN là một tệp, nhưng không thành công nếu đầu vào là một đường ống, vì nó sử dụng tìm kiếm:

  # works
  < foo perl -e 'seek(STDIN,1,1) || die;print <STDIN>'
  
  # fails
  cat foo | perl -e 'seek(STDIN,1,1) || die;print <STDIN>'
  

Tôi đã xem xét hình phạt hiệu suất trên http://oletange.blogspot.dk/2013/10/usless-use-of-cat.html Kết luận là không sử dụng cat file |nếu độ phức tạp của quá trình xử lý tương tự như một grep đơn giản và hiệu suất quan trọng hơn khả năng đọc. Đối với các tình huống khác cat file |là tốt.

Tôi nghĩ rằng vị trí của một số người bình luận về một cái gì đó là UUOC là nếu một người thực sự hiểu Unix và cú pháp shell, người ta sẽ không sử dụng con mèo trong bối cảnh đó. Nó giống như sử dụng ngữ pháp kém: Tôi có thể viết một câu sử dụng ngữ pháp kém và vẫn hiểu được ý của tôi, nhưng tôi cũng thể hiện sự hiểu biết kém về ngôn ngữ và bằng cách mở rộng, giáo dục kém của tôi. Vì vậy, nói rằng một cái gì đó là UUOC là một cách khác để nói rằng ai đó không hiểu những gì họ đang làm.

Về hiệu quả, nếu bạn đang thực hiện một đường ống từ dòng lệnh, thì máy sẽ mất ít thời gian hơn để thực hiện cat somefile |so với việc bạn nghĩ xem liệu nó có thể hiệu quả hơn khi sử dụng < somefile. Nó không quan trọng.

Tôi đã không nhận thức được giải thưởng cho đến ngày hôm nay khi một số tân binh cố gắng ghim UUOC vào tôi cho một trong những câu trả lời của tôi. Đó là một cat file.txt | grep foo | cut ... | cut .... Tôi đã cho anh ấy một phần suy nghĩ của tôi, và chỉ sau khi làm như vậy, đã truy cập vào liên kết mà anh ấy đã cho tôi đề cập đến nguồn gốc của giải thưởng và thực hành làm như vậy. Tìm kiếm thêm dẫn tôi đến câu hỏi này. Thật không may, mặc dù có ý thức xem xét không có câu trả lời nào bao gồm lý do của tôi.

Tôi không có ý phòng thủ khi giáo dục anh ta. Rốt cuộc, trong những năm còn trẻ, tôi đã viết lệnh grep foo file.txt | cut ... | cut ...vì bất cứ khi nào bạn thường xuyên thực grephiện, bạn sẽ học được vị trí của đối số tệp và sẵn sàng biết rằng đầu tiên là mẫu và các mẫu sau là tên tệp.

Đó là một lựa chọn có ý thức khi tôi trả lời câu hỏi với cattiền tố một phần vì lý do "hương vị tốt" (theo lời của Linus Torvalds) nhưng chủ yếu là vì lý do thuyết phục của chức năng.

Lý do thứ hai là quan trọng hơn vì vậy tôi sẽ đưa nó ra trước. Khi tôi cung cấp một đường ống như một giải pháp, tôi hy vọng nó có thể được tái sử dụng. Rất có khả năng một đường ống sẽ được thêm vào cuối hoặc ghép vào một đường ống khác. Trong trường hợp đó, có một đối số tệp để grep tăng khả năng sử dụng lại và hoàn toàn có thể làm như vậy một cách im lặng mà không có thông báo lỗi nếu đối số tệp tồn tại. I E. grep foo xyz | grep bar xyz | wcsẽ cung cấp cho bạn số lượng dòng xyzchứa bartrong khi bạn đang mong đợi số lượng dòng chứa cả foovà bar. Phải thay đổi đối số thành một lệnh trong một đường ống trước khi sử dụng nó dễ bị lỗi. Thêm vào đó là khả năng thất bại thầm lặng và nó trở thành một thực tiễn đặc biệt quỷ quyệt.

Lý do trước đây không phải là không quan trọng vì rất nhiều "hương vị tốt" chỉ là một lý do tiềm thức trực giác cho những thứ như những thất bại thầm lặng ở trên mà bạn không thể nghĩ ra ngay lúc mà một người cần giáo dục nói "nhưng không phải là con mèo đó vô dụng ".

Tuy nhiên, tôi sẽ cố gắng làm cho ý thức về lý do "hương vị tốt" trước đây tôi đã đề cập. Lý do đó phải làm với tinh thần thiết kế trực giao của Unix. grepkhông cutvà lskhông grep. Do đó ít nhất grep foo file1 file2 file3đi ngược lại với tinh thần thiết kế. Cách trực giao làm việc đó là cat file1 file2 file3 | grep foo. Bây giờ, grep foo file1chỉ đơn thuần là một trường hợp đặc biệt grep foo file1 file2 file3, và nếu bạn không đối xử với nó giống như vậy thì ít nhất bạn cũng đang sử dụng hết chu kỳ đồng hồ não để cố gắng tránh giải thưởng mèo vô dụng.

Điều đó dẫn chúng ta đến cuộc tranh luận về grep foo file1 file2 file3sự kết hợp và catsự kết hợp sao cho phù hợp cat file1 file2 file3nhưng vì catnó không được kết nối cat file1 | grep foodo đó chúng ta đang vi phạm tinh thần của cả catUnix và toàn năng. Chà, nếu đó là trường hợp thì Unix sẽ cần một lệnh khác để đọc đầu ra của một tệp và nhổ nó vào thiết bị xuất chuẩn (không phân trang nó hoặc bất cứ thứ gì chỉ là nhổ thuần túy vào thiết bị xuất chuẩn). Vì vậy, bạn sẽ có tình huống bạn nói cat file1 file2hoặc bạn nói dog file1và nhớ một cách tận tâm cat file1để tránh nhận giải thưởng, đồng thời tránh dog file1 file2vì hy vọng thiết kế dogsẽ gây ra lỗi nếu nhiều tệp được chỉ định.

Hy vọng rằng tại thời điểm này, bạn đồng cảm với các nhà thiết kế Unix vì không bao gồm một lệnh riêng biệt để nhổ một tệp vào thiết bị xuất chuẩn, đồng thời đặt tên catcho concatenate thay vì đặt cho nó một số tên khác. <edit>Có một con chó như vậy, người <điều hành không may . Thật không may là vị trí của nó ở cuối đường ống ngăn cản khả năng kết hợp dễ dàng. Không có cách tổng hợp hoặc thẩm mỹ để đặt nó ở đầu. Thật không may khi không đủ chung chung để bạn bắt đầu với con chó nhưng chỉ cần thêm một tên tệp khác nếu bạn cũng muốn nó được xử lý sau cái trước đó. (Mặt >khác, không phải là một nửa xấu. Nó có vị trí gần như hoàn hảo ở cuối. Nó thường không phải là một phần có thể tái sử dụng của một đường ống, và do đó nó được phân biệt một cách tượng trưng.)</edit>

Câu hỏi tiếp theo là tại sao điều quan trọng là phải có các lệnh chỉ nhổ một tệp hoặc ghép một số tệp vào thiết bị xuất chuẩn mà không cần xử lý thêm? Một lý do là để tránh việc mỗi lệnh Unix hoạt động trên đầu vào tiêu chuẩn phải biết cách phân tích ít nhất một đối số tệp dòng lệnh và sử dụng nó làm đầu vào nếu nó tồn tại. Lý do thứ hai là để tránh người dùng phải nhớ: (a) nơi các đối số tên tệp đi; và (b) tránh lỗi đường ống im lặng như đã đề cập ở trên.

Điều đó đưa chúng ta đến lý do tại sao grepcó logic bổ sung. Lý do là cho phép người dùng lưu loát cho các lệnh được sử dụng thường xuyên và trên cơ sở độc lập (chứ không phải là một đường ống). Đó là một sự thỏa hiệp nhỏ về tính trực giao để đạt được đáng kể khả năng sử dụng. Không phải tất cả các lệnh phải được thiết kế theo cách này và các lệnh không được sử dụng thường xuyên sẽ tránh hoàn toàn logic bổ sung của các đối số tệp (hãy nhớ logic bổ sung dẫn đến sự mong manh không cần thiết (khả năng xảy ra lỗi)). Ngoại lệ là cho phép đối số tệp như trong trường hợp grep. (bằng cách lưu ý rằng lscó một lý do hoàn toàn khác để không chỉ chấp nhận mà còn yêu cầu khá nhiều đối số tệp)

Cuối cùng, những gì có thể được thực hiện tốt hơn là nếu các lệnh đặc biệt như grep(nhưng không nhất thiết ls) tạo ra lỗi nếu đầu vào tiêu chuẩn có sẵn. Điều này là hợp lý bởi vì các lệnh bao gồm logic vi phạm tinh thần trực giao của Unix toàn năng để thuận tiện cho người dùng. Để thuận tiện hơn cho người dùng, tức là để ngăn chặn sự đau khổ do lỗi im lặng gây ra, các lệnh như vậy không nên ngần ngại vi phạm chính họ bằng cách cảnh báo cho người dùng nếu có khả năng xảy ra lỗi im lặng.

Để bảo vệ những công dụng vô dụng của mèo

(Một vài đoạn để giúp cân bằng sóng thần về những bình luận cằn nhằn chống lại thực tiễn này)

Tôi đã sử dụng bash trong quá nhiều năm vừa là vỏ sò vừa là ngôn ngữ kịch bản cho các tập lệnh nhỏ (và đôi khi rất tiếc cho những phần không nhỏ). Cách đây rất lâu, tôi đã biết về "Sử dụng mèo vô dụng" (UUoC). Tôi vẫn phạm tội ít nhất mỗi tuần nhưng thật lòng tôi hiếm khi cảm thấy mình thậm chí có một chút buộc phải tránh nó. Tôi tin rằng việc sử dụng catvs liên quan < filenhiều đến hương vị hơn là sự khác biệt về kỹ thuật và tôi đã viết câu trả lời này để bảo vệ những người mới sử dụng Linux có chung sở thích của tôi vớicattừ việc nghĩ rằng có điều gì đó sai nghiêm trọng về cách của họ (và lưu ý vài lần có). Giống như Linus Torvalds tôi cũng tin rằng hương vị thường quan trọng hơn kỹ năng. Điều đó không có nghĩa là khẩu vị của tôi tốt hơn khẩu vị của bạn nhưng điều đó có nghĩa là nếu thứ gì đó có vị xấu tôi sẽ không làm điều đó mà không đạt được thứ gì đó xứng đáng.

Rõ ràng là giống như tác giả câu hỏi Tôi cảm thấy rằng việc sử dụng mèo là rất tự nhiên khi làm việc trên REPL như bash khi tôi đang khám phá một vấn đề bằng cách tăng dần các lệnh phức tạp. Đây là một ví dụ rất điển hình: Tôi có một tệp văn bản và không biết nhiều về nó. Tôi sẽ gõ cat fileđể có được một hương vị của nội dung. Nếu đầu ra là quá nhiều Tôi sẽ đánh tôi mũi tên lên và tùy thuộc vào hoàn cảnh tôi sẽ thêm | headhoặc | grep foohoặc | what_evermở rộng lệnh trước đây của tôi bằng cách thêm các bước xử lý. Cách này tăng dần từ một lệnh đơn giản sang một lệnh phức tạp hơn bằng cách thêm một bước xử lý sau khi bước khác cảm thấy rất tự nhiên đối với tôi (Tôi cũng làm như vậy với ipython và tôi thích cách nàypyfunctionalvà các công cụ lập trình tương tự bao gồm phong cách này). Vì vậy, khi làm việc với bash shell, tôi tin tưởng rằng việc làm gián đoạn dòng chảy của tôi để loại bỏ catnó là vô ích hơn là để nó tồn tại và chịu đựng ... cũng không có hậu quả nào trong 99,9% trường hợp.

Tất nhiên khi viết kịch bản mọi thứ có thể thay đổi. Nhưng ngay cả khi viết kịch bản, theo ý kiến ​​của tôi, những người chế giễu UUoC đã bỏ qua bài học quan trọng này bởi một ý nghĩ tuyệt vời: "Tối ưu hóa sớm là gốc rễ của mọi tội lỗi" . Và nếu bạn không làm điều gì đó không điển hình, thật khó để UUoC trở thành nơi cần tối ưu hóa. Tất nhiên bạn chắc chắn cần phải biết những gì không hiệu quả về nó (đó là BTW gọi thêm quy trình bổ sung vì dường như rất ít đề cập đến nó). Có kiến ​​thức đó nếu bạn tình cờ làm việc trên các hệ thống hiếm hoi đó, trong đó việc gọi một quy trình là tốn kém (ví dụ: một số hệ thống nhúng hoặc CygWin ở mức độ thấp hơn), bạn sẽ biết phải làm gì nếu tình huống đặc biệt yêu cầu. Ví dụ nếu bạn thấy mình gọicatnhiều lần một giây trong một vòng lặp (BTW nếu bạn thấy mình ở vị trí đó hãy tự hỏi liệu bash có phải là công cụ phù hợp cho công việc không). Một lần nữa mặc dù: "đầu tiên làm cho nó hoạt động chính xác sau đó tối ưu hóa nó nếu cần thiết" .

Và làm thế nào để bạn giải thích sóng thần phàn nàn về UUoC Nick?

Bên cạnh đó không phải ai cũng có sở thích của tôi, tôi tin rằng một phần lớn lý do tại sao rất nhiều người phàn nàn về UUoC không phải là kỹ thuật mà là con người: Hầu hết những người mới sử dụng Unix sẽ không biết về < file commandthành ngữ này nên rất cám dỗ một người có kinh nghiệm hơn để chơi "Old Guru "Với họ. Anh ta cũng sẽ có cơ hội sử dụng những từ ưa thích ("quá trình gọi") và chạm vào chủ đề thân yêu là "tối ưu hóa". Một ấn tượng tốt được đảm bảo nên rất khó cưỡng lại. Sau đó, những người mới đến sẽ nhận lời khuyên của Chuyên gia theo mệnh giá và trong một thời gian dài sẽ phát lại nó cho người khác là "Sự thật duy nhất" (và bỏ phiếu trả lời câu trả lời này :-). Lưu ý hài hước: có thể rất dễ dàng để sửa bash để tránh bất kỳ sự thiếu hiệu quả nào của UUoC mà người ta phải tự hỏi tại sao không ai thêm tính năng này hoặc thực hiện< filenamemèo một tập tin sau nhiều năm. Một linh hồn đen tối sẽ gợi ý rằng một số tin tặc bash xám muốn để lại cơ hội chế giễu chúng tôi ;-)

Điều gì sẽ thực sự tốt đẹp là một shell hỗ trợ cú pháp như:

< filename cmd | cmd2 cmd2arg1... | cmd3

Trong khi đó, tôi nghĩ cat filename | realcmd1...là chấp nhận được, vì nó giữ cú pháp được chuẩn hóa với các lệnh ban đầu yêu cầu tên tệp làm đối số.

Đối với tất cả những người nói rằng mèo được chấp nhận sử dụng vì nó "có mùi" tốt hơn hoặc "dễ đọc hơn" tôi chỉ nói điều này:

Đối với bạn có thể ... nhưng không phải cho những người khác có thể đọc hoặc cố gắng hiểu mã của bạn. Nếu bạn sẽ không bao giờ cố gắng hướng dẫn người khác bằng các ví dụ của bạn hoặc chia sẻ mã của bạn, thì bằng mọi cách, vui lòng sử dụng nó một cách thoải mái.

Tôi cũng sẽ thêm nhận xét này, vì một người dùng Linux và Quản trị viên / Kỹ sư lâu năm ... (và có nhiều người trong chúng ta) nó làm cho mắt chúng ta chảy máu khi thấy điều này. Tại sao? Bởi vì nó sử dụng tài nguyên trên các hệ thống mà chúng tôi kiểm soát tài nguyên chặt chẽ. Lệnh cat và ống tự sử dụng bộ nhớ và tập tin xử lý bổ sung hoàn toàn vô dụng. Bạn đã liên kết các tài nguyên mà hệ thống của tôi cần miễn phí và bạn đã đạt được KHÔNG CÓ gì có thể giải thích việc sử dụng các tài nguyên này. Đây là một không lớn không có.

Bây giờ tôi có thể ngồi đây và tranh luận về những thứ như mùi mã hoặc khả năng đọc cả ngày với bất kỳ ai, nhưng vào cuối ngày, đó là vấn đề viết hoặc sai và bất cứ khi nào bạn sử dụng tài nguyên trên hệ thống và không thu được gì cho nó ... nó sai

Là người dùng gia đình, bạn có thể học hỏi từ lời khuyên của tôi và học cách tốt hơn để làm mọi thứ hoặc bạn có thể chọn bị mù bởi "mùi" của mèo, lựa chọn của bạn ... nhưng hãy biết rằng nếu bạn công khai thực hành cách này, bạn sẽ được gọi trên thực tế này mọi lúc và bạn sẽ phải âm thầm thừa nhận họ đúng và bạn cứng đầu vì đó là sự thật. :-)