รวมเครื่องมือ Modern Linux: CLI รุ่นใหม่ที่มาแทนคำสั่งเดิม

• แนะนำเครื่องมือบรรทัดคำสั่งสมัยใหม่หลากหลายตัวที่ช่วย เพิ่มประสิทธิภาพการทำงานบนลินุกซ์
• มีทั้งเครื่องมือที่มาแทนหรือเสริมความสามารถของ คำสั่ง Unix แบบดั้งเดิม ในสไตล์โมเดิร์น และอีกหลายตัวที่ เน้นประสิทธิภาพโดยพัฒนาด้วย Rust, Go เป็นต้น

เครื่องมือสำหรับดูและสำรวจไฟล์

• bat : เวอร์ชันอัปเกรดของคำสั่ง cat ที่เพิ่ม syntax highlighting และการทำงานร่วมกับ git
• exa : ตัวแสดงรายการไฟล์แบบโมเดิร์น ที่มาแทน ls/tree แต่ปัจจุบันหยุดบำรุงรักษาแล้ว
• eza : ฟอร์กของ exa ที่มอบ ls/tree แบบสมัยใหม่
• lsd : ls เจเนอเรชันใหม่ ที่รองรับความเข้ากันได้กับของเดิมและแสดงผลได้สวยงามยิ่งขึ้น
• broot : ตัวสำรวจไฟล์แบบ โครงสร้างต้นไม้ ที่เสริมความสามารถด้านการนำทาง
• nnn : ตัวจัดการไฟล์บนเทอร์มินัลแบบ เบาและเร็ว

การวิเคราะห์ขนาดไฟล์และไดเรกทอรี

• ncdu : มอบ อินเทอร์เฟซของ du ที่เข้าใจง่าย แบบข้อความ
• dust : ตัวแทน du ที่ใช้ง่ายกว่า พัฒนาด้วย Rust
• duf : เครื่องมือวิเคราะห์การใช้ดิสก์ที่ ใช้งานสะดวกกว่า df แบบเดิม

การค้นหาไฟล์และโค้ด

• fd : ตัวแทน find ที่กระชับและรวดเร็ว พร้อมการใช้งานที่ยอดเยี่ยม
• ripgrep : ตัวแทน grep ความเร็วสูงมาก ที่รองรับ gitignore
• ag : เครื่องมือค้นหาโค้ดที่คล้าย ack แต่เร็วกว่า
• fzf : เครื่องมือ fuzzy search อเนกประสงค์ ใช้งานได้ในไปป์ไลน์และอีกหลายบริบท
• bfs : ตัวแทน find ที่ทำงานบนพื้นฐาน breadth-first

ตัวดู Git/diff ในเทอร์มินัล

• delta : แสดงผลลัพธ์จาก git และ diff ให้ อ่านง่ายและมองเห็นภาพมากขึ้น

ประวัติและการจัดการคำสั่ง

• mcfly : ยกระดับ การค้นหาและสำรวจ shell history อย่างมาก พร้อมคุณภาพการค้นหาที่ดีขึ้นและ UI ที่เข้าใจง่าย

การประมวลผลข้อมูล

• choose : ตัวแทนที่ตรงไปตรงมาและเร็วกว่า cut และบางส่วนของ awk
• jq : ตัวแยกวิเคราะห์ข้อมูลที่ใช้งานได้เหมือน sed สำหรับ JSON โดยเฉพาะ
• sd : เครื่องมือแทน sed ที่ทำ find/replace ได้คุ้นเคยกว่า

การมอนิเตอร์ระบบ/โปรเซส

• bottom : ตัวมอนิเตอร์ระบบและโปรเซสแบบกราฟิก ที่ทำงานข้ามแพลตฟอร์ม
• glances : เวอร์ชันปรับปรุง ของ top/htop
• gtop : ตัวมอนิเตอร์ระบบแบบแดชบอร์ดบนเทอร์มินัล
• procs : คำสั่งแทน ps ที่เขียนด้วย Rust

Benchmarking และเครือข่าย

• hyperfine : เครื่องมือทำ benchmark สำหรับ CLI แบบอัตโนมัติ
• gping : เครื่องมือ ping ที่มี ความสามารถในการแสดงกราฟ

HTTP client

• httpie : HTTP client สำหรับ CLI ที่ทันสมัยและเป็นมิตรต่อผู้ใช้ เหมาะกับการทดสอบ API สำหรับนักพัฒนา
• curlie : เครื่องมือที่รวมพลังของ curl เข้ากับ ความใช้งานง่ายของ httpie
• xh : เครื่องมือแทน httpie ที่ เน้นประสิทธิภาพ

การย้ายไดเรกทอรีและเอดิเตอร์

