Tool: grep — ค้น regex ข้ามไฟล์พร้อมกันไฟ ReDoS จากบรรทัดที่ยาวผิดปกติ
grep ค้นหาข้อความหรือรูปแบบในไฟล์ของ workspace อย่างรวดเร็ว เป็นขั้นตอนสำคัญก่อนอ่านหรือแก้โค้ด เพราะช่วยหาไฟล์และบรรทัดที่เกี่ยวข้องได้ตรงจุด
Tool นี้คืออะไร
ค้นหา regex pattern ข้ามไฟล์หลายไฟล์ในโฟลเดอร์เดียว คืนผลเป็น file:line: content — เหมือนคำสั่ง grep บน Unix แต่เป็น tool แยกต่างหาก ไม่ต้องผ่าน bash เพราะเป็น operation ที่ใช้บ่อยพอจะคุ้มค่าที่จะมี interface ตรงไปตรงมาของตัวเอง
รับ glob pattern เลือกกลุ่มไฟล์ได้
พารามิเตอร์ glob (ดีฟอลต์ "*") กรองว่าจะค้นไฟล์แบบไหน เช่น "*.py" จำกัดเฉพาะไฟล์ Python — ใช้ Path.rglob() ค้นแบบ recursive ในทุกโฟลเดอร์ย่อย ยกเว้นโฟลเดอร์ที่ชื่อขึ้นต้นด้วยจุด (.git, .venv ฯลฯ) ที่ถูกกรองทิ้งไปโดยอัตโนมัติ
ป้องกัน ReDoS ด้วยการข้ามบรรทัดยาวผิดปกติ
จุดที่รอบคอบเป็นพิเศษ: ระบบข้ามบรรทัดที่ยาวเกิน 2,000 ตัวอักษรไปเลยไม่นำไปทดสอบกับ regex — เหตุผลตรงไปตรงมาจากคอมเมนต์ในซอร์ส: “skip longer lines — avoids ReDoS on minified/base64 content”
ReDoS (Regular Expression Denial of Service) คือปัญหาที่ regex pattern บางแบบ (โดยเฉพาะที่มี backtracking ซับซ้อน) ใช้เวลาประมวลผลยาวขึ้นแบบทวีคูณเมื่อ input ยาวขึ้น — ไฟล์ที่มีบรรทัดยาวผิดปกติ (เช่น JS ที่ minify มาแล้วทั้งไฟล์อยู่บรรทัดเดียว, ไฟล์ที่มี base64-encoded data ฝังอยู่) เป็นความเสี่ยงจริง ถ้า regex ที่โมเดลเขียนมาบังเอิญมี pattern ที่ backtrack หนัก การรันกับบรรทัดยาวขนาดนั้นอาจทำให้ tool ค้างได้นานผิดปกติ — การข้ามบรรทัดยาวเกิน threshold ไปเลยเป็นทางแก้ที่ตรงไปตรงมาและมีต้นทุนต่ำ (เสียแค่การค้นในบรรทัดนั้นๆ ซึ่งมักเป็นไฟล์ที่สร้างขึ้นอัตโนมัติอยู่แล้ว ไม่ใช่โค้ดที่คนเขียนเอง)
จำกัดผลลัพธ์ที่ 50 รายการ
ผลลัพธ์คืนสูงสุด 50 รายการแรกที่เจอ (ตามลำดับไฟล์ที่ sort แล้ว) พร้อมข้อความบอกว่ามีการตัดถ้าเจอมากกว่านั้น — กันผลลัพธ์บวมจนล้น context เมื่อ pattern ที่ค้นกว้างเกินไปจนแมตช์เกือบทุกบรรทัดในโปรเจกต์ใหญ่
Path guard เหมือน read_file
ใช้ resolve_read_path เดียวกับ read_file — path แบบ relative resolve เข้า workspace, อ่านได้เกือบทุกที่ยกเว้น protected path (.ssh, .aws, .gnupg ฯลฯ) เหมือนกันทุกประการ ไม่มี logic ความปลอดภัยแยกต่างหาก แต่ใช้ helper ร่วมกับ tool อ่านไฟล์อื่นๆ ทั้งหมด
ทำไมเรื่องนี้ถึงสำคัญ
grep เป็นตัวอย่างของ tool ที่ดู “ธรรมดา” ที่สุดในกลุ่ม แต่ยังมีการป้องกันความเสี่ยงที่ไม่ชัดเจนในตอนแรก (ReDoS จากบรรทัดยาวผิดปกติ) ซ่อนอยู่ — สะท้อนแนวคิดที่เห็นซ้ำๆ ทั่วทั้งโปรเจกต์: ทุก tool ที่รับ input จากโมเดล (ซึ่งอาจสร้าง pattern ที่ไม่ได้ตั้งใจให้เป็นอันตรายแต่บังเอิญมีผลข้างเคียงแย่) ต้องมีการป้องกันที่ระดับโค้ด ไม่ใช่หวังว่า pattern ที่โมเดลสร้างจะปลอดภัยเสมอ
ความคิดเห็น
กำลังโหลดความคิดเห็น...