ในส่วนเชลล์สคริปต์ที่ผมเคยเห็น (นอกเหนือจากคนที่ฉันไม่ได้เขียนตัวเอง) ผมสังเกตเห็นว่า shebang #!/bin/shมีการตั้งค่า นี่ไม่ได้ทำให้ฉันแปลกใจกับสคริปต์เก่า ๆ แต่มันก็มีสคริปต์ใหม่ ๆ

มีเหตุผลในการเลือก/bin/shมากกว่า/bin/bashเนื่องจากbashแพร่หลายมากและมักจะเริ่มต้นในเครื่อง Linux และ BSD จำนวนมากจะกลับมาดีกว่าทศวรรษ?

1. มีระบบที่ไม่จัดส่ง bash เป็นค่าเริ่มต้น (เช่น FreeBSD)
2. แม้ว่าจะมีการติดตั้ง bash แล้วมันอาจไม่อยู่ใน/binนั้น
3. สคริปต์แบบง่าย ๆ ส่วนใหญ่ไม่ต้องใช้ bash
4. การใช้ POSIX เชลล์สามารถพกพาได้มากขึ้นและสคริปต์จะทำงานบนระบบที่หลากหลายมากขึ้น

สคริปต์ระบบส่วนใหญ่ใน (เกี่ยวข้องกับ Debian: Ubuntu, Mint, ฯลฯ ) Linux เขียนขึ้นเพื่อให้ทำงานได้เร็วขึ้นซึ่งเป็นค่าเริ่มต้น / bin / sh ในระบบเหล่านั้น เหตุผลคือสองเท่า:

• ความเร็วของระบบ โค้ดขนาดเล็กที่โหลดได้เร็วกว่าและยังทำงานได้เร็วขึ้น ด้วยความพยายาม (เล็ก) เพิ่มเติมบางส่วน (ราคา) ให้โปรแกรมเมอร์ของเชลล์สคริปต์

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

Bash นั้นเป็นเชลล์เริ่มต้นสำหรับผู้ใช้เช่นเดียวกับที่มีประสิทธิภาพมากขึ้นและมีองค์ประกอบมากมายที่จะทำให้การเขียนโปรแกรมง่ายขึ้น นอกจากนี้ยังเป็นค่าเริ่มต้นshใน Mac OS (อันที่เชื่อมโยงจาก / bin / sh) อย่างไรก็ตามการโทรbashด้วยชื่อลิงค์ของshทำให้มันเริ่มต้นเป็นเชลล์ที่สอดคล้องกับ posix

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

นอกจากนั้นมีเหตุผลที่ดีที่จะใช้เชลล์ Bourne Again ในการตีความสคริปต์เชลล์ เหตุผลเหล่านี้มีแรงจูงใจในโครงการขนาดใหญ่ของ Ubuntu และ Debian ของกว่าหลายปีที่จะลบ bashisms และเพื่อให้เป็นจำนวนมากของเชลล์สคริปต์ที่ดำเนินการโดยเริ่มต้นระบบ (ซึ่งเป็นจำนวนมากของเชลล์สคริปต์ที่มีระบบ 5 rc) และแพคเกจกำจัด / ติดตั้งใช้Debian Almquist shellแทนเชลล์ Bourne Again

พูดง่าย ๆ : Bourne Again shell, หนุนเต็มไปด้วยคุณสมบัติการโต้ตอบตามที่เป็นอยู่มันไม่ได้เป็นล่ามเชลล์ที่เร็วที่สุดสำหรับเชลล์สคริปต์ที่สอดคล้องกับ POSIX ดังนั้นหากใครสามารถสร้างเชลล์สคริปต์ให้สอดคล้องกับ POSIX ให้ตีความโปรแกรมเหล่านั้นด้วยโปรแกรมที่มีน้ำหนักเบากว่าเช่น Debian Almquist shell ระบบของคนจะทำงานได้ดีขึ้น (ในท้ายที่สุดเดเบียนต้องทำการปรับเปลี่ยนเล็กน้อยกับ Almquist shell เพื่อเพิ่มการสนับสนุนสำหรับโครงสร้างที่ไม่ใช่ POSIX สองเชลล์ที่ลึกเกินไปและฝังลึกเกินไปและมีประโยชน์มากเกินไปที่จะกำจัด)

ผลที่ได้คือทุกอย่างเพิ่มขึ้นอย่างมากในประสิทธิภาพของ bootstrap

ดังนั้นจึงต้องพิจารณาเชลล์สองคลาสที่แตกต่างกันที่นี่:

• เชลล์ที่มีคุณสมบัติการโต้ตอบแบบฉูดฉาดทั้งหมดซึ่งกำหนดค่าเป็นเชลล์ล็อกอินแบบโต้ตอบสำหรับผู้ใช้ในฐานข้อมูลบัญชี
• เชลล์ที่แปลสคริปต์จำนวนมากอย่างรวดเร็วซึ่งใช้เป็นล่ามสคริปต์โดยเชลล์สคริปต์โปรแกรม