• zoxide : คำสั่ง cd อัจฉริยะ ที่ได้แรงบันดาลใจจาก z
• micro : เอดิเตอร์ข้อความบนเทอร์มินัล ที่มีความสามารถทันสมัย

ยูทิลิตี CLI หน้าใหม่

• up : เครื่องมือไปป์ไลน์พร้อมพรีวิวแบบเรียลไทม์ ดูผลลัพธ์คำสั่งได้ทันที

เครื่องมือช่วยเหลือและเอกสาร

• ManKier : man page แบบสรุปย่อ พร้อมคำอธิบายคำสั่งที่อ่านง่าย
• tldr : สรุป man page แบบกระชับ เน้นตัวอย่างการใช้งาน
• tealdeer : เวอร์ชัน tldr ที่พัฒนาด้วย Rust และทำงานได้รวดเร็ว
• explainshell : วิเคราะห์อาร์กิวเมนต์ของคำสั่งอัตโนมัติและ อธิบายความหมายแบบมองเห็นภาพ
• cheat.sh : บริการช่วยเหลือออนไลน์ที่รวม tldr และ cheatsheet เข้าด้วยกัน

เครื่องมือ GUI

• baobab : ตัววิเคราะห์การใช้ดิสก์แบบ GUI
• stacer : เครื่องมือ GUI สำหรับปรับแต่งและมอนิเตอร์ระบบ รวมถึงการจัดการบริการ

[GN⁺]

ความคิดเห็นบน Hacker News

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

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

  • บางเครื่องมือดีกว่ามากจนคุ้มค่าพอ แม้จะติดตั้งยุ่งยากขึ้นนิดหน่อย ฉันใช้เครื่องมือดั้งเดิมได้ดี แต่ fd กับ ripgrep ดีกว่าเสมอ

  • เหตุผลที่ฉันชอบ Nix มากจริง ๆ คือมันทำให้มีเซ็ตอัปแบบเดียวกันได้แทบทุกสภาพแวดล้อม (ตราบใดที่สภาพแวดล้อมที่ฉันใช้คือ linux หรือ macOS ฉันก็สนใจแค่สองอย่างนี้) มีวิธีติดตั้ง Nix หลายแบบที่ไม่ต้องใช้สิทธิ์ root เลยทำให้สร้างสภาพแวดล้อมเดิมของตัวเองได้ทุกที่ แน่นอนว่าถ้าไม่มี Nix เครื่องมือดั้งเดิมก็ยังใช้งานได้ดีอยู่แล้ว ไม่จำเป็นต้องเลือกแค่อย่างใดอย่างหนึ่ง เรามีได้ทั้งคู่

  • เวลาติดตั้ง OS ใหม่ ยังไงก็ต้องลงแพ็กเกจที่ต้องใช้ผ่าน apt-get, pacman, dnf, brew อยู่แล้ว และยังต้องลงเบราว์เซอร์หรือเอดิเตอร์ที่ตัวเองใช้เพิ่มอีก เวลา SSH เข้าเครื่องก็ใช้ GUI ไม่ได้อยู่แล้ว แต่ก็ไม่ใช่เหตุผลที่จะต้องหลีกเลี่ยงเครื่องมือ GUI ฉันไม่คิดว่าการมีชุดเครื่องมือคนละแบบระหว่างสภาพแวดล้อมส่วนตัวกับสภาพแวดล้อมสาธารณะจะเป็นปัญหาใหญ่ ตัวอย่างเช่น bat ไม่ได้มาแทน cat แบบสมบูรณ์ แต่มันเพิ่ม syntax highlighting ที่ช่วยให้ชีวิตสะดวกขึ้น ถ้าเครื่องไหนไม่ได้ติดตั้งไว้ก็แค่ไม่ใช้

  • ถ้ามองตามปรัชญา UNIX เรื่อง “ทำสิ่งเดียวให้ดี” ฉันคิดว่าแก่นของยูทิลิตีเรียบง่ายพวกนี้ก็คือ หากมีทางเลือกที่ดีกว่าเกิดขึ้น ก็ควรถูกแทนที่ได้ง่าย การเรียนรู้เครื่องมือคลาสสิกก่อนนั้นถูกต้องสำหรับเส้นทางอาชีพ แต่ฉันคิดว่าควรเรียนรู้ทางเลือกใหม่ ๆ ด้วยเหมือนกัน สำหรับฉัน ทางเลือกที่ช่วยประหยัดเวลาอย่าง fd (แทน find), sd (แทน sed) มีประโยชน์มากกว่า bat หรือ eza

