เหตุผลบางประการที่ OP ระบุว่าตัวเลือกไม่เหมาะสมไม่มีพื้นฐานในความเป็นจริง ที่นี่ฉันแสดงให้เห็นว่าเอฟเฟ็กต์ชนิดใดที่ใช้กลยุทธ์ของ OP 4:
ในการกระจายส่วนใหญ่grep
มีการติดตั้งใน/bin
(ทั่วไป) หรือ/usr/bin
(OpenSUSE บางทีคนอื่น ๆ ) และเริ่มต้นPATH
มี/usr/local/bin
มาก่อนหรือ/bin
/usr/bin
ซึ่งหมายความว่าถ้าคุณสร้าง/usr/local/bin/grep
ด้วย
#!/bin/sh
exec /bin/grep --color=auto "$@"
โดยที่/bin/sh
เชลล์ที่ใช้งานร่วมกันได้กับ POSIX ที่จัดจำหน่ายของคุณมักเป็น bash หรือ dash หากgrep
อยู่ใน/usr/bin
ให้ทำเช่นนั้น
#!/bin/sh
exec /usr/bin/grep --color=auto "$@"
โอเวอร์เฮดของสคริปต์นี้มีค่าน้อยที่สุด exec
งบหมายความว่าล่ามสคริปต์ที่จะถูกแทนที่ด้วยgrep
ไบนารี; นี่หมายความว่าเชลล์ไม่ได้อยู่ในหน่วยความจำในขณะที่grep
กำลังดำเนินการ ดังนั้นค่าใช้จ่ายเพียงอย่างเดียวคือการดำเนินการพิเศษของล่ามสคริปต์เช่นเวลาแฝงเล็กน้อยในเวลานาฬิกาแขวน แฝงเป็นค่าคงที่ประมาณ (แตกต่างกันเพียง แต่ขึ้นอยู่กับว่าgrep
และsh
มีอยู่แล้วในแคชหน้าหรือไม่และเกี่ยวกับวิธีการ I / O แบนด์วิดธ์ที่เหลืออยู่) และไม่ได้ขึ้นอยู่กับระยะเวลาที่grep
รันหรือเท่าใดข้อมูลจะประมวลผล
ดังนั้นเวลาแฝงนั้นคือค่าใช้จ่ายที่เพิ่มโดยสคริปต์ตัวตัด?
หากต้องการค้นหาให้สร้างสคริปต์ด้านบนและเรียกใช้
time /bin/grep --version
time /usr/local/bin/grep --version
บนเครื่องของฉันอดีตใช้เวลาจริง 0.005 (ข้ามการวิ่งจำนวนมาก) ในขณะที่หลังใช้เวลาจริง 0.006 ดังนั้นค่าใช้จ่ายในการใช้ wrapper ในเครื่องของฉันคือ 0.001s (หรือน้อยกว่า) ต่อการเรียกใช้
นี่คือไม่มีนัยสำคัญ
ฉันยังไม่เห็นอะไร "สกปรก" เกี่ยวกับเรื่องนี้เพราะแอปพลิเคชันและยูทิลิตี้ทั่วไปจำนวนมากใช้วิธีการเดียวกัน หากต้องการดูรายการดังกล่าวในเครื่องของคุณ/bin
และ/usr/bin
เพียงเรียกใช้
file /bin/* /usr/bin/* | sed -ne 's/:.*shell script.*$//p'
ในเครื่องของฉันออกดังกล่าวข้างต้นรวมถึงegrep
, fgrep
, zgrep
, which
, 7z
, chromium-browser
, ldd
และxfig
ซึ่งผมใช้ค่อนข้างบ่อย ถ้าคุณไม่พิจารณาการแจกจ่ายทั้งหมด "สกปรก" สำหรับการใช้สคริปต์ตัวคลุมคุณไม่มีเหตุผลที่จะต้องพิจารณาสคริปต์ตัวตัดคำ "สกปรก"
เป็นปัญหาเช่นสคริปต์ wrapper อาจทำให้:
หากผู้ใช้มนุษย์เท่านั้น (เมื่อเทียบกับสคริปต์) จะใช้รุ่นของ grep ที่เริ่มต้นที่การสนับสนุนสีถ้ามีการส่งออกไปยังสถานีแล้วสคริปต์กระดาษห่อสามารถตั้งชื่อcolorgrep
หรือcgrep
หรืออะไรก็ตาม OP เห็นสมควร
สิ่งนี้จะหลีกเลี่ยงปัญหาความเข้ากันได้ที่เป็นไปได้ทั้งหมดเนื่องจากพฤติกรรมของgrep
ไม่เปลี่ยนแปลงเลย
การเปิดใช้งานgrep
ตัวเลือกด้วยสคริปต์ตัวตัดคำ แต่ในวิธีที่หลีกเลี่ยงปัญหาใหม่:
เราสามารถเขียนสคริปต์ตัวตัดใหม่เพื่อสนับสนุนการกำหนดเองได้อย่างง่ายดายGREP_OPTS
แม้ว่าGREP_OPTIONS
จะไม่ได้รับการสนับสนุน (เนื่องจากเลิกใช้แล้ว) วิธีนี้ผู้ใช้สามารถเพิ่มexport "GREP_OPTIONS=--color=auto"
หรือคล้ายกับโปรไฟล์ของพวกเขา /usr/local/bin/grep
เป็นแล้ว
#!/bin/sh
exec /bin/grep $GREP_OPTIONS "$@"
โปรดทราบว่าไม่มีเครื่องหมายคำพูดล้อมรอบ$GREP_OPTIONS
เพื่อให้ผู้ใช้สามารถระบุมากกว่าหนึ่งตัวเลือก
ในระบบของฉันการรันtime /usr/local/bin/grep --version
ด้วยGREP_OPTIONS
empty หรือด้วยGREP_OPTIONS=--color=auto
นั้นเร็วเท่ากับเวอร์ชันก่อนหน้าของ wrapper script grep
คือมักจะใช้เวลาหนึ่งมิลลิวินาทีนานในการดำเนินการกว่าธรรมดา
รุ่นล่าสุดนี้เป็นรุ่นที่ฉันแนะนำให้ใช้เป็นการส่วนตัว
โดยสรุปกลยุทธ์ของ OP 4:
เป็นสิ่งที่แนะนำโดยgrep
นักพัฒนา
เป็นเรื่องเล็กน้อยที่จะใช้ (สองบรรทัด)
มีค่าใช้จ่ายที่ไม่มีนัยสำคัญ (ความล่าช้าพิเศษหนึ่งมิลลิวินาทีต่อการเรียกใช้บนแล็ปท็อปเครื่องนี้โดยเฉพาะตรวจสอบได้ง่ายในแต่ละเครื่อง)
สามารถนำมาใช้เป็นสคริปต์ wrapper ที่เพิ่มGREP_OPTS
การสนับสนุน (เพื่อแทนที่เลิก / ไม่สนับสนุนGREP_OPTIONS
)
สามารถนำไปใช้ (เป็นcolorgrep
/ cgrep
) ที่ไม่มีผลกับสคริปต์หรือผู้ใช้ที่มีอยู่เลย
เพราะมันเป็นเทคนิคที่ใช้กันอย่างแพร่หลายในการแจกแจงลินุกซ์แล้วมันเป็นเทคนิคทั่วไปและไม่ "สกปรก"
หากมีการใช้งานเป็น wrapper ( colorgrep
/ cgrep
) แยกต่างหากมันจะไม่สามารถสร้างปัญหาใหม่ได้เนื่องจากจะไม่มีผลgrep
กับพฤติกรรมเลย หากนำมาใช้เป็นสคริปต์เสื้อคลุมที่เพิ่มGREP_OPTS
การสนับสนุนการใช้GREP_OPTS=--color=auto
มีตรงความเสี่ยงเดียวกัน (WRT. ปัญหากับสคริปต์ที่มีอยู่) ที่ต้นน้ำเพิ่มค่าเริ่มต้น--color=auto
จะ ดังนั้นความคิดเห็นที่ว่า "การสร้างปัญหามากกว่าที่แก้" ไม่ถูกต้องสมบูรณ์: ไม่มีการสร้างปัญหาเพิ่มเติม