เมื่อใดที่ฉันต้องใช้ #! / bin / bash และเมื่อ #! / bin / sh?

เมื่อใด#!/bin/bashที่เหมาะสมกว่า#!/bin/shในเชลล์สคริปต์

ในระยะสั้น:

• มีหลายเปลือกหอยที่ใช้ซูเปอร์มีข้อกำหนด POSIX ดวลจุดโทษ ในระบบที่ต่างกัน/bin/shอาจเป็นลิงก์ไปยัง ash, bash, dash, ksh, zsh, & c (มันจะเข้ากันได้กับ SH เสมอ - ไม่เคย csh หรือปลา)

• ตราบใดที่คุณยึดติดกับshคุณสมบัติเท่านั้นคุณสามารถใช้ (และอาจจะควร) #!/bin/shและสคริปต์ควรทำงานได้ดีไม่ว่าจะใช้เชลล์ตัวไหน

• หากคุณเริ่มใช้คุณสมบัติเฉพาะของ bash (เช่นอาร์เรย์) คุณควรร้องขอ bash เป็นพิเศษ - เนื่องจากแม้ว่า/bin/shจะเรียกใช้ bash ในระบบของคุณอยู่แล้วมันอาจไม่ได้อยู่ในระบบของคนอื่นและสคริปต์ของคุณจะไม่ทำงานที่นั่น (แน่นอนใช้กับ zsh และ ksh.) คุณสามารถใช้shellcheckเพื่อระบุ bashisms

• แม้ว่าสคริปต์นั้นมีไว้สำหรับการใช้งานส่วนตัวเท่านั้นคุณอาจสังเกตเห็นว่าบาง OS เปลี่ยนแปลง/bin/shในระหว่างการอัพเกรดเช่นบน Debian เคยเป็นทุบตี แต่ภายหลังถูกแทนที่ด้วยเส้นประที่น้อยที่สุด สคริปต์ที่ใช้ bashisms แต่#!/bin/shทันใดนั้นก็พัง

อย่างไรก็ตาม:

• แม้#!/bin/bashจะไม่ถูกต้องมากนัก ในระบบที่แตกต่างกันทุบตีอาจอาศัยอยู่ใน/usr/binหรือหรือ/usr/pkg/bin/usr/local/bin

• ตัวเลือกที่น่าเชื่อถือมากขึ้นคือการ#!/usr/bin/env bashใช้ $ PATH (แม้ว่าenvเครื่องมือนั้นจะไม่รับประกันอย่างเข้มงวด แต่/usr/bin/envก็ยังใช้งานได้กับระบบมากกว่าที่เป็น/bin/bashอยู่)

ใช้ shebang ที่สอดคล้องกับเชลล์ที่คุณใช้พัฒนาและดีบักสคริปต์ของคุณ เช่นถ้าเปลือกเข้าสู่ระบบของคุณและคุณเรียกใช้สคริปต์ของคุณเป็นที่ปฏิบัติการในสถานีของคุณใช้bash #!/bin/bashอย่าเพิ่งคิดว่าเมื่อคุณไม่ได้ใช้อาร์เรย์ (หรือbashคุณสมบัติใด ๆ ที่คุณรับรู้) คุณจะปลอดภัยในการเลือกเปลือกที่คุณชอบ มีความแตกต่างเล็กน้อยระหว่างเชลล์ ( echo, ฟังก์ชั่น, ลูป, คุณตั้งชื่อ) ซึ่งไม่สามารถค้นพบได้หากไม่มีการทดสอบที่เหมาะสม

พิจารณาสิ่งนี้: ถ้าคุณออกไป#!/bin/bashและผู้ใช้ของคุณไม่มีมันพวกเขาจะเห็นข้อความแสดงข้อผิดพลาดที่ชัดเจน

Error: /bin/bash not found

ผู้ใช้ส่วนใหญ่สามารถแก้ไขปัญหานี้ได้ภายในหนึ่งนาทีโดยการติดตั้งแพ็คเกจที่เหมาะสม ในทางกลับกันถ้าคุณแทนที่ shebang ด้วย#!/bin/shและทดสอบบนระบบที่/bin/shมี symlink ให้/bin/bashผู้ใช้ของคุณที่ไม่มีbashปัญหา พวกเขาส่วนใหญ่จะเห็นข้อความผิดพลาดที่เป็นความลับเช่น:

Error in script.sh line 123: error parsing token xyz

อาจใช้เวลาหลายชั่วโมงในการแก้ไขและจะไม่มีเงื่อนงำเกี่ยวกับเชลล์ที่ควรใช้

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

คุณควรใช้#! /bin/shเท่านั้น

คุณไม่ควรใช้ส่วนขยาย bash (หรือ zsh หรือ fish หรือ ... ) ในเชลล์สคริปต์

