ฉันทามติทั่วไปเกี่ยวกับ“ การใช้แมวที่ไร้ประโยชน์” คืออะไร?

เมื่อฉันไพพ์คำสั่ง unix หลายคำสั่งเช่น grep, sed, tr ฯลฯ ฉันมักจะระบุไฟล์อินพุตที่กำลังถูกประมวลผลโดยใช้ cat cat file | grep ... | awk ... | sed ...ดังนั้นสิ่งที่ต้องการ

แต่เมื่อไม่นานมานี้หลังจากมีความคิดเห็นที่เหลืออยู่ในคำตอบของฉันแสดงว่านี่เป็นการใช้แมวที่ไร้ประโยชน์ฉันคิดว่าฉันจะถามคำถามที่นี่

ฉันค้นหาปัญหาและพบบทความของ Wikipedia เกี่ยวกับ UUOCและThe Useless Use of Cat Awardและดูเหมือนว่าสำหรับฉันแล้วข้อโต้แย้งที่ทำนั้นมาจากมุมมองของประสิทธิภาพ

คำถามที่ใกล้เคียงที่สุดที่ฉันได้พบที่นี่คือคำถามนี้: การเรียกแมวเป็นเรื่องที่สิ้นเปลืองหรือไม่? - แต่มันไม่ใช่สิ่งที่ฉันถาม

ฉันเดาสิ่งที่ค่าย UUOC แนะนำคือการใช้cmd1 args < file | cmd2 args | cmd3 ..หรือถ้าคำสั่งมีตัวเลือกให้อ่านจากไฟล์แล้วส่งผ่านในไฟล์เป็นอาร์กิวเมนต์

แต่สำหรับฉันcat file | cmd1 ... | cmd2ดูเหมือนว่าจะง่ายต่อการอ่านและทำความเข้าใจ ฉันไม่ต้องจำวิธีที่แตกต่างกันในการส่งไฟล์อินพุตไปยังคำสั่งต่าง ๆ และกระบวนการจะไหลอย่างมีเหตุผลจากซ้ายไปขวา อินพุตแรกจากนั้นประมวลผลแรก ... และอื่น ๆ

ฉันล้มเหลวหรือไม่ที่จะเข้าใจว่าข้อโต้แย้งอะไรที่เกี่ยวกับการใช้แมวที่ไร้ประโยชน์? ฉันเข้าใจว่าถ้าฉันทำงาน cron ที่ทำงานทุก ๆ 2 วินาทีซึ่งทำการประมวลผลมากมายในกรณีนี้ cat อาจสิ้นเปลือง แต่อย่างอื่นฉันทามติทั่วไปเกี่ยวกับการใช้แมวคืออะไร?

มันไร้ประโยชน์ในแง่ที่ว่าการใช้แบบนี้ไม่ได้ทำสิ่งอื่นให้สำเร็จอาจเป็นตัวเลือกที่มีประสิทธิภาพมากกว่าไม่ได้ (เช่นสร้างผลลัพธ์ที่เหมาะสม)

แต่เป็นวิธีที่มีประสิทธิภาพมากขึ้นกว่าเพียงแค่cat cat somefileปรึกษาman catหรืออ่านสิ่งที่ฉันเขียนในคำตอบนี้ แต่ถ้าคุณต้องการเนื้อหาของไฟล์เดียวอย่างแน่นอนคุณอาจได้รับประโยชน์จากการไม่ใช้catเพื่อเข้าถึงเนื้อหาไฟล์

เกี่ยวกับความสามารถในการอ่านสิ่งนี้ขึ้นอยู่กับรสนิยมส่วนตัวของคุณ ฉันชอบนำcatไฟล์ไปไว้ในคำสั่งอื่น ๆ ด้วยเหตุผลเดียวกันโดยเฉพาะอย่างยิ่งหากแง่มุมของประสิทธิภาพนั้นเล็กน้อย