โปรดทราบว่าการพูดถึงสิ่งนี้ในฐานะ "การเลือก/bin/sh" เป็นสิ่งที่เกินความคาดหมาย เดเบียนมีเป้าหมายอย่างน้อยสองเป้าหมาย:

1. ในหน้าผู้ดูแลระบบที่ใช้เชลล์ Debian Almquist, Z Shell (ในโหมด POSIX), Bourne Again shell (ในโหมด POSIX), MirBSD Korn เชลล์และอื่น ๆ ตามที่/bin/shมี ...

   1. ... ทำให้สคริปต์เป็นแบบพกพาได้มากที่สุดดังนั้นการสลับสิ่งที่/bin/shแมปไปไม่ทำให้สิ่งแตกหัก หรือ

   2. ... การทำให้สคริปต์ที่ไม่ใช่แบบพกพากำหนดเป้าหมายโปรแกรมล่ามที่ถูกต้องอย่างชัดเจนแทนที่จะคาดหวัง/bin/shแผนที่นั้น

2. มีการทำเด Almquist เปลือกทำแผนที่เริ่มต้นสำหรับการ/bin/shแทนของบอร์นเชลล์เพื่อให้สคริปต์เหล่านั้นที่เป็น POSIX สอดคล้อง (หรือถูกกว่าเดนโยบายคู่มือการใช้งานที่สอดคล้อง) วิ่งได้รวดเร็วยิ่งขึ้น

และแน่นอนว่าเมื่อมีใครเข้ามาในนี้ใคร ๆ ก็สามารถนำมันไปได้ไกลกว่านี้มาก เช่นการพิจารณาประสิทธิภาพการแลกเปลี่ยนของไลค์/bin/trueและ/usr/bin/clearการเป็นเชลล์สคริปต์หรือโปรแกรมที่คอมไพล์ แต่นั่นไม่ใช่คำตอบนี้โชคดีที่ ☺

สิ่งนี้ไม่ใหม่มากหรือแม้แต่เฉพาะยูนิกซ์แน่นอน ย้อนกลับไปก่อนศตวรรษที่ฉันเขียนและตีพิมพ์ล่ามบรรทัดคำสั่งที่มีทั้งรสชาติ "แบบโต้ตอบ" และ "ไม่โต้ตอบ" อธิบายส่วนนี้ใน doco และสังเกตความแตกต่างระหว่างตัวแปรCOMSPECและOS2_SHELLสภาพแวดล้อม ในทำนองเดียวกันการอภิปรายการลบ bashisms ใน System V ของ Debian rcและสคริปต์การติดตั้ง / กำจัดแพ็กเกจเริ่มต้นตั้งแต่ปี 1990

อ่านเพิ่มเติม

• https://superuser.com/a/696310/38062
• https://unix.stackexchange.com/a/193210/5132
• /bin/shรีบเป็น อูบุนตูวิกิ
• /bin/shรีบเป็น Debian wiki
• bashisms wiki ของเกร็ก
• Brian M. Carlson (2005-07-29) บริการประชาชนประกาศเกี่ยวกับนโยบาย 10.4 <1122626433.30217.39.camel@stonewall.crustytoothpaste.ath.cx> เดเบียน-devel
• Raphael Geissert (2009-04-12) รีบเป็นค่าเริ่มต้น / bin / ดวลจุดโทษและ bashisms ฟรี RGs <200904121359.09387.atomo64@gmail.com> debian-devel
• เดเบียนนโยบาย: โปรดอย่าระบุว่าสคริปต์ทำงานภายใต้เส้นประเป็น 'อาจจะ' ที่สอดคล้องกับนโยบาย Debian Bug # 490604
• รายงานแพคเกจ Debian สำหรับเส้นประเป้าหมาย
• เดเบียนนโยบาย: โปรดกีดกันการใช้งานของก้อง -n และสะท้อนในทั่วไป Debian Bug # 490605
• Rebecca Sobol (2009-07-29) เรื่องของสองเปลือกหอย: ทุบตีหรือขีด LWN
• Justus Pendleton (1997-04-22) ทุบตี-ISMS ในแพคเกจ <E0wJjkL-0001II-00@ryoohki.res.cmu.edu> เดเบียน-devel
• Jonathan de Boyne Pollard (2000) "คำสั่งล่ามปลายด้านหน้า" Command Interpreter อ้างอิงคำสั่ง เอกสารออนไลน์สำหรับตัวแปลคำสั่ง 32- บิต
• John Chambers (1990) คำสั่ง / bin / true และลิขสิทธิ์