• ถ้าคุณต้องเชื่อมต่อเข้าเซิร์ฟเวอร์หลายร้อยเครื่อง ข้ามหลายเครือข่ายและลูกค้าหลายราย เครื่องมือคัสตอมแทบไม่มีค่าเลย เพราะใน 90% ของสภาพแวดล้อม เครื่องมือพวกนี้ไม่ได้ถูกติดตั้งไว้ ฉันเพิ่มแค่ไม่กี่อย่างลงใน ansible-config แล้วปล่อยผ่านระบบอัตโนมัติ โดยพยายามให้ลิสต์สั้นที่สุด 95% ของระบบที่ฉันดูแลคือ debian หรือ ubuntu เลยมี baseline คล้ายกันมาก และฉันก็แค่เพิ่ม ack, etckeeper, vim, pv, dstat เข้าไป

  • ประเด็นสำคัญคือคำว่า “เซิร์ฟเวอร์” ตรงนี้ โปรแกรมปรับปรุงเล็ก ๆ สำหรับงาน sysadmin ส่วนใหญ่อาจไม่ค่อยมีค่า แต่บางตัวเป็น dev tool จริง ๆ สำหรับสภาพแวดล้อมพัฒนา ซึ่งติดตั้งแค่บนเครื่องไม่กี่เครื่องที่ใช้เขียนโปรแกรมก็พอ เช่น ripgrep (recursive grep ที่ยอดเยี่ยม), jq (ตัวประมวลผล JSON ที่ไม่มีของเทียบในชุดเครื่องมือ unix พื้นฐาน), hyperfine (benchmarking)

  • การต้องสลับทำงานระหว่าง Windows กับ Linux ทำให้เครื่องมือข้ามแพลตฟอร์มที่ยอดเยี่ยมอย่าง ripgrep สะดวกมากจริง ๆ

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

  • emacs ทำงานแทบจะเหมือนระบบปฏิบัติการหนึ่งระบบ ทำให้มีสภาพแวดล้อมที่คุ้นเคยได้ไม่ว่าบนระบบไหน ถึงได้มีคำพูดว่า "GNU is my operating system, linux is just the current kernel" จากมุมมองของแอดมินรุ่นเก๋า นี่จึงเป็นเหตุผลที่ฉันแนะนำคนที่เริ่มเรียนลินุกซ์ให้เปิดคำสั่ง info ก่อน แล้วอ่านคู่มือทั้งหมด ถ้าทำได้ คุณจะนำหน้าผู้ดูแลระบบส่วนใหญ่ไปไกลเลย พอรู้ว่ามีเครื่องมือ built-in อะไรบ้าง คู่มือก็ยอดเยี่ยมและช่วยให้เขียนสคริปต์ได้ง่าย ซึ่งนี่แหละคือหัวใจของปรัชญาลินุกซ์ สมัยก่อนเคยมีช่วงที่แม้แต่ nano ก็ยังไม่มี มีแค่ vi แต่ทุกวันนี้การเพิ่มเอดิเตอร์แบบ TUI ผ่านระบบอัตโนมัติ CI/CD ก็ง่ายมากแล้ว

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

• ฉันคิดว่าถ้ามีคอลัมน์เพิ่มในตารางว่า “เครื่องมือนี้แก้ปัญหาอะไร” ก็น่าจะดี และฉันไม่คิดว่า “เขียนด้วย rust” จะเป็นจุดต่างที่มีความหมาย

  • ฉันเคยมีประสบการณ์ในประชุมบริษัทที่มีคนอธิบายว่า “เขียนด้วย Go” คือจุดต่าง ฟังแล้วอึ้งมาก #facepalm

  • หลายรายการในตารางก็พูดถึงปัญหาจริงอยู่ เช่น “syntax highlight”, “ncurses interface”, “more intuitive” เพียงแต่ฉันคิดว่าคำอย่าง “เขียนด้วย rust”, “modern”, “better” ไม่ได้ช่วยอะไร

  • เป้าหมายหลักลำดับแรกของเครื่องมือส่วนใหญ่คือการปรับปรุง UX

  • การใช้ไลเซนส์ที่ไม่ใช่ GPL ก็ไม่ใช่จุดต่างเหมือนกัน

  • เครื่องมือหลายตัวในนี้ใช้งานบน Windows ได้ด้วย ซึ่งถือว่าดี

• ลิสต์เครื่องมือแบบนี้สนุกเสมอ คนส่วนใหญ่น่าจะได้ประโยชน์จากเครื่องมือในนี้อย่างน้อยสักหนึ่งหรือสองตัว ส่วนตัวฉันมองว่า ripgrep กับ jq เป็นของจำเป็น ripgrep เป็นตัวแทน grep ที่ดีที่สุดเท่าที่ฉันเคยใช้ และ jq ก็แก้ปัญหาที่ฉันต้องการจริง ๆ ฉันอาจลองใช้ lsd กับ dust ดูด้วย ถึงเครื่องมือใหม่บางตัวอาจไม่ตรงกับความต้องการของฉันโดยตรง แต่ฉันก็รู้สึกขอบคุณที่มีคนทุ่มเวลาให้กับเครื่องมือแบบนี้ มันเป็นเรื่องน่าทึ่งที่ช่วยทำให้กล่องเครื่องมือของชุมชนดีขึ้นทีละนิด

  • ถ้าให้เลือกก่อน ฉันน่าจะเลือก fzf เป็นอันดับแรก ชอบมากกว่า rg หรือ jq เสียอีก

  • ripgrep ทำงานต่างจาก grep ดังนั้นจริง ๆ แล้วมันไม่ใช่ตัวแทนแบบ drop-in เป็นโปรแกรมที่ยอดเยี่ยมก็จริง แต่ไม่ได้เข้ากันได้แบบสมบูรณ์

  • แอดมินลินุกซ์อย่างฉันต่างก็มีลิสต์แน่น ๆ แบบนี้ของตัวเอง ฉันวางสแตกฝั่งตัวเองโดยเน้นเครื่องมือสาย GPL และชอบฟอร์แมตจาก ikrima.dev อันนี้เป็นพิเศษ

• ฉันใช้ชีวิตอยู่ในเทอร์มินัล แต่เครื่องมือพวกนี้ไม่เคยแก้ปัญหาที่ฉันต้องการตอนนี้ หรือไม่ก็ไม่ได้ติดตั้งอยู่ในระบบของฉัน แต่กลับมีดาวบน GitHub เป็นหมื่น ๆ งงจริงว่ามันได้รับความนิยมขนาดนี้ได้ยังไง

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

  • ไม่ใช้ fzf เหรอ ชีวิตในเทอร์มินัลคงลำบากน่าดู มันมีประโยชน์มากเพราะผ่านปลั๊กอินของแต่ละเชลล์ คุณสามารถใช้ Ctrl+R เพื่อค้นหาแบบ fuzzy ใน bash_history หรือ Ctrl+T เพื่อค้นหาไฟล์ในไดเรกทอรีปัจจุบันได้ แทนที่จะต้องเรียกใช้ตรง ๆ

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

  • ถามด้วยความอยากรู้ว่า ถ้าใช้แค่เครื่องมือ unix ที่มีมาในระบบ มีวิธีที่สวยงามไหมที่จะทำ recursive grep โดยข้ามไฟล์ซ่อนอย่าง .git และค้นหาเฉพาะไฟล์นามสกุลที่กำหนด เช่นคำสั่ง rg -g '*.foo' bar เป็นแพตเทิร์นที่ฉันใช้บ่อยมาก เช่นเดียวกับการใช้ fd เพื่อหาไฟล์ที่ตรงกับ regex หรือ glob ฉันยังหาวิธีที่สะอาดตาด้วยเครื่องมือพื้นฐานไม่เจอ

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

• ในโหมดมืด ข้อความลิงก์มองแทบไม่เห็น ทำให้อ่านยากมาก

• ฉันคิดว่ามีแค่ jq ที่แก้ปัญหาจริงซึ่งเครื่องมือเดิมไม่สามารถจัดการได้ ส่วนที่เหลือส่วนใหญ่ก็เป็นแค่เรื่องรสนิยม ประสิทธิภาพ ไฮไลต์ หรือการเขียนด้วย rust

• อยากให้มีทีมสักทีมทำชุดเครื่องมือแบบ “suite” ที่ออกแบบพารามิเตอร์ สี ตาราง ฯลฯ ให้สอดคล้องกันทั้งหมด

• ฉันใช้ htop แทน top มานานเพราะเข้าถึงง่ายกว่า แต่ htop ไม่แสดง kernel thread เป็นค่าเริ่มต้น ทำให้มันกลายเป็นอุปสรรคเวลาหาสาเหตุของปัญหา หลังจากนั้นฉันก็กลับไปใช้ top เพราะมันแสดงข้อมูลครบและเชื่อถือได้มากกว่า ฉันมองว่า UI อย่าง htop/btop ออกแนวโชว์มากกว่าใช้งานจริง

• บทความนี้เป็นของปี 2023 แล้ว “เครื่องมือสมัยใหม่” ส่วนใหญ่คงอัปเดตไปแล้ว และอาจมีตัวใหม่ ๆ ที่กำลังเป็นกระแสออกมาอีก

  • เครื่องมือมีเยอะมาก เพราะฉะนั้นถึงจะรอดมาได้แค่ครึ่งเดียวก็คุ้มค่าแล้ว

  • ประสบการณ์ของฉันกลับตรงกันข้าม เครื่องมือส่วนใหญ่พวกนี้เป็นเพียงการ “ประดิษฐ์ซ้ำ” เครื่องมือ GNU พื้นฐานที่ทรงพลังมากอยู่แล้ว ถ้าคุณยอมใช้เวลาเรียนรู้มันให้ดี