การเปรียบเทียบ Unix shells


9

ของเชลล์ Unix ที่สำคัญ (bash, ksh, tcsh, zsh, อื่น ๆ ?) มีเหตุผลที่น่าสนใจไหมที่จะใช้อีกอันหนึ่ง?

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

ฉันสามารถทำให้วิกินี้เป็นชุมชนได้หากมีใครชอบ

คำตอบ:


17

ปัจจุบัน:

  • bash- Bourne shell อีกครั้งเชลล์เริ่มต้นในลีนุกซ์ส่วนใหญ่ คุณสมบัติที่ดี
  • zsh - ฟีเจอร์ส่วนใหญ่รวย แต่ยังไม่ค่อยได้ใช้
  • ksh - เชลล์เริ่มต้นใน Solaris, AIX และยูนิเซฟอื่น ๆ
  • tcsh - เชลล์เริ่มต้นใน unices รสชาติ * BSD ต่างๆ

ประวัติศาสตร์:

  • sh- เชลล์เป้าหมายเดิม (เปิดตัวในปี 1977) ล้าสมัยโดยทุบตี;
  • csh- เชลล์ C ดั้งเดิม (เปิดตัวในปี 1978) เลิกใช้แล้วโดย tcsh และ ksh;

โปรดทราบว่า bash, ksh และ zsh มาจากไวยากรณ์ sh ขณะที่ tcsh มาจากไวยากรณ์ csh นี่เป็นไวยากรณ์ที่แตกต่างกันสองแบบ

แผนภูมิคุณลักษณะ (wiki)


โดยทั่วไปแล้วสคริปต์ส่วนใหญ่จะเขียนให้สอดคล้องกับ sh เนื่องจากการเปิดตัวสคริปต์ผ่าน sh มักจะเร็วกว่าการทุบตีมาก
Mikeage

วิธีที่ว่า? บน Linux / bin / sh คือ symlink ไปยัง / bin / bash
vartec

2
bin / sh / ไม่เคย symlink ไป / bin / ทุบตี
แบรดกิลเบิร์

1
เมื่อคุณยกตัวอย่าง bash เป็น "sh" มันจะทำงานในโหมด "sh" ที่รองรับชุดย่อยของคำสั่ง bash ฉันเชื่อว่าไวยากรณ์ "sh" เป็นมาตรฐาน POSIX
duffbeer703

ใน Debian คุณสามารถใช้ 'dash' แทน '/ bin / sh'
drybjed

9

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

ภาพหน้าจอไม่กี่ ( 1 , 2 , 3 , 4 ) เพียงพอที่จะให้ความคิดทั่วไป

fish ตอนนี้เชลล์เริ่มต้นบน Mac ที่ทำงาน ไปคิด


2

หากคุณกำลังจะได้เรียนรู้อื่น ๆ กว่าเปลือกsh/ คุณอาจได้เป็นอย่างดีก็ไปกับbash zshฉันไม่คิดว่าจะมีใครแข่งขันอย่างจริงจังว่ามันเป็นกระสุนที่ทรงพลังที่สุดและเต็มไปด้วยคุณสมบัติ ไม่ว่าจะเป็นเพียงการขยายตัวของหลักสูตรยังคงขึ้นอยู่กับการอภิปราย

ฉันเคยได้ยินสิ่งดีๆเกี่ยวกับfishแต่ไม่เคยพยายามที่จะรบกวนพวกเขา

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


2

ฉันขอแนะนำให้รู้จักทุบตีให้ดีเพราะมันเป็นหนึ่งในสิ่งที่พบได้บ่อยที่สุด โดยส่วนตัวแล้วฉันชอบ zsh ในฐานะเชลล์เชิงโต้ตอบของฉัน มันมีคุณสมบัติที่สมบูรณ์มาก ตัวอย่างเช่นคุณสามารถตั้งค่ารายการโฮสต์และเมื่อคุณทำบางอย่างเช่น ssh Ser [tab] มันจะรู้ว่าพยายามแท็บอัตโนมัติหนึ่งในโฮสต์เหล่านั้นให้สมบูรณ์ นอกจากนี้ยังมีการทำซ้ำแบบซ้ำดังนั้นหากคุณต้องการค้นหาไฟล์ jpeg ทั้งหมดในไดเรกทอรีปัจจุบันและไดเรกทอรีย่อยที่คุณสามารถls -ld **/*.jpgใช้ได้ มีคุณสมบัติความสนุกมากมายด้วย zsh (ค้นหาไฟล์. zshrc ของผู้คน) และคุณสามารถตั้งค่าให้เป็น 'bash Compatible' ดังนั้นจึงง่ายต่อการสลับระหว่างสอง หากคุณรวมสิ่งนี้เข้ากับหน้าจอ GNU คุณอาจพบว่าบรรทัดคำสั่งมีความยินดีที่ได้ใช้งาน


1

อย่าลืมคำถามอื่นของคุณเชลล์ Unix / Linux ที่พบบ่อยที่สุด - เชลล์ที่นิยมที่สุดน่าจะเป็นที่นิยมมากที่สุดด้วยเหตุผล ;-)

สำหรับสิ่งที่คุ้มค่าคนส่วนใหญ่ไม่ได้ปิดการใช้งานเชลล์บ่อยครั้งดังนั้นจึงเป็นการยากที่จะเปรียบเทียบตัวเลือกต่าง ๆ อย่างรอบด้าน คุณจะมีแนวโน้มที่จะเห็นผู้คนต่างกันเพิ่มความมีคุณธรรมของหอยที่พวกเขาโปรดปราน จากสิ่งเล็ก ๆ น้อย ๆ ที่ฉันเคยได้ยินเกี่ยวกับเชลล์ที่แตกต่างกันพวกเขาทั้งหมดมีคุณสมบัติพื้นฐานบางอย่างที่เหมือนกัน (เช่นการเปลี่ยนเส้นทาง I / O, คำสั่งประวัติ ฯลฯ ) ดังนั้นการตั้งค่าส่วนตัวน่าจะเป็นองค์ประกอบขนาดใหญ่


1

เหตุผลที่น่าสนใจกับการใช้ ZSH ที่ยังไม่ได้รับการกล่าวถึงเป็นโหมด vi และ emacs โหมด

สำหรับผู้ที่รักการใช้หน่วยความจำกล้ามเนื้อ vi ของพวกเขาในเปลือกนี้เป็นคุณสมบัตินักฆ่า

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

;-)


0

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


0

เช่นเดียวกับ Heads Up: Ubuntu เริ่มต้น "sh" ถึง "dash" ซึ่งนำไปสู่ปัญหาบางอย่างในอดีตด้วยความสามารถในการ POSIX เห็นได้ชัดว่าคำสั่ง echo แตกต่างกันเล็กน้อย

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