นอกจากนี้ยังขึ้นอยู่กับสิ่งที่คุณเขียนสคริปต์ หากเป็นวิธีเชลล์และความสะดวกสบายสำหรับเครื่องเดสก์ท็อปของคุณไม่มีใครนอกจากคุณจะสนใจ หากคุณสะดุดกรณีที่เครื่องมือถัดไปในเครือจะดีกว่าไม่สามารถค้นหาและแจกจ่ายสิ่งนี้เป็นซอฟต์แวร์ที่ใช้บ่อยในระบบ Linux ขั้นต่ำบางตัวในเราเตอร์ประสิทธิภาพต่ำหรืออุปกรณ์ที่คล้ายกันซึ่งมีข้อ จำกัด จริง ความสามารถในการประมวลผลนั้นแตกต่างกัน มันขึ้นอยู่กับบริบทเสมอ

ในทุก ๆ วันบรรทัดคำสั่งใช้มันไม่ต่างกันมาก คุณจะไม่สังเกตเห็นความแตกต่างของความเร็วใด ๆ โดยเฉพาะอย่างยิ่งตั้งแต่เวลาที่หลีกเลี่ยงการใช้ CPU โดยที่catCPU ของคุณไม่ทำงาน แม้ว่าคุณจะวนลูปผ่านหลายแสนหรือหลายพัน (หรือหลายแสน) ของไอเท็มในการใช้งานได้จริงมันจะไม่สร้างความแตกต่างมากนักเว้นแต่ว่าคุณอยู่ในระบบที่โหลดมาก (โหลด CPU เฉลี่ย / N> 1)

ที่ซึ่งยางตรงกับถนนกำลังก่อตัวเป็นนิสัยที่ดีและทำให้คนไม่ดีท้อใจ หากต้องการลากความคิดโบราณขึ้นมามารจะอยู่ในรายละเอียด และมันมีรายละเอียดเช่นนี้ที่แยกความแตกต่างจากความยิ่งใหญ่

มันเหมือนกับการขับรถทำไมถึงต้องเลี้ยวซ้ายเมื่อคุณสามารถทำสามสิทธิ์แทนได้ แน่นอนคุณสามารถและทำงานได้อย่างสมบูรณ์ แต่ถ้าคุณเข้าใจพลังแห่งการเลี้ยวซ้ายก็มีสิทธิ์สามอย่างที่ดูเหมือนโง่

ไม่เกี่ยวกับการบันทึกการจัดการไฟล์หนึ่งไฟล์ 17k of RAM และ 0.004 วินาทีของเวลา CPU มันเกี่ยวกับปรัชญาทั้งหมดของการใช้ UNIX "พลังแห่งการเลี้ยวซ้าย" ในภาพประกอบของฉันไม่เพียง แต่เปลี่ยนเส้นทางอินพุต แต่เป็นปรัชญาของ UNIX การทำแบบนี้จะทำให้คุณเก่งกว่าคนรอบข้างและคุณจะได้รับความเคารพจากคนที่เข้าใจ

ฉันมักจะใช้cat file | myprogramในตัวอย่าง บางครั้งฉันถูกกล่าวหาว่าใช้แมวอย่างไร้ประโยชน์ ( http://www.iki.fi/era/unix/award.html ) ฉันไม่เห็นด้วยด้วยเหตุผลดังต่อไปนี้:

มันง่ายที่จะเข้าใจสิ่งที่เกิดขึ้น

เมื่ออ่านคำสั่ง UNIX คุณคาดว่าจะมีคำสั่งตามด้วยอาร์กิวเมนต์ตามด้วยการเปลี่ยนเส้นทาง มันเป็นไปได้ที่จะใส่ได้ทุกที่เปลี่ยนเส้นทาง แต่มันจะไม่ค่อยเห็น - ดังนั้นคนจะมีช่วงเวลาที่ยากอ่านตัวอย่าง ฉันเชื่อ

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

อ่านง่ายกว่า

    program1 -o option -b option < foo | program2

หากคุณย้ายการเปลี่ยนเส้นทางไปที่จุดเริ่มต้นคุณจะสับสนกับผู้ที่ไม่คุ้นเคยกับไวยากรณ์นี้:

    < foo program1 -o option -b option | program2

และตัวอย่างควรเข้าใจง่าย

มันง่ายที่จะเปลี่ยน

หากคุณรู้ว่าโปรแกรมสามารถอ่านได้จาก cat คุณสามารถสมมติว่ามันสามารถอ่านเอาต์พุตจากโปรแกรมใด ๆ ที่ส่งออกไปยัง STDOUT และทำให้คุณสามารถปรับให้เข้ากับความต้องการของคุณเองและรับผลลัพธ์ที่คาดการณ์ได้

มันเน้นว่าโปรแกรมไม่ล้มเหลวถ้า STDIN ไม่ใช่ไฟล์ปกติ

มันไม่ปลอดภัยที่จะสมมติว่าถ้าprogram1 < fooทำงานแล้วก็cat foo | program1จะทำงาน แต่ก็เป็นในทางปฏิบัติปลอดภัยที่จะคิดตรงข้าม โปรแกรมนี้ทำงานถ้า STDIN เป็นไฟล์ แต่ล้มเหลวหากอินพุตเป็นไพพ์เนื่องจากใช้การค้นหา:

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

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

ฉันได้ดูบทลงโทษที่ประสิทธิภาพในhttp://oletange.blogspot.dk/2013/10/useless-use-of-cat.htmlข้อสรุปไม่ได้ใช้cat file |หากความซับซ้อนของการประมวลผลคล้ายกับ grep อย่างง่าย และประสิทธิภาพมีความสำคัญมากกว่าความสามารถในการอ่าน สำหรับสถานการณ์อื่น ๆcat file |ก็โอเค

ฉันคิดว่าตำแหน่งที่ถูกคนบางคนให้ความเห็นเกี่ยวกับสิ่งที่เป็น UUOC คือถ้าใครเข้าใจ Unix และไวยากรณ์ของเชลล์คน ๆ นั้นจะไม่ใช้ cat ในบริบทนั้น มันถูกมองว่าเหมือนกับการใช้ไวยากรณ์ที่ไม่ดี: ฉันสามารถเขียนประโยคโดยใช้ไวยากรณ์ที่ไม่ดีและยังคงได้คะแนน แต่ฉันยังแสดงให้เห็นถึงความเข้าใจที่ไม่ดีของฉันเกี่ยวกับภาษาและการต่อเติมการศึกษาที่ไม่ดีของฉัน ดังนั้นการพูดว่าสิ่งที่เป็น UUOC นั้นเป็นอีกวิธีหนึ่งในการพูดว่าบางคนไม่เข้าใจสิ่งที่พวกเขากำลังทำอยู่

ถ้าหากคุณกำลังประมวลผลไปป์ไลน์จากบรรทัดคำสั่งมันจะใช้เวลาน้อยลงสำหรับเครื่องที่จะดำเนินการcat somefile |มากกว่าที่คุณคิดว่าจะใช้งาน< somefileได้มีประสิทธิภาพมากขึ้นหรือไม่ มันไม่สำคัญ

ฉันไม่ได้ตระหนักถึงรางวัลจนกระทั่งทุกวันนี้เมื่อมือใหม่บางคนพยายามตรึง UUOC ไว้กับฉันเพื่อรับคำตอบข้อใดข้อหนึ่งของฉัน cat file.txt | grep foo | cut ... | cut ...มันเป็น ฉันให้ชิ้นส่วนของความคิดของฉันและหลังจากทำเช่นนั้นไปเยี่ยมลิงค์ที่เขาให้ฉันหมายถึงต้นกำเนิดของรางวัลและการปฏิบัติของการทำเช่นนั้น การค้นหาเพิ่มเติมทำให้ฉันมีคำถามนี้ ค่อนข้างน่าเสียดายที่แม้จะมีการพิจารณาอย่างมีสติไม่มีคำตอบรวมถึงเหตุผลของฉัน

ฉันไม่ได้ตั้งใจจะป้องกันเมื่อให้ความรู้แก่เขา ในทุก ๆ ปีในวัยเด็กของฉันฉันจะได้เขียนคำสั่งเป็นgrep foo file.txt | cut ... | cut ...เพราะเมื่อใดก็ตามที่คุณทำบ่อยครั้งgrepที่คุณได้เรียนรู้การจัดวางของอาร์กิวเมนต์ไฟล์และมันก็รู้ว่าพร้อมที่แรกคือรูปแบบและคนต่อมาเป็นชื่อไฟล์

มันเป็นตัวเลือกที่มีสติเมื่อฉันตอบคำถามด้วยcatคำนำหน้าบางส่วนเนื่องจากเหตุผลของ "รสนิยมที่ดี" (ในคำพูดของ Linus Torvalds) แต่ส่วนใหญ่สำหรับเหตุผลที่น่าสนใจของฟังก์ชั่น

เหตุผลหลังสำคัญกว่าดังนั้นฉันจะเอามันออกก่อน เมื่อฉันเสนอไปป์ไลน์เป็นวิธีแก้ปัญหาฉันคาดว่าจะสามารถใช้ซ้ำได้ มีโอกาสมากที่จะเพิ่มท่อส่งเมื่อสิ้นสุดหรือต่อท่อไปอีกท่อหนึ่ง ในกรณีที่มีการโต้แย้งไฟล์ไปยังสกรู grep ขึ้นสามารถนำมาใช้และค่อนข้างเป็นไปได้ทำเช่นนั้นอย่างเงียบ ๆโดยไม่มีข้อความข้อผิดพลาดถ้าอาร์กิวเมนต์ไฟล์ที่มีอยู่ I. e. grep foo xyz | grep bar xyz | wcจะทำให้คุณมีวิธีการหลายเส้นในxyzมีbarในขณะที่คุณจะคาดหวังว่าจำนวนของสายที่มีทั้งในและfoo barต้องเปลี่ยนอาร์กิวเมนต์เป็นคำสั่งในไปป์ไลน์ก่อนที่จะใช้มันมีแนวโน้มที่จะเกิดข้อผิดพลาด เพิ่มความเป็นไปได้ของความล้มเหลวเงียบและกลายเป็นวิธีปฏิบัติที่ร้ายกาจโดยเฉพาะ

เหตุผลก่อนหน้านี้ไม่สำคัญเช่นกันเพราะ "รสนิยมดี" เป็นเพียงเหตุผลที่เป็นสัญชาตญาณที่เข้าใจง่ายสำหรับสิ่งต่าง ๆ เช่นความล้มเหลวเงียบ ๆ ที่คุณไม่สามารถคิดได้ในขณะที่บางคนที่ต้องการการศึกษาพูดว่า "แต่ไม่ใช่ แมวตัวนั้นไร้ประโยชน์ "

อย่างไรก็ตามฉันจะพยายามทำให้เหตุผล "รสชาติดี" ในอดีตที่ฉันกล่าวถึงด้วย เหตุผลนั้นเกี่ยวข้องกับการออกแบบมุมฉากของ Unix grepไม่ได้cutและไม่ได้ls grepดังนั้นอย่างน้อยที่สุดก็grep foo file1 file2 file3ขัดกับจิตวิญญาณการออกแบบ cat file1 file2 file3 | grep fooวิธีทำมุมฉากของมันคือ ตอนนี้grep foo file1เป็นเพียงกรณีพิเศษของgrep foo file1 file2 file3และถ้าคุณไม่ปฏิบัติต่อมันเหมือนกันคุณอย่างน้อยก็ใช้วงจรนาฬิกาสมองที่พยายามหลีกเลี่ยงรางวัลแมวที่ไร้ประโยชน์

นั่นนำเราไปสู่การโต้แย้งที่grep foo file1 file2 file3เชื่อมโยงกันและcatเชื่อมโยงกันดังนั้นจึงเหมาะสมcat file1 file2 file3แต่เพราะcatไม่ต่อเนื่องกันcat file1 | grep fooดังนั้นเราจึงละเมิดวิญญาณของทั้งcatUnix และยิ่งใหญ่ ถ้าเป็นเช่นนั้นแล้วยูนิกซ์จะต้องใช้คำสั่งที่แตกต่างกันในการอ่านเอาต์พุตของไฟล์หนึ่งไฟล์และถ่มน้ำลายลงไปที่ stdout (ไม่ใช่การแบ่งหน้ามัน ดังนั้นคุณจะมีสถานการณ์ที่คุณพูดcat file1 file2หรือคุณพูดdog file1และอย่าลืมที่จะหลีกcat file1เลี่ยงการได้รับรางวัลอย่างเป็นเรื่องเป็นราวขณะเดียวกันก็หลีกเลี่ยงdog file1 file2เนื่องจากหวังว่าการออกแบบของdogจะทำให้เกิดข้อผิดพลาดหากระบุไฟล์หลายไฟล์

หวังว่า ณ จุดนี้คุณจะเห็นอกเห็นใจกับนักออกแบบ Unix ที่ไม่รวมคำสั่งแยกเพื่อแยกไฟล์ออกเป็น stdout ในขณะเดียวกันก็ตั้งชื่อcatให้เรียงต่อกันแทนที่จะให้ชื่ออื่น <edit>มีสุนัขดังกล่าวโชคร้าย<ผู้ประกอบการ มันเป็นเรื่องโชคร้ายที่วางไว้ที่ส่วนท้ายของท่อเพื่อป้องกันการประกอบง่าย ไม่มีวิธีทำความสะอาดทาง syntactically หรือสกอร์เพื่อวางไว้ที่จุดเริ่มต้น มันเป็นเรื่องที่โชคร้ายที่ไม่ได้อยู่ในเกณฑ์ทั่วไปดังนั้นคุณจึงเริ่มต้นกับสุนัข แต่เพียงเพิ่มชื่อไฟล์อื่นถ้าคุณต้องการให้มันถูกประมวลผลหลังจากที่ก่อนหน้านี้ ( >ในทางกลับกันก็ไม่ได้แย่ไปกว่าครึ่งแล้วมันมีตำแหน่งที่เกือบสมบูรณ์แบบในตอนท้ายโดยทั่วไปแล้วมันไม่ได้เป็นส่วนที่นำกลับมาใช้ใหม่ได้ของไปป์ไลน์ดังนั้นจึงเป็นสัญลักษณ์ที่โดดเด่น)</edit>

คำถามต่อไปคือเหตุผลที่จำเป็นต้องมีคำสั่งที่คายไฟล์หรือทำการต่อไฟล์หลายไฟล์เข้ากับ stdout โดยไม่ต้องดำเนินการใด ๆ เพิ่มเติม? เหตุผลหนึ่งคือการหลีกเลี่ยงคำสั่ง Unix ทุกคำสั่งที่ทำงานกับอินพุตมาตรฐานเพื่อทราบวิธีแยกอาร์กิวเมนต์ไฟล์บรรทัดคำสั่งอย่างน้อยหนึ่งอาร์กิวเมนต์และใช้เป็นอินพุตหากมีอยู่ เหตุผลที่สองคือการหลีกเลี่ยงผู้ใช้ต้องจำ: (a) ที่ขัดแย้งชื่อไฟล์ไป; และ (b) หลีกเลี่ยงข้อบกพร่องไปป์ไลน์แบบเงียบตามที่กล่าวไว้ข้างต้น

นั่นทำให้เรารู้ว่าทำไมถึงgrepมีเหตุผลพิเศษ เหตุผลคือการอนุญาตให้ผู้ใช้คล่องแคล่วสำหรับคำสั่งที่ใช้บ่อยและแบบสแตนด์อโลน (แทนที่จะเป็นไพพ์ไลน์) มันเป็นการประนีประนอมเล็กน้อยของ orthogonality สำหรับกำไรที่สำคัญในการใช้งาน คำสั่งไม่ทั้งหมดควรได้รับการออกแบบด้วยวิธีนี้และคำสั่งที่ไม่ได้ใช้บ่อยควรหลีกเลี่ยงตรรกะเพิ่มเติมของอาร์กิวเมนต์ไฟล์อย่างสมบูรณ์ (จำไว้ว่าตรรกะพิเศษนำไปสู่ความเปราะบางที่ไม่จำเป็น grepยกเว้นเป็นข้อโต้แย้งที่จะอนุญาตให้ไฟล์เช่นในกรณีของ (โดยวิธีการทราบที่lsมีเหตุผลที่แตกต่างกันโดยสิ้นเชิงที่จะไม่เพียง แต่ยอมรับ แต่ค่อนข้างต้องใช้อาร์กิวเมนต์ไฟล์)

ในที่สุดสิ่งที่สามารถทำได้ดีกว่าคือถ้าคำสั่งพิเศษเช่นgrep(แต่ไม่จำเป็นls) จะสร้างข้อผิดพลาดหากอินพุตมาตรฐานพร้อมใช้งาน นี่คือเหตุผลเพราะคำสั่งรวมถึงตรรกะที่ละเมิดจิตวิญญาณของมุมมองของ Unix ยิ่งใหญ่เพื่อความสะดวกของผู้ใช้ เพื่อความสะดวกของผู้ใช้เพิ่มเติมเช่นเพื่อป้องกันความทุกข์ที่เกิดจากความล้มเหลวเงียบคำสั่งดังกล่าวไม่ควรลังเลที่จะละเมิดการละเมิดของตัวเองโดยแจ้งเตือนผู้ใช้หากมีความเป็นไปได้ของความล้มเหลวเงียบ

ในการป้องกันการไร้ประโยชน์ Uses of Cat

(วรรคสองสามข้อเพื่อช่วยปรับสมดุลของคลื่นสึนามิในการแสดงความคิดเห็นต่อการปฏิบัตินี้)

ฉันใช้ทุบตีมานานหลายปีทั้งในฐานะเชลล์และเป็นภาษาสคริปต์สำหรับสคริปต์ขนาดเล็ก (และบางครั้งก็น่าเสียใจสำหรับคนที่ไม่ได้เล็กมาก) นานมาแล้วฉันได้เรียนรู้เกี่ยวกับ "การใช้ประโยชน์จากแมว" (UUoC) ฉันยังคงมีความผิดอย่างน้อยทุกสัปดาห์ แต่พูดตามตรงฉันไม่ค่อยรู้สึกว่าถูกบังคับเล็กน้อยเพื่อหลีกเลี่ยงมัน ฉันเชื่อว่าการใช้catvs < fileเป็นเรื่องเกี่ยวกับรสนิยมมากกว่าความแตกต่างทางเทคนิคและฉันเขียนคำตอบนี้เพื่อปกป้องผู้คนใหม่ ๆ ใน Linux ที่แบ่งปันรสนิยมของฉันcatจากการคิดว่ามีบางอย่างผิดปกติเกี่ยวกับวิธีการของพวกเขา (และสังเกตโอกาสที่มีอยู่) เช่นเดียวกับ Linus Torvalds ฉันเชื่อว่าบ่อยครั้งที่รสชาติมีความสำคัญมากกว่าความสามารถ นั่นไม่ได้หมายความว่ารสนิยมของฉันดีกว่าของคุณ แต่มันก็หมายความว่าหากบางสิ่งมีรสชาติไม่ดีฉันจะไม่ทำโดยไม่ได้รับสิ่งที่คู่ควร

เห็นได้ชัดว่าเหมือนผู้เขียนคำถามที่ฉันรู้สึกว่าการใช้ cat นั้นเป็นธรรมชาติมากเมื่อทำงานกับ REPL เช่นทุบตีซึ่งฉันกำลังสำรวจปัญหาโดยการสร้างคำสั่งที่ซับซ้อนเพิ่มขึ้น นี่เป็นตัวอย่างทั่วไปมาก: ฉันมีไฟล์ข้อความและไม่รู้อะไรเกี่ยวกับมันมากนัก ฉันจะพิมพ์cat fileเพื่อรับรสชาติของเนื้อหา หากการส่งออกมากเกินไปผมจะตีลูกศรของฉันขึ้นและขึ้นอยู่กับสถานการณ์ฉันจะเพิ่ม| headหรือ| grep fooหรือ| what_everขยายคำสั่งก่อนหน้าของฉันโดยท้ายขั้นตอนการประมวลผล วิธีนี้เพิ่มขึ้นจากคำสั่งง่ายๆไปยังขั้นตอนที่ซับซ้อนมากขึ้นโดยการเพิ่มขั้นตอนการประมวลผลหนึ่งหลังจากที่อีกคนรู้สึกเป็นธรรมชาติมากสำหรับฉัน (ฉันทำแบบเดียวกันกับ ipython และฉันชอบวิธีนี้pyfunctionalและเครื่องมือการเขียนโปรแกรมที่คล้ายกันครอบคลุมสไตล์นี้) ดังนั้นเมื่อทำงานในเปลือกทุบตีฉัน 'm มั่นใจว่าขัดขวางการไหลของฉันที่จะเอาcatเป็นไร้ประโยชน์มากขึ้นกว่าปล่อยให้มันเป็นและทุกข์ทรมาน ... ดีผลที่ทุกคนใน 99.9% ของกรณีที่

แน่นอนเมื่อเขียนสิ่งต่าง ๆ สคริปต์อาจเปลี่ยนแปลง แต่แม้เมื่อเขียนสคริปต์มันเป็นความคิดของฉันว่าคนที่เยาะเย้ย UUoC ละเว้นบทเรียนที่สำคัญนี้โดยมีจิตใจดี: "การเพิ่มประสิทธิภาพก่อนกำหนดเป็นรากของความชั่วร้ายทั้งหมด" และถ้าคุณไม่ได้ทำอะไรผิดปกติมันเป็นเรื่องยากสำหรับ UUoC ที่จะต้องเพิ่มประสิทธิภาพ แน่นอนคุณต้องรู้ว่าอะไรไม่มีประสิทธิภาพเกี่ยวกับเรื่องนี้ (เป็นการเรียกกระบวนการพิเศษ BTW เนื่องจากมีเพียงไม่กี่คนที่พูดถึงมัน) การมีความรู้นั้นถ้าคุณทำงานกับระบบที่หายากเหล่านั้นซึ่งการเรียกใช้กระบวนการมีราคาแพง (เช่นระบบฝังตัวบางตัวหรือ CygWin ในระดับที่น้อยกว่า) คุณจะรู้ว่าต้องทำอย่างไรหากสถานการณ์พิเศษต้องการ ตัวอย่างเช่นหากคุณพบว่าตัวเองโทรcatหลายครั้งต่อวินาทีในลูป (BTW หากคุณพบว่าตัวเองอยู่ในตำแหน่งนั้นถามตัวเองว่าการทุบตีเป็นเครื่องมือที่เหมาะสมสำหรับงานหรือไม่) อีกครั้งว่า: "Make แรกที่มันทำงานอย่างถูกต้องแล้วเพิ่มประสิทธิภาพของมันถ้าจำเป็น"

และคุณจะอธิบายสึนามิที่บ่นเกี่ยวกับ UUoC Nick ได้อย่างไร

นอกจากนี้ทุกคนไม่ได้มีรสชาติของฉันผมเชื่อว่าเป็นส่วนสำคัญของทำไมหลายคนบ่นเกี่ยวกับ UUoC ไม่ได้ทางเทคนิค แต่มนุษย์ส่วนใหญ่ยูนิกซ์มาใหม่จะไม่ทราบเกี่ยวกับ< file commandสำนวนจึงเป็นที่ดึงดูดให้คนที่มีประสบการณ์มากขึ้นในการเล่น"เก่าคุรุ "กับพวกเขา เขาจะมีโอกาสใช้คำพูดแปลก ๆ ("การเรียกใช้กระบวนการ") และแตะที่เรื่องที่รักของ "การเพิ่มประสิทธิภาพ" รับประกันความประทับใจที่ดีดังนั้นจึงยากที่จะต้านทาน จากนั้นผู้มาใหม่จะใช้คำแนะนำของปราชญ์ที่ใบหน้าและเป็นเวลานานจะเล่นให้กับผู้อื่นในฐานะ "ความจริงเท่านั้น" (และลงคะแนนคำตอบนี้ :-) ข้อความตลก: อาจเป็นเรื่องง่ายมากที่จะแก้ไข bash เพื่อหลีกเลี่ยงความไร้ประสิทธิภาพของ UUoC ที่ใคร ๆ ก็สงสัยว่าทำไมไม่มีใครเพิ่มคุณสมบัตินี้หรือสร้าง< filenameแมวไฟล์หลังจากหลายปี วิญญาณที่มืดมนจะแนะนำว่าแฮกเกอร์ที่มีหนวดสีเทาบางคนชอบปล่อยโอกาสให้เราเยาะเย้ย ;-)

สิ่งที่ดีจริงๆคือเชลล์ที่สนับสนุนไวยากรณ์เช่น:

< filename cmd | cmd2 cmd2arg1... | cmd3

ในขณะเดียวกันฉันคิดว่าcat filename | realcmd1...เป็นที่ยอมรับเนื่องจากมันทำให้ไวยากรณ์เป็นมาตรฐานด้วยคำสั่งเริ่มต้นที่ต้องการชื่อไฟล์เป็นอาร์กิวเมนต์

สำหรับทุกคนที่พูดว่าแมวเป็นที่ยอมรับที่จะใช้เพราะมัน "กลิ่น" ดีกว่าหรือ "อ่านง่ายขึ้น" ฉันจะพูดแค่นี้:

สำหรับคุณอาจจะ ... แต่ไม่ใช่สำหรับคนอื่น ๆ ที่อาจอ่านหรือพยายามที่จะเข้าใจรหัสของคุณ หากคุณจะไม่พยายามสั่งสอนผู้อื่นด้วยตัวอย่างหรือแบ่งปันรหัสของคุณโปรดใช้มันเพื่อการพักผ่อนของคุณเอง

ฉันจะเพิ่มความคิดเห็นนี้เป็นเวลานานผู้ใช้ Linux และผู้ดูแลระบบ / วิศวกร ... (และมีพวกเราหลายคน) มันทำให้ตาของเรามีเลือดออกที่จะเห็นสิ่งนี้ ทำไม? เพราะมันใช้ทรัพยากรบนระบบที่เราควบคุมทรัพยากรอย่างแน่นหนา คำสั่ง cat และไปป์นั้นใช้หน่วยความจำเพิ่มเติมและตัวจัดการไฟล์ที่ไร้ประโยชน์อย่างสมบูรณ์ คุณได้ผูกทรัพยากรที่ระบบของฉันต้องการฟรีและคุณได้รับอะไรที่สามารถอธิบายการใช้ทรัพยากรเหล่านี้ นี่คือขนาดใหญ่ไม่ไม่

ตอนนี้ฉันสามารถนั่งที่นี่และอภิปรายเรื่องต่าง ๆ เช่นกลิ่นรหัสหรืออ่านได้ทุกวันกับทุกคน แต่ในตอนท้ายของวันมันเป็นเรื่องของการเขียนหรือผิดและทุกครั้งที่คุณใช้ทรัพยากรในระบบและไม่ทำอะไรเลย ... มันผิด.

ในฐานะผู้ใช้ตามบ้านคุณสามารถเรียนรู้จากคำแนะนำของฉันและเรียนรู้วิธีที่ดีกว่าในการทำสิ่งต่าง ๆ หรือคุณสามารถเลือกที่จะ "แมว" ตาบอดทางเลือกของคุณ ... แต่รู้ว่าถ้าคุณใช้วิธีนี้อย่างเปิดเผยคุณจะถูกเรียก ในการฝึกฝนนี้ตลอดเวลาและคุณจะต้องยอมรับอย่างเงียบ ๆ ว่าถูกต้องและคุณดื้อเพราะมันเป็นเรื่องจริง :-)