คุณควรเท่านั้นที่เคยเขียนสคริปต์เปลือกที่ทำงานร่วมกับใด ๆการดำเนินงานของภาษาเปลือก (รวมทั้งหมด "ยูทิลิตี้โปรแกรม" ที่ไปพร้อมกับเปลือกของตัวเอง) วันนี้คุณอาจใช้POSIX.1-2001 ( ไม่ใช่ -2008) เป็นสิทธิ์สำหรับสิ่งที่เชลล์และยูทิลิตีสามารถใช้งานได้ แต่โปรดทราบว่าวันหนึ่งคุณอาจถูกเรียกให้พอร์ตสคริปต์ของคุณไปยังระบบเดิม (เช่น Solaris หรือ AIX) ซึ่งเชลล์และยูทิลิตีถูกแช่แข็งประมาณปี 1992

อะไรนะ!

ใช่อย่างจริงจัง

นี่คือสิ่งที่: เชลล์เป็นภาษาการเขียนโปรแกรมที่แย่มาก สิ่งเดียวที่มันเกิดขึ้นคือนั่น/bin/shคือตัวแปลสคริปต์เพียงตัวเดียวเท่านั้นที่รับประกันการติดตั้ง Unix ทุกอัน

นี่คือสิ่งอื่น ๆ : ทวนของแกน Perl 5 ล่ามบางคน ( /usr/bin/perl) เป็นมากขึ้นมีแนวโน้มที่จะมีอยู่ในการติดตั้งระบบปฏิบัติการยูนิกซ์สุ่มเลือกกว่า(/(usr|opt)(/(local|sfw|pkg)?)?/bin/bashคือ ภาษาสคริปต์ที่ดีอื่น ๆ (Python, Ruby, node.js เป็นต้น) - ฉันจะใส่ PHP และ Tcl ในประเภทนั้นเมื่อเปรียบเทียบกับเชลล์) นอกจากนี้ยังมีคร่าวๆเช่น bash และ shell ที่ขยายเพิ่มอื่น ๆ

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

ตอนนี้เชลล์สคริปต์แบบธรรมดาชนิดที่เพิ่งรันโปรแกรมสองสามตัวตามลำดับจากงาน cron หรือบางอย่างไม่มีอะไรผิดปกติที่ปล่อยให้มันเป็นเชลล์สคริปต์ แต่สคริปต์เชลล์แบบง่ายไม่ต้องการอาร์เรย์หรือฟังก์ชั่นหรือ[[แม้กระทั่ง และคุณควรเขียนสคริปต์เชลล์ที่ซับซ้อนเฉพาะเมื่อคุณไม่มีทางเลือกอื่น ตัวอย่างเช่นสคริปต์ Autoconf ยังคงเป็นสคริปต์เชลล์อย่างถูกต้อง แต่สคริปต์เหล่านั้นมีการทำงานในทุกชาติ/bin/shที่เกี่ยวข้องกับโปรแกรมที่มีการกำหนดค่า และนั่นหมายความว่าพวกเขาไม่สามารถใช้ส่วนขยายใด ๆ ได้ คุณอาจจะไม่ได้มีการดูแลเกี่ยวกับกรรมสิทธิ์ Unixes เก่าวันนี้ แต่คุณอาจควรดูแลเกี่ยวกับปัจจุบัน BSDs เปิดแหล่งที่มาบางส่วนที่ไม่ได้ติดตั้งbashbusyboxโดยค่าเริ่มต้นและสภาพแวดล้อมที่ให้คุณเพียงเปลือกที่น้อยที่สุดที่ฝังตัวและ

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

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

หากต้องการความกระชับยิ่งขึ้นให้ใช้shหากการพกพาข้ามระบบส่วนใหญ่มีความสำคัญที่สุดและbashหากคุณต้องการใช้คุณสมบัติบางอย่างเช่นอาร์เรย์หากเวอร์ชันของ bash รองรับ

• sh (สำหรับกรณีส่วนใหญ่) ทุบตีหากต้องการเฉพาะ (หรือ ksh หรืออะไรก็ตาม)

เส้นทางที่ปลอดภัยที่สุด เมื่อรหัสฮาร์ดจะเป็น / usr / bin / shellOfChoiceแต่การประชุมใหม่ฉันพยายามที่จะใช้เสมอตอนนี้เป็น 'สถานที่เริ่มต้น' ผ่านการเปลี่ยนแปลงเส้นทางอาจมีการเปลี่ยนแปลง:

#! / usr / bin / env sh หรือ
#! / usr / bin / env ทุบตี
หรือสำหรับเช่นสคริปต์ Perl
#! / usr / bin / env perl -w

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