มีเหตุผลใดบ้างที่จะต้องมี shebang ชี้ไปที่ / bin / sh แทนที่จะเป็น / bin / bash?

ใช่. @ Marco's คำตอบที่ยอดเยี่ยมแสดงถึงสิ่งนี้ได้ดี

ฉันควรใช้อะไรใน shebang ของฉัน

เมื่อเขียนสคริปต์ของคุณเองคุณควรชีบชีทให้เป็นสิ่งทั่วไปที่สุดที่คุณทดสอบ

ในระบบของฉัน (Centos 6.6) shมีการเชื่อมโยงกับbash:

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Dec  2  2014 /bin/sh -> bash

ซึ่งหมายความว่าฉันมักจะใช้#!/bin/bashใน shebang ของฉันเว้นแต่ฉันจะตรวจสอบว่าฉันไม่ได้ bashims ในสคริปต์ของฉัน

โดยการตั้งค่า shebang เพื่อคุณสัญญาว่าสคริปต์ที่จะทำงานร่วมกับการใช้งานของ#!/bin/shsh

นี่เป็นสัญญาที่ยิ่งใหญ่กว่าการบอกว่าสคริปต์จะใช้งานได้กับการทุบตี

นี่คือตัวอย่างของสคริปต์ที่จะทำงานไม่ถูกต้องขึ้นอยู่กับshการใช้งานระบบที่ใช้:

#!/bin/sh
n=1
a=$((++n))
echo $n

เมื่อใช้bashสคริปต์จะพิมพ์:

2

เมื่อใช้dashสคริปต์จะพิมพ์:

1

หากฉันต้องการใช้#!/bin/shสิ่งที่ฉันต้องทำ

• ตรวจสอบสคริปต์ด้วยcheckbashisms- โปรดทราบว่านี่จะไม่พบ bashims ทั้งหมด ไม่พบความผิดพลาดในสคริปต์ของฉันด้านบน
• ทดสอบสคริปต์โดยใช้shการนำไปใช้อื่น โดยทั่วไปแล้วฉันจะทดสอบด้วยdashอย่างไรก็ตามฉันคาดหวังว่า bashisms หรือ dashims บางตัวยังสามารถผ่านได้

หน้า DashAsBinShในวิกิพีเดียอูบุนตูมีจำนวนมากของข้อมูลที่น่าสนใจ

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

/bin/shเป็นตัวแปลสคริปต์หนึ่งเดียวที่พร้อมใช้งานในทุกสิ่งที่เรียกตัวเองว่า Unix แต่ในระบบมรดกจำนวนมากอันน่ากลัว/bin/shและยูทิลิตี้ที่เกี่ยวข้องนั้นไม่สอดคล้องกับ POSIX.1-1996 "เชลล์และยูทิลิตี้" สเป็คให้ทุกอย่างทันสมัยยิ่งขึ้น เครื่องมือที่ได้มาตรฐานเป็นตัวเลือกเสริมติดตั้งใน/usr/xpg4หรือตำแหน่งที่ไม่ชัดเจนดังกล่าว ^{1 การ} เขียนสคริปต์ไปยังภาษาของเชลล์แบบพกพาเซตย่อยน่าเบื่อกว่าและเกิดข้อผิดพลาดได้ง่ายกว่าการเขียนสคริปต์ไปยังภาษาของ POSIX เชลล์ (อ่านconfigureสคริปต์ที่สร้างโดย Autoconf บางครั้งถ้าคุณไม่เชื่อฉันเพียงแค่การตั้งค่าควรเพียงพอที่จะโน้มน้าวคุณ)

แต่ถ้าคุณสามารถสันนิษฐานได้ว่ามีการติดตั้งล่ามสคริปต์อื่น ๆ (เช่น Bash) คุณสามารถใช้ล่ามแปลภาษาสคริปต์ที่ดีกว่าได้ Perl, ตัวอย่างเช่นเป็นมากขึ้นมีแนวโน้มที่จะสามารถใช้งานได้กว่าทุบตี

ดังนั้นคุณไม่ควรเขียน#! /bin/bashสคริปต์เพราะถ้าเป็นตัวเลือกภาษาที่ดีกว่าก็เป็นตัวเลือกเช่นกัน

¹ตัวอย่างเช่น Solaris 10 และผู้สูงอายุจัดส่งต้นฉบับเปลือกบอร์น/bin/shเป็น ฉันได้รับแจ้งว่า Solaris 11 อัปเดตเป็น ksh93

คุณควรใช้จริง

#! /bin/env sh

หรือ

#! /bin/env bash

วิธีที่คุณเรียกใช้เชลล์โดยวิธีที่พวกเขาติดตั้งบนระบบนั้น

เพื่อความปลอดภัยสุด ( เช่นในกรณีของการเริ่มต้นใหม่ผู้เดียว) ใช้อย่างอื่นใช้shbash