ripgrep 15.0

 (github.com/BurntSushi)
2 คะแนน โดย GN⁺ 2025-10-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ripgrep 15.0 เป็นรุ่นหลักที่มีการอัปเดตหลากหลาย ทั้งการแก้บั๊ก ปรับปรุงประสิทธิภาพ และเพิ่มความสามารถใหม่
  • มีการแก้บั๊กหลายรายการเกี่ยวกับ การใช้กฎ gitignore และปรับ การใช้หน่วยความจำให้เหมาะสม เมื่อต้องจัดการไฟล์ขนาดใหญ่
  • เพิ่มการรองรับแพลตฟอร์ม Windows aarch64 และยุติการรองรับ powerpc64
  • ความสามารถใหม่บางส่วนได้แก่ รองรับ --json พร้อมแฟล็กทดแทนพร้อมกัน และรองรับวงเล็บปีกกาซ้อนใน globs
  • การปรับปรุง ประสิทธิภาพโดยรวม การแก้ข้อผิดพลาด และการเพิ่มความสะดวกในการใช้งาน ช่วยเพิ่มประสิทธิผลของนักพัฒนา

ภาพรวมของ ripgrep 15.0

ripgrep 15.0 เป็นรุ่นเมเจอร์ล่าสุดของ ripgrep โดยเน้นที่ การแก้บั๊ก การปรับปรุง ประสิทธิภาพ เล็กน้อย และการเพิ่ม ความสามารถใหม่ ขนาดเล็ก

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

การเปลี่ยนแปลงสำคัญ

  • แก้ไข บั๊กที่เกี่ยวข้องกับการจับคู่ gitignore หลายรายการ
    • แก้ปัญหาบั๊กที่ถูกรายงานบ่อยเกี่ยวกับการใช้กฎ gitignore ของไดเรกทอรีแม่
  • แก้บั๊ก การใช้หน่วยความจำเพิ่มขึ้น ที่เกิดขึ้นเมื่อประมวลผลไฟล์ gitignore ขนาดใหญ่มาก
  • เปลี่ยนให้ rg -vf file จับคู่ทั้งหมดเมื่อ file ว่างเปล่า
  • ตอนนี้แฟล็ก -r/--replace ทำงานร่วมกับ --json ได้อย่างถูกต้อง
  • รองรับการมองว่า รีโพซิทอรี Jujutsu(jj) บางประเภทเป็นเหมือนรีโพซิทอรี git ทำให้ ripgrep ปฏิบัติตาม gitignore ของ jj
  • Globs รองรับ วงเล็บปีกกาซ้อน

การรองรับแพลตฟอร์ม

  • มีการจัดเตรียมไบนารีรีลีสสำหรับ Windows aarch64 เพิ่มใหม่
  • จะไม่มีการจัดเตรียมไบนารีรีลีสสำหรับ powerpc64 อีกต่อไป
    • ยุติเนื่องจากปัญหาในเวิร์กโฟลว์ CI release และสามารถร้องขอได้หากต้องการการทดสอบและการรองรับ
  • ไบนารีของ ripgrep ถูกคอมไพล์ด้วย LTO (การเพิ่มประสิทธิภาพทั้งกระบวนการลิงก์) ซึ่งช่วยเพิ่มประสิทธิภาพเล็กน้อยและลดขนาดไฟล์

การปรับปรุงประสิทธิภาพ

  • บน Windows หากไม่ได้ใช้ตัวเลือก -z/--search-zip จะมีการ ปิดการค้นหา helper binary เพื่อเพิ่มประสิทธิภาพ
  • บน Windows มีการเพิ่มความเร็วด้วยการ ข้ามการทำ path normalization เมื่อแสดงผลไฮเปอร์ลิงก์
  • ปรับปรุงประสิทธิภาพการจัดการ ค่าขนาดใหญ่ เมื่อใช้ -A/--after-context

การแก้บั๊ก

  • แก้ไขปัญหาที่เกี่ยวข้องกับ gitignore หลายรายการ เช่น การไม่ใช้ gitignore ของไดเรกทอรีแม่
  • แก้ให้คำสั่ง rg -vf file กับไฟล์ว่างจับคู่ทั้งหมด
  • เพิ่มการจัดการให้ ไม่สนใจ UTF-8 BOM marker ใน .gitignore เป็นต้น
  • ปรับการใช้หน่วยความจำให้เหมาะสม เมื่อประมวลผลไฟล์ gitignore ขนาดใหญ่
  • แก้ข้อผิดพลาด การแสดงจำนวนไบต์ที่ค้นหา เมื่อใช้ --stats
  • แก้ข้อผิดพลาดในการจัดการ glob ที่ลงท้ายด้วย .
  • แก้ปัญหา การแสดงว่าเกินจำนวนแมตช์ เมื่อใช้ -m/--max-count ร่วมกับ -U/--multiline
  • เปลี่ยนให้เมื่อใช้แฟล็ก -r/--replace มีการ คงตัวปิดบรรทัด ไว้
  • แก้ข้อผิดพลาด การกลับด้าน exit code เมื่อใช้ -q --files-without-match ร่วมกัน
  • แก้ความไม่สอดคล้องของเอกสารระหว่าง -c/--count และ --files-with-matches
  • แก้ปัญหา panic ที่เกิดขึ้นไม่บ่อยกับนิพจน์ปรกติขนาดใหญ่และอินพุตขนาดใหญ่
  • จัดการการ escape ขีดกลางในชื่อแฟล็กตัวเลือกบน man page
  • จัดการการคอมไพล์แบบสแตติกของ PCRE2 ในรีลีส macOS aarch64
  • แก้บั๊กฟิลเตอร์ ละเว้นไดเรกทอรีแม่ เมื่อค้นหาไฟล์ซ่อนที่อยู่ใน whitelist
  • แก้ปัญหา สถิติสรุปไม่ถูกต้อง เมื่อใช้แฟล็ก --json
  • แก้ข้อผิดพลาดในการจัดการ gitignore เมื่อค้นหาด้วยพาธสัมบูรณ์และ global gitignore
  • แก้ปัญหา panic ที่เคยเกิดขึ้นเมื่อใช้ -U/--multiline ร่วมกับ -r/--replace

การปรับปรุงความสามารถ

  • ชุดประเภทไฟล์เริ่มต้นถูก ขยาย และ ปรับปรุง อย่างมาก
  • ปรับให้ -r/--replace เข้ากันได้กับ --json
  • ปรับปรุงระบบเติมคำสั่งอัตโนมัติของ fish shell ให้สะท้อน ไฟล์คอนฟิก ของ ripgrep
  • เพิ่ม italic เป็นคุณสมบัติสไตล์ที่ใช้กับ --color ได้
  • ปฏิบัติต่อไดเรกทอรี .jj เป็นรีโพซิทอรี git
  • เมื่อใช้มัลติเธรด เพิ่มความสามารถในการจัดคิวการค้นหาตาม ลำดับไฟล์ที่ระบุจาก CLI
  • เพิ่มอาร์ติแฟกต์รีลีส aarch64 สำหรับ Windows
  • เพิ่ม highlight color type ที่ช่วยให้จัดสไตล์ข้อความที่ไม่ตรงกันภายในบรรทัดที่มีการแมตช์ได้
  • เพิ่มความสามารถ nested alternates ให้กับ globs และ crate globset
  • ปรับปรุงการเติมคำสั่งอัตโนมัติของ --hyperlink-format บน bash, fish และ zsh

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-19
ความคิดเห็นบน Hacker News

  • ripgrep เป็นเครื่องมือที่ช่วยประหยัดเวลาให้ฉันได้มากจริง ๆ ตลอดหลายปีที่ผ่านมา เป็นสิ่งที่ต้องติดตั้งเป็นอย่างแรกทุกครั้งเมื่อเริ่มใช้ระบบใหม่ โดยเฉพาะเวลาสำรวจ codebase เก่า ๆ คือขาดไม่ได้เลย ข้อเสียดายนิดหนึ่งคือแม้จะใช้ตัวเลือก -F (มองเป็น literal) ก็ยังมีบางอักขระที่ถูกมองเป็นอักขระพิเศษและต้อง escape อยู่ดี จำไม่ได้แน่ชัดว่าเป็นตัวไหน แต่ถึงอย่างนั้นก็ยังดีใจทุกครั้งที่เห็น ripgrep ออกอัปเดตต่อเนื่อง

    • ถ้ายกตัวอย่างได้ว่ามีปัญหากับอักขระไหน จะช่วยอธิบายได้แบบเจาะจงมากขึ้น -F/--fixed-strings ปิดความสามารถของ regular expression ในแพตเทิร์นแบบ 100% และจะตีความเป็น literal เท่านั้น ถ้ายังต้อง escape อยู่ สาเหตุน่าจะมาจาก shell ที่บังคับให้ทำมากกว่า

  • rg เป็นเครื่องมือที่ให้ความรู้สึกเหมือนเวทมนตร์ แต่จริง ๆ แล้วมันคือผลลัพธ์ของวิศวกรรมที่ยอดเยี่ยม การปรับปรุงอย่างต่อเนื่อง และการดึงประสิทธิภาพของฮาร์ดแวร์สุดน่าทึ่งที่พวกเราใช้กันทุกวันออกมาได้อย่างเต็มที่ อีกทั้งยังเป็นนวัตกรรมที่เปิดทางให้นักพัฒนาสามารถสำรวจและทำความเข้าใจโค้ดได้เร็วขึ้น โดยไม่จำเป็นต้องสร้างมาตรฐานแยกต่างหากแบบ lsp

    • อยากรู้จริง ๆ ว่า smithing ในบริบทนี้หมายถึงอะไร

  • codebase ของ ripgrep เป็นตัวอย่างชั้นยอดของการ "เตรียมเครื่องดื่มแล้วนั่งลงบนเก้าอี้ตัวที่สบายที่สุด เพื่ออ่านซอฟต์แวร์คุณภาพสูงอย่างเพลิดเพลิน" คลิกไล่ดูโค้ดตรงนั้นตรงนี้แล้วต้องทึ่งตลอด

  • เหมือนกับ fd, rg เป็นเครื่องมือ command line ที่ใช้งานแล้วเพลินจริง ๆ ฉันชอบเครื่องมือใหม่ ๆ แบบอิงคำสั่งพวกนี้มาก

    • เพิ่งรู้ไม่นานมานี้ว่าผู้เขียน ripgrep กับ fd ทำงานอยู่ที่ Astral ถึงได้เข้าใจว่าทำไมซอฟต์แวร์ของ Astral ถึงดีขนาดนี้
    • ทั้งสองเครื่องมือทำงานได้ตรงกับสิ่งที่ฉันต้องการ 99% ตั้งแต่ค่าเริ่มต้นโดยแทบไม่ต้องใส่ออปชันอะไรเลย ช่วยประหยัดเวลาได้มาก เช่น แค่พิมพ์ rg <string> หรือ fd <string> ก็พอแล้ว

  • ฟีเจอร์ที่ส่วนตัวอยากให้เพิ่มคือแฟลก "extension" ที่ทำงานคล้าย -g แต่ตีความอาร์กิวเมนต์ที่ป้อนเข้าไปเป็นนามสกุลไฟล์ (เช่น rg -e c,h) เพราะเวลาจะใช้ glob pattern ส่วนใหญ่ก็เพื่อจับคู่นามสกุลไฟล์นี่แหละ

    • อยากถามว่าเคยเห็นแฟลก -t/--type ไหม สามารถใช้แบบ -tc ตามตัวอย่างได้ ถ้าเป็นนามสกุลที่ ripgrep ยังไม่มี ก็สามารถนิยาม type เองได้

  • ripgrep เป็นหนึ่งในเหตุผลหลักที่ทำให้ฉันเริ่มสนใจ rust มันทำงานได้สมบูรณ์มากจนพอรู้ว่าเขียนด้วย rust ก็ยิ่งอยากรู้จักภาษานี้มากขึ้น หลายปีผ่านไปจนถึงตอนนี้ก็ยังใช้ rg ทุกวัน

    • nibbles เป็นเหตุผลหลักที่ทำให้ฉันเริ่มสนใจ qbasic มันทำออกมาได้สมบูรณ์มาก พอรู้ว่าเขียนด้วย qbasic ก็เลยยิ่งสนใจ และนั่นทำให้ฉันได้ใช้ nibbles ทุกวัน

  • ไม่นานมานี้เพิ่งค้นพบตัวเลือก --replace และประทับใจมาก ใช้มันคู่กับ --type แล้วก็เสียดายที่ก่อนหน้านี้ไม่รู้เลยว่ามีฟีเจอร์ดี ๆ แบบนี้อยู่ ต่อจากนี้คงต้องอ่าน release notes ให้ละเอียดขึ้นและตามฟีเจอร์ใหม่ ๆ ให้ทันมากขึ้น อีกทั้งก็ดีใจที่มีการปรับปรุงการทำงานร่วมกับ jj

  • เป็นเครื่องมือที่ยอดเยี่ยมและใช้งานง่ายมาก ตอนแรกเริ่มใช้บน Linux ตอนนี้ก็ใช้บน Windows ด้วย เพราะเครื่องมือนี้ทำให้ตอนนี้ฉันนำ regular expression มาใช้ค้นหาโดยตรงแทน wildcard แล้ว

    • ดีกว่า grep แบบพื้นฐาน และคำสั่ง rg --files ก็มีประโยชน์ด้วย

  • สัปดาห์นี้ฉันทำ bash function สำหรับรัน ripgrep เฉพาะกับไฟล์ที่ git ติดตามไว้

      rgg() {
    readarray -d '' -t FILES < <(git ls-files -z)
    rg "${@}" "${FILES[@]}"
  }

    ทำให้ค้นหาได้เร็วขึ้นมากในไดเรกทอรีที่มีไฟล์ไบนารีหรือ dot file เยอะ ๆ ถ้าจะค้นหา dot file ต้องใช้ตัวเลือก -uu แต่ตัวเลือกนี้จะค้นหาไฟล์ไบนารีด้วย พอมีไฟล์เป็นร้อย ๆ ไฟล์ git ls-files เองก็เริ่มช้า

    • อยากรู้ว่ามีตัวอย่างแบบเจาะจงไหมที่ทำแบบนั้นแล้วเร็วขึ้นกว่าเดิม โดยทั่วไป ripgrep ก็เคารพกฎของ gitignore อยู่แล้ว เลยทำงานคล้าย git ls-files อยู่แล้ว อ้างอิงไว้ด้วยว่า -uu หมายถึงสั่งให้ ripgrep ไม่สนใจ gitignore และ hidden file แต่ก็ยังข้ามไฟล์ไบนารีอยู่ ถ้าจะรวมไฟล์ไบนารีด้วยต้องใช้ -uuu ปัญหาใหญ่สุดของฟังก์ชันนี้คือถ้าใช้กับ repo ของ Linux kernel จะเจอ error ว่า argument list ยาวเกินไป เลยลองเปลี่ยนไปใช้ xargs 
        $ git ls-files -z | time xargs -0 rg APM_RESUME
  ...

  real  0.638
  user  0.741
  sys   1.441
  maxmem 29 MB
  faults 0
  $ time rg APM_RESUME
  ...

  real  0.097
  user  0.399
  sys   0.588
  maxmem 29 MB
  faults 0
      ถ้ามีตัวอย่างสถานการณ์ที่ git ls-files -z | xargs -0 rg ... เร็วกว่า rg ... ตรง ๆ ก็ช่วยแชร์ด้วย
    • หลังจากเขียนคอมเมนต์นี้แล้วกลับไปอ่านคู่มืออีกที ก็เพิ่งรู้ว่าสามารถใช้แฟลก -. ได้แทน -uu (สำหรับค้นหา hidden file อย่างเดียว) คงจะดีถ้าค้นหา hidden file ที่ git ติดตามได้ แต่ overhead จากการ query รายชื่อไฟล์ดูจะมากพอจนแม้เขียนด้วย Rust ก็ยังเลี่ยงไม่ได้
    • หรือว่าฉันพลาดอะไรไป ripgrep ปกติก็ไม่ได้มองข้ามไฟล์ที่ git ไม่ได้ติดตามไว้เป็นค่าเริ่มต้นอยู่แล้วไม่ใช่เหรอ?
    • อยากรู้ว่าวิธีนี้เร็วกว่าการใช้ git grep ไหม

  • ฉันใช้ ripgrep ในงานทุกวัน ทั้งบน command line และเวลาใช้ค้นหาใน vscode ก็ใช้ตลอด ขอขอบคุณ burntsushi