ทำไมทุบเปลือกเริ่มต้นในระบบปฏิบัติการส่วนใหญ่?


38

ทำไมทุบเปลือกเริ่มต้นในระบบปฏิบัติการส่วนใหญ่ (Ubuntu, Fedora, OSX ฯลฯ ) เหตุใดผู้ใช้ขั้นสูงจำนวนมากจึงมักใช้ zsh หากเป็นสิ่งที่ดีทำไมจึงไม่เป็นค่าเริ่มต้น

ฉันใช้ทั้งฉันไม่เห็นความแตกต่างสำหรับงานทั้งหมดของฉันง่าย :)


5
ทุกอย่างเป็นเส้นโค้งแบบเกาส์: ถ้าเป็นจริงที่ผู้ใช้ขั้นสูงสุดใช้kshแล้วก็เป็นความจริงที่คนส่วนใหญ่ใช้เชลล์ที่แตกต่างกันและสิ่งนี้ในตัวมันเองจะอธิบายว่าทำไมkshไม่ใช่เชลล์เริ่มต้น อย่างไรก็ตามฉันไม่คิดว่าเป็นเหตุผลให้รอคำตอบนักฆ่าที่ฉันแน่ใจว่าคำถามนี้จะได้รับ
kos

1
อันที่จริงแล้วฉันเชื่อว่าอูบุนตูใช้เส้นประเป็นเปลือกเริ่มต้น ...
บาคุริ

1
นี่เป็นคำตอบที่ดีฉันลงคะแนนให้เราเปิดทิ้งไว้
เซท

คำตอบ:


33

ฉันได้อ่านเกี่ยวกับเรื่องนี้และข้อสรุปที่น่าจะเป็นว่าเป็นเชลล์เริ่มต้นของGNU (ใช้โดย Linux ส่วนใหญ่ที่ใช้ระบบปฏิบัติการ) และดังนั้นจึงมาเป็นแพคเกจที่เป็นส่วนหนึ่งของ GNU ในขณะที่มีการพัฒนา 20 ปี มีเสถียรภาพและกลมกลืนเป็นสิ่งที่ดีที่สุดสำหรับทุกคนรอบตัวตอบสนองความต้องการของทุกคน แต่เป็นผู้ใช้ขั้นสูง

อ่านเพิ่มเติมทำไม bash standard บน Linux? (คำถามเดียวกันใน Unix & Linux)

เพียงเพิ่มนิดหน่อยก็มี shell อื่น ๆ ให้ลองถ้าคุณสนใจนี่คือตัวอย่างจากคำตอบนี้ :

  • Zshมีสิ่งอำนวยความสะดวกแบบอินเทอร์แอคทีฟที่ทันสมัยกว่า แต่ก็มีเรื่องแปลกๆ เล็กน้อยเมื่อพูดถึงการเขียนสคริปต์ ในช่วงต้นถึงกลางปี ​​1990 เมื่อลีนุกซ์อยู่ในช่วงเริ่มต้น, zsh ไม่เป็นที่รู้จักอย่างแท้จริง

  • Kshเป็นมาตรฐานอย่างแท้จริงเกี่ยวกับการทำธุรกรรมเชิงพาณิชย์มาตั้งแต่กลางทศวรรษ 1980 แต่เป็นซอฟต์แวร์ที่เป็นกรรมสิทธิ์จนถึงปี 2000 ดังนั้นจึงไม่ใช่ตัวเลือกบน Linux นอกจากนี้ ksh มีความสามารถในการแก้ไขบรรทัดคำสั่ง subpar เทียบกับ bash

  • pdkshโคลนนิ่งฟรี ksh จะได้รับตัวเลือก แต่มันก็ไม่ได้รู้จักกันดีและมีความสามารถในบรรทัดคำสั่งฉบับที่ยากจน (Pdksh ไม่ได้เป็นโครงการที่ใช้งานได้อีกต่อไปแม้ว่าจะยังคงใช้ใน BSD บางส่วนตอนนี้ ATT ksh ฟรี)

  • กระจายบางติดตั้ง เถ้า/bin/shตัวแปรเป็น Ash (โดยที่ฉันหมายถึงเปลือกหอยหลวม ๆ ที่เรียกว่า ash) ได้รับการออกแบบให้มีขนาดเล็กและรวดเร็วโดยไม่มีคุณลักษณะแบบโต้ตอบ (เป็นเพียงสคริปต์แก้ไขเท่านั้น) การฟื้นตัวของเถ้าค่อนข้างเร็ว ในปี 1990 ตัวแปรที่มีอยู่ขาดคุณสมบัติมากมาย

  • tcshเป็นเปลือกโต้ตอบที่ทันสมัยที่สุดจนกว่า zsh มาพร้อม แต่มันไม่เข้ากันกับการดวลจุดโทษและไม่ดีกับการเขียนสคริปต์


1
เมื่อคุณคัดลอกวางจากที่อื่นคุณควรระบุอย่างชัดเจนว่าเป็นกรณีนี้
muru

1
@muru ฉันให้ลิงก์ไปยังโพสต์ดั้งเดิม แต่ฉันเห็นจุดของคุณว่ามันชัดเจนกว่า
Mark Kirby

อะไรคือที่มาของความคิดเห็นของคุณที่ zsh มีนิสัยใจคอบางประการเกี่ยวกับการเขียนสคริปต์? ไม่เป็นไรฉันเห็นว่าความคิดเห็นนั้นมาจากที่อื่น
สกูตเตอร์

1
คุณมีปลาด้วย (ซึ่งไม่สามารถใช้กับไวยากรณ์ sh ได้)
Léo Lam

1
คุณจะอธิบายว่ามีอะไรบกพร่องเกี่ยวกับการแก้ไข Korn Shell หรือไม่ ดูเหมือนว่าจะทำงานได้ดีสำหรับฉันเสมอแม้กระทั่งใน 90s
Jonathan Leffler

9

The Bourne Shell ( ดวลจุดโทษกลับในวันที่) ของ AT & T สาขาของยูนิกซ์ได้รับการปรับปรุงให้ดีขึ้นและแทนที่ด้วย Korn Shell, ksh ksh ยังมาจาก AT & T Bell Labs และไม่ใช่ GPL (รุ่นปัจจุบันคือ Eclipse Public License) C-shell, cshออกมาจากรุ่นUnkelของ Berkeley และยังไม่ใช่ GPL (BSD license) และใช้ไวยากรณ์ที่แตกต่างจาก sh Z-เปลือกzshคือการปรับปรุงในการดวลจุดโทษ แต่ไม่ GPL (MIT เหมือนใบอนุญาต) Bash เป็นการปรับปรุงโดยใช้ GPL และจาก GNU ใบอนุญาตเพียงอย่างเดียวทุบตีอาจจะเป็นทางเลือกสำหรับระบบปฏิบัติการ GPL โดยเฉพาะอย่างยิ่งกับเปลือกหอยที่เป็นส่วนหลักของ distro

แต่แบชก็เป็นโครงการ GNU ด้วยฉันคิดว่าการพัฒนาที่กระตือรือร้นมากขึ้นและการมีส่วนร่วมได้ง่ายกว่าผลิตภัณฑ์ที่สืบทอดจาก Berkeley Unix หรือ AT&T Unix กรณีที่ดีมากอาจทำให้ zsh เป็นและเป็นเชลล์ที่ดีกว่า Bash แต่ก็ไม่เพียงพอที่จะเอาชนะใบอนุญาตที่แตกต่างกันและสถานะโครงการที่ไม่ใช่ของ GNU

ย้อนกลับไปเมื่อ Linux distros ปรากฏตัวครั้งแรกและเลือกเชลล์เริ่มต้น (ช่วงต้นถึงกลาง 90 วินาที) ไม่มี github (2008) หรือแม้แต่ SourceForge (1999) ณ จุดนั้นฉันคิดว่าโครงการ GNU มีข้อได้เปรียบเหนือโครงการที่ไม่ใช่ของ GNU ในการสังเกตและวาดรูปรวมถึงนักพัฒนาใหม่ ดังนั้น distros สามารถดู Z-shell ได้ดีกว่า แต่ก็คาดหวังว่า Bash จะได้รับการสนับสนุนและการบำรุงรักษาที่ดีต่อไปและยังมีคุณสมบัติอื่น ๆ อีกมากมายที่เพิ่มเข้ามาทำให้สามารถติดตาม zsh ได้

ตอนนี้ Bash มีสถานะเริ่มต้นเป็นเวลาหลายปีมันกลายเป็นมาตรฐาน defacto โดยมีหนังสือที่เขียนเกี่ยวกับเรื่องนี้ มีหนังสือเล่มหนึ่งที่ครอบคลุมทั้ง Bash และ Z-shellแต่ไม่มีหนังสือที่ครอบคลุมเฉพาะในขณะที่มีหนังสือหลายเล่มที่ทำเพื่อ Bash

และ ณ จุดนี้หาก distros เปลี่ยนค่าเริ่มต้นสำหรับการอัพเกรดของระบบที่มีอยู่มันจะหยุดการตั้งค่าเนื่องจากไฟล์เริ่มต้นบางไฟล์มีชื่อแตกต่างกัน (เช่น. bashrc เทียบกับ. zshrc) และเนื้อหาของไฟล์อาจมีไวยากรณ์ที่เข้ากันไม่ได้ ดังนั้นพวกเขาจะไม่เต็มใจที่จะทำเช่นนั้นปล่อยให้การดาวน์โหลดใหม่มี zsh เป็นค่าเริ่มต้นและอัปเกรดเพื่อทุบตี สองค่าเริ่มต้นที่แตกต่างกันสำหรับ distro เดียวกันคือสิ่งที่พวกเขาอาจไม่ต้องการให้การสนับสนุนและผู้ใช้ / บริษัท ก็ไม่ต้องการที่จะจัดการเช่นกัน


1

ภาษาของ Unix shell น่าเกลียดทั้งหมด บางคนโดยเฉพาะ ( csh) บางคนอาจจะน้อยกว่านี้ ( ksh? ฉันไม่รู้จริง ๆ ) แต่จริงๆแล้วเมื่อพูดถึงแง่มุมต่าง ๆ เช่นความสามารถในการอ่านและความแข็งแกร่งสำหรับโครงการขนาดใหญ่ Python, C # หรือ Haskell ดังนั้นเมื่อคุณต้องการบางอย่างที่เป็นของแข็งคุณจะไม่เลือกรสชาติของเปลือกหอยเลย

คุณจะเลือกพวกเขาเมื่อคุณต้องการที่จะได้รับสิ่งที่ง่าย สำหรับสิ่งนี้คุณต้อง:

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

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

คนที่ทำสวิตช์นั้นจะพิจารณาอย่างรอบคอบและมีประสบการณ์มากพอที่จะจัดการกับการสลับไปยังเชลล์ที่พวกเขาชื่นชอบได้อย่างง่ายดาย OTOH มือใหม่ที่ถูกบังคับให้ทำงานกับกระสุนที่ได้รับความนิยมน้อยกว่าจะสับสนอย่างรวดเร็วหากพวกเขาขออะไรจากอินเทอร์เน็ตและมันไม่ทำงาน ดังนั้น distro ใด ๆ ที่ไม่เพียง แต่มุ่งเป้าไปที่ทหารผ่านศึกของ Unix จะมีความเสี่ยงค่อนข้างมากถ้ามันทำอะไรนอกจากbashมาตรฐานซึ่งเป็นขั้นตอนที่คนจำนวนไม่มากนักจะได้รับประโยชน์ (และเพียงเล็กน้อย)


1
ภาษาใดก็ตามที่สนใจช่องว่างจำนวนไม่ได้เป็น "การออกแบบที่ดี" แต่ฉันยอมรับว่าความนิยมเป็นกุญแจสำคัญ
Nagora

1
@Nagora: ความคิดเห็นแตกต่างกันไป FWIW คุณสามารถเขียน Haskell ด้วยเครื่องหมายวงเล็บและเซมิโคลอนแทนช่องว่างและฉันคิดว่า Python มีทางเลือกที่คล้ายกัน ไม่มีใครทำสิ่งนี้เพราะการจัดกลุ่มตามการเยื้องนั้นน่าทึ่งสำหรับการอ่าน
leftaroundabout

1
  1. มันอยู่ที่นั่นเมื่อมันต้องการ
  2. มีตาหวานพอที่ผู้ใช้สามารถใช้เวลาหนึ่งสัปดาห์ในการปรับแต่งพรอมต์ของพวกเขา
  3. กรณีการใช้งานทั่วไปมันดีพอ (โดยทั่วไปการเริ่มต้นคำสั่งเดียว)
  4. ในกรณีที่มันไม่ดีพอ Perl, หลามและ lua สามารถใช้เวลาหย่อน
  5. Perl ทำให้เปลือกโต้ตอบที่น่ากลัว
  6. แม้ว่าปลา, ksh หรือ zsh ในทางทฤษฎีอาจเป็นเปลือกที่ดีกว่า แต่ก็ยังไม่พอสำหรับฉันที่จะต้องใส่ใจเมื่อ perl ทำงานได้ดีหรือการพกพาเป็นปัญหาดังนั้นฉันจึงกำหนดเป้าหมายไปที่ขีดกลาง

0

"Critical Mass" เป็นคำตอบหลัก IMO Bash ไม่ได้มีไว้สำหรับงานบรรทัดคำสั่งเท่านั้น แต่ยังมีไว้สำหรับเขียนสคริปต์และมีสคริปต์ Bash จำนวนมากที่นั่น ไม่ว่าทางเลือกใดจะดีไปกว่าตอนนี้สำหรับการโต้ตอบความต้องการที่จะสามารถเพียงแค่ "plug and play" สคริปต์เหล่านั้นมีค่ามากกว่าข้อดีดังกล่าว ดังนั้นเชลล์เดียวที่สามารถกำจัด Bash ได้อย่างสมจริงในขณะนี้คือกระสุนที่เข้ากันได้อย่างสมบูรณ์แบบย้อนหลังและตัวเลือกที่มีแนวโน้มมากที่สุดสำหรับ ... Bash เวอร์ชั่นถัดไป


1
คุณสามารถใช้สคริปต์ทุบตีใด ๆ และทั้งหมดไม่ว่าเชลล์เริ่มต้นของคุณคืออะไร นั่นคือความหมายของ she-bang (#! / bin / bash) ที่ด้านบนสุดของสคริปต์
Panther

1
@ bodhi.zazen ตราบใดที่ bash shell มีอยู่ในระบบ ฉันรู้จัก Solaris อย่างน้อยหนึ่งเวอร์ชันที่ไม่มีการทุบตี
Tulains Córdova

@ bodhi.zazen มีค่าใช้จ่ายในการสลับระหว่างสองเชลล์ - หนึ่งสำหรับการมีปฏิสัมพันธ์และอีกหนึ่งสำหรับการเขียนสคริปต์ โดยทั่วไปแล้วไม่คุ้มกับความรำคาญ
Nagora

1
@Nagora ค่าใช้จ่ายในการใช้สคริปต์เป็นเท่าใด
คอส

@kos หากคุณเพียงแค่เรียกใช้สคริปต์จริงๆไม่มี หากคุณต้องบำรุงรักษาและปรับสคริปต์คุณจำเป็นต้องคำนึงถึงความแตกต่างเล็กน้อยระหว่างเชลล์พื้นฐานที่แตกต่างกันซึ่งในกรณีนี้มีค่าใช้จ่ายโลหะต่อเนื่องและต้นทุนการเปลี่ยนบริบทเมื่อคุณต้องทำงานบางอย่างใน ไวยากรณ์ "อื่น ๆ "
Nagora
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.