เหตุใดยูทิลิตี้บังคับ POSIX จึงไม่ได้สร้างไว้ในเชลล์?

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

ตัวอย่างเช่นฉันมีสคริปต์ที่อ่านไฟล์ข้อความเล็ก ๆ น้อย ๆ และตรวจสอบว่ามีการฟอร์แมตอย่างถูกต้อง แต่ใช้เวลา 27 วินาทีในการเรียกใช้บนเครื่องของฉันเนื่องจากมีการจัดการสตริงจำนวนมาก การจัดการสตริงนี้สร้างกระบวนการใหม่นับพันโดยเรียกโปรแกรมอรรถประโยชน์ต่าง ๆ ดังนั้นความเชื่องช้า ผมค่อนข้างมั่นใจว่าถ้าบางส่วนของสาธารณูปโภคที่ถูกสร้างขึ้นในคือgrep, sed, cut, trและexprแล้วสคริปต์ที่จะวิ่งในครั้งที่สองหรือน้อยกว่า (ขึ้นอยู่กับประสบการณ์ของผมใน C)

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

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

ไม่คาดว่าเชลล์สคริปต์จะทำงานด้วยความเร็วประเภทนั้น หากคุณต้องการปรับปรุงความเร็วสคริปต์ของคุณให้ลองเป็น Perl หากยังคงช้าเกินไปคุณจะต้องย้ายไปที่ภาษาที่พิมพ์แบบคงที่เช่น java หรือ c หรือเขียนโมดูล C สำหรับ perl ที่รันส่วนที่ช้าเกินไป

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

คาดว่า Unix OS จะรวมโปรแกรมขนาดเล็กจำนวนมากซึ่งทำงานที่กำหนดไว้อย่างดีซึ่งประกอบเป็นภาพใหญ่ขึ้น นี่เป็นสิ่งที่ดีเพราะโปรแกรมนี้มีขนาดใหญ่ขึ้น ลองดูที่ qmail และเปรียบเทียบกับ sendmail qmail ประกอบด้วยหลายโปรแกรม:

http://www.nrg4u.com/qmail/the-big-qmail-picture-103-p1.gif

การใช้ประโยชน์จาก daemon เครือข่ายจะไม่ช่วยให้คุณใช้ประโยชน์จากตัวจัดการคิว

เหตุใดยูทิลิตี้บังคับ POSIX จึงไม่ได้สร้างไว้ในเชลล์

เนื่องจากเป็นไปตาม POSIX ระบบจึงจำเป็นต้องมี¹เพื่อให้โปรแกรมอรรถประโยชน์ส่วนใหญ่เป็นคำสั่งแบบสแตนด์อโลน

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

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

ยังทราบว่าอย่างน้อยksh93, bashและzshไปต่อไปโดยการให้วิธีการที่กำหนดเองสำหรับเปลือกวิ่งไป builtins โหลดแบบไดนามิกจากห้องสมุดสาธารณะ ในทางเทคนิคแล้วไม่มีสิ่งใดขัดขวาง POSIX ยูทิลิตี้ทั้งหมดที่จะใช้งานและทำให้เป็นแบบบิวด์อิน

ในที่สุดการวางไข่กระบวนการใหม่ได้กลายเป็นการดำเนินการอย่างรวดเร็วด้วยระบบปฏิบัติการที่ทันสมัย หากคุณประสบปัญหาด้านประสิทธิภาพจริงๆอาจมีการปรับปรุงบางอย่างเพื่อให้สคริปต์ของคุณทำงานได้เร็วขึ้น

¹ POSIX.1-2008

_{อย่างไรก็ตามยูทิลิตี้มาตรฐานทั้งหมดรวมถึงบิวด์อินปกติในตาราง แต่ไม่ต้องบิวด์อินพิเศษที่อธิบายไว้ในยูทิลิตี้บิวด์อินพิเศษจะต้องดำเนินการในลักษณะเพื่อให้สามารถเข้าถึงได้ผ่านตระกูล exec ฟังก์ชั่นตามที่กำหนดไว้ในปริมาณการเชื่อมต่อระบบของ POSIX.1-2008 และสามารถเรียกใช้โดยตรงโดยยูทิลิตี้มาตรฐานเหล่านั้นที่ต้องการมัน (env, ค้นหา, ดี, nohup, เวลา, xargs)}

จากคู่มืออ้างอิงทุบตี ,

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

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

พวกที่ AT&T ถามตัวเองในสิ่งเดียวกัน

หากคุณดูประวัติของ AT&T Software Toolkit (ปัจจุบันอยู่เฉยๆบน github นับตั้งแต่ทีมแกนซ้าย) นี่เป็นสิ่งที่พวกเขาทำกับ AT&T Korn shell หรือที่รู้จักกันว่า ksh93

ประสิทธิภาพเป็นส่วนหนึ่งของแรงจูงใจสำหรับผู้ดูแล ksh93 และเมื่อสร้าง ksh คุณสามารถเลือกที่จะสร้างยูทิลิตี้ POSIX ทั่วไปเป็นไลบรารีที่โหลดแบบไดนามิก โดยผูกคำสั่งเหล่านี้กับชื่อไดเรกทอรีเช่น/opt/ast/binคุณสามารถควบคุมเวอร์ชันของคำสั่งที่จะใช้ขึ้นอยู่กับตำแหน่งของชื่อไดเรกทอรี$PATHนั้น

ตัวอย่าง:

cat chmod chown cksum cmp cp cut date expr fmt head join ln
mkdir mkfifo mktemp mv nl od paste rm tail tr uniq uuencode wc

รายการทั้งหมดสามารถพบได้ในพื้นที่เก็บข้อมูลgithub ast

โปรดทราบว่าเครื่องมือ ast ส่วนใหญ่มีที่มาของตนเองและจะแตกต่างอย่างมากจากการใช้งาน gnu ทั่วไป ทีมวิจัยของ AT&T ปฏิบัติตามมาตรฐานอย่างเป็นทางการซึ่งเป็นวิธีการทำงานร่วมกันเมื่อคุณไม่สามารถแบ่งปันรหัสได้

ดังนั้นเราจึงไม่ได้ใช้ทรัพยากรจอมพลในการเพิ่มประสิทธิภาพเครื่องมือดั้งเดิมเพื่อตอบสนองทุกความต้องการ ฉันเดาว่าสิ่งที่เราต้องอธิบายคือความปรารถนานี้จะมีค่าใช้จ่ายเท่าไหร่

POSIX ให้คำจำกัดความเกี่ยวกับยูทิลิตี้ที่ดูเหมือนว่าจะไม่มีปัญหาอย่างมากที่จะมีการใช้งานที่แตกต่างกัน

นี่เป็นสมมติฐานที่ไม่ดี :-P

ระบบ POS-POSIX ยังคงมีประสิทธิภาพและสะดวกสบายมากขึ้นด้วยเหตุผลที่ดี เป็นมาตรฐานตามความเป็นจริงมันไม่เคยสบตาจริง ๆ

Ubuntu เริ่มใช้ความพยายามในการเปลี่ยนไปใช้เชลล์ POSIX แบบถอดลงสำหรับสคริปต์เพื่อปรับกระบวนการบูต System V init เก่าให้เหมาะสม ฉันไม่ได้บอกว่ามันล้มเหลว แต่มันทำให้เกิดข้อบกพร่องมากมายที่ต้องทำความสะอาด: "bashisms" สคริปต์ที่ทำงานภายใต้/bin/shขณะที่สมมติว่าbashมีฟีเจอร์ต่างๆ

POSIX sh ไม่ได้เป็นภาษาการเขียนโปรแกรมวัตถุประสงค์ทั่วไปที่ดี จุดประสงค์หลักของมันคือการทำงานได้ดีเป็นเปลือกโต้ตอบ เร็วที่สุดเท่าที่คุณจะเริ่มต้นในการบันทึกคำสั่งของคุณสคริปต์จะทราบว่าคุณเข้าใกล้tarpit ทัวริง เช่นมันเป็นไปไม่ได้ที่จะตรวจสอบความล้มเหลวในช่วงกลางของท่อปกติ bashเพิ่มset -o pipefailสำหรับสิ่งนี้ แต่สิ่งนี้ไม่ได้อยู่ใน POSIX

คุณสมบัติที่มีประโยชน์ แต่ unstandardized trueคล้ายกันจะถูกจัดไว้ให้โดยเกือบทุกยูทิลิตี้ที่มีความซับซ้อนมากกว่า

สำหรับคลาสของงานที่คุณร่างคุณสามารถวาดเส้นคร่าว ๆ ไปยัง Awk, Perl และ Python ในปัจจุบัน เครื่องมือต่าง ๆ ถูกสร้างขึ้นและพัฒนาอย่างอิสระ คุณคาดหวังว่า GNU Awk จะรวมเป็น libutilposixextended หรือไม่?

ฉันไม่ได้บอกว่าตอนนี้เรามีวิธีที่ดีกว่าในระดับสากลที่ฉันสามารถบอกคุณได้ ฉันมีจุดอ่อนสำหรับ Python Awk นั้นทรงพลังอย่างน่าประหลาดใจแม้ว่าฉันจะรู้สึกหงุดหงิดกับบางคุณสมบัติที่เฉพาะเจาะจงของ GNU Awk แต่ประเด็นก็คือการประมวลผลสตริงจำนวนมากทีละรายการ (สันนิษฐานจากบรรทัดของไฟล์) ไม่ใช่เป้าหมายการออกแบบของ POSIX เชลล์

นอกจากนี้ยังมีคำถามว่า: เปลือกไหนที่คุณจะสร้างมันขึ้นมา?

ระบบ Unix / Linux ส่วนใหญ่มีเชลล์ที่แตกต่างกันหลายตัวซึ่งพัฒนาขึ้นโดยอิสระ (sh / bash / korn / ???) หากคุณสร้างเครื่องมือลงในเชลล์คุณจะต้องใช้เครื่องมือเหล่านี้สำหรับแต่ละเชลล์ สิ่งนี้จะทำให้เกิดโอเวอร์เฮดและคุณอาจพบกับคุณสมบัติ / ข้อบกพร่องต่าง ๆ เช่น grep ขึ้นอยู่กับเชลล์ที่คุณใช้เรียกมัน

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

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

ในการปิดพิจารณาบางส่วนของฟังก์ชั่นที่คุณปรารถนาที่จะอยู่ในทุบตีอยู่ในทุบตี ตัวอย่างเช่นความสามารถในการจับคู่ RE ใน BASH ถูกนำมาใช้โดยใช้ตัวดำเนินการ= ~ไบนารี (ดูไวยากรณ์ของเชลล์ในหน้าคู่มือเพิ่มเติมโดยเฉพาะอ้างอิงการอภิปรายของโครงสร้าง [[]] สำหรับถ้า ) เป็นตัวอย่างที่รวดเร็วมากสมมติว่าฉันกำลังค้นหาไฟล์สำหรับเลขฐานสิบหก 2 หลัก:

while read line; do
    if [[ $line =~ 0x[[:xdigit:]]{2} ]]; then
        # do something important with it
    fi
done < input_file.txt

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

# this does not take into account the saving of the substituted text
# it shows only how to do it
while read line; do
    ${line/pattern/substitution}
done < input_file.txt

ในท้ายที่สุดแม้ว่าข้างต้นเป็น "ดีกว่า" กว่า?

grep -E "[[:xdigit:]]{3}" input_file.txt
sed -e 's/pattern/substitution/' input_file.txt

นี่คืออุบัติเหตุทางประวัติศาสตร์

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

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

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

นั่นไม่ได้หมายความว่าคุณไม่สามารถใช้งานบางฟังก์ชั่นได้สองครั้งและแน่นอนว่าบางเชลล์ใช้ฟังก์ชั่นบางอย่างที่ควรจะเป็นโปรแกรมภายนอกในฐานะเชลล์บิวด์อิน; เช่นทุบตีใช้echoคำสั่งเป็น builtin แต่ยังมี/usr/bin/echo