shebang พิจารณาเชลล์ที่รันสคริปต์หรือไม่

นี่อาจเป็นคำถามที่โง่ แต่ฉันก็ยังถาม ถ้าฉันได้ประกาศ shebang

#!/bin/bash 

ในตอนต้นของmy_shell_script.shฉันจะต้องเรียกใช้สคริปต์นี้โดยใช้ทุบตี

[my@comp]$bash my_shell_script.sh

หรือฉันสามารถใช้เช่น

[my@comp]$sh my_shell_script.sh

และสคริปท์ของฉันกำหนดเชลล์ที่กำลังใช้งานอยู่โดยใช้ shebang? มันเกิดขึ้นเหมือนกันกับkshเชลล์ไหม? ฉันใช้ AIX

shebang #!เป็นตัวอย่างการอ่านของมนุษย์ของจำนวนมายากลประกอบด้วยสตริงไบต์0x23 0x21ซึ่งถูกใช้โดยexec()ครอบครัวของฟังก์ชั่นเพื่อตรวจสอบว่าไฟล์ที่จะดำเนินการเป็นสคริปต์หรือไบนารี เมื่อ shebang ปรากฏขึ้นให้exec()เรียกใช้ไฟล์ปฏิบัติการที่ระบุหลังจาก shebang แทน

โปรดทราบว่านี่หมายความว่าหากคุณเรียกใช้สคริปต์โดยการระบุล่ามในบรรทัดคำสั่งเช่นเดียวกับที่ทำในทั้งสองกรณีที่กำหนดในคำถามexec()จะดำเนินการล่ามที่ระบุในบรรทัดคำสั่งมันจะไม่ดูสคริปต์ด้วยซ้ำ

ดังนั้นกับคนอื่น ๆ ได้ตั้งข้อสังเกตถ้าคุณต้องการexec()ที่จะเรียกล่ามระบุในบรรทัด shebang ./my_shell_script.shสคริปต์จะต้องมีบิตปฏิบัติการตั้งค่าและเรียกว่าเป็น

ลักษณะการทำงานนั้นง่ายต่อการสาธิตด้วยสคริปต์ต่อไปนี้:

#!/bin/ksh
readlink /proc/$$/exe

คำอธิบาย:

• #!/bin/kshกำหนดkshให้เป็นล่าม

• $$ เก็บ PID ของกระบวนการปัจจุบัน

• /proc/pid/exe คือ symlink ไปยัง executable ของกระบวนการ (อย่างน้อยบน Linux; บน AIX, /proc/$$/object/a.out เป็นลิงค์ไปยัง executable)

• readlink จะเอาท์พุทค่าของลิงค์สัญลักษณ์

ตัวอย่าง:

หมายเหตุ : ฉันแสดงให้เห็นถึงนี้บน Ubuntu ที่เปลือกเริ่มต้น/bin/shเป็น symlink ไปรีบ IE /bin/dashและ/bin/kshเป็น symlink ไป/etc/alternatives/kshซึ่งจะเป็น symlink /bin/pdkshไป

$ chmod +x getshell.sh
$ ./getshell.sh 
/bin/pdksh
$ bash getshell.sh 
/bin/bash
$ sh getshell.sh 
/bin/dash

ใช่แล้ว. โดยวิธีการที่มันไม่ใช่คำถามที่โง่ การอ้างอิงสำหรับคำตอบของฉันคือที่นี่ เริ่มต้นสคริปต์ด้วย #!

• มันถูกเรียกว่า Shebang หรือเส้น "ปัง"

• มันไม่มีอะไรนอกจากเส้นทางที่แน่นอนไปยังล่าม Bash

• ประกอบด้วยเครื่องหมายตัวเลขและอักขระเครื่องหมายอัศเจรีย์ (#!) ตามด้วยเส้นทางแบบเต็มไปยังล่ามเช่น / bin / bash

  สคริปต์ทั้งหมดภายใต้ Linux ดำเนินการโดยใช้ล่ามที่ระบุในบรรทัดแรกเกือบทุกสคริปต์ทุบตีมักจะเริ่มต้นด้วย #! / bin / bash (สมมติว่าติดตั้ง Bash ใน / bin) ทำให้มั่นใจได้ว่า Bash จะใช้ในการตีความสคริปต์แม้ ถ้ามันถูกดำเนินการภายใต้เปลือกอื่น shebang ได้รับการแนะนำโดย Dennis Ritchie ระหว่าง Version 7 Unix และ 8 ที่ Bell Laboratories จากนั้นจะถูกเพิ่มเข้าไปยังบรรทัด BSD ที่ Berkeley

ไม่สนใจบรรทัดล่าม (shebang)

หากคุณไม่ได้ระบุบรรทัดล่ามค่าเริ่มต้นมักจะเป็น / bin / sh แต่ขอแนะนำให้คุณตั้งค่า #! / bin / bash

การexecเรียกระบบของเคอร์เนล Linux เข้าใจ shebangs ( #!) โดยกำเนิด

เมื่อคุณทุบตี:

./something

บน Linux นี้เรียกสายระบบกับเส้นทางexec./something

บรรทัดของเคอร์เนลนี้ถูกเรียกบนไฟล์ที่ส่งผ่านไปยังexec: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_script.c#L25

if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))

#!มันอ่านไบต์แรกของไฟล์และเปรียบเทียบพวกเขาไป

หากการเปรียบเทียบเป็นจริงดังนั้นส่วนที่เหลือของบรรทัดจะถูกวิเคราะห์โดยเคอร์เนล Linux ซึ่งทำให้การexecเรียกด้วยพา ธ/usr/bin/env pythonและไฟล์ปัจจุบันเป็นอาร์กิวเมนต์แรก:

/usr/bin/env python /path/to/script.py

และใช้ได้กับภาษาสคริปต์ใด ๆ ที่ใช้#เป็นอักขระความคิดเห็น

และใช่คุณสามารถสร้างวงวนไม่สิ้นสุดด้วย:

printf '#!/a\n' | sudo tee /a
sudo chmod +x /a
/a

Bash รู้จักข้อผิดพลาด:

-bash: /a: /a: bad interpreter: Too many levels of symbolic links

#! เพิ่งเกิดขึ้นกับมนุษย์อ่านได้ แต่ไม่จำเป็น

หากไฟล์เริ่มต้นด้วยไบต์ที่แตกต่างกันการexecเรียกของระบบจะใช้ตัวจัดการที่แตกต่างกัน ตัวจัดการในตัวที่สำคัญที่สุดสำหรับไฟล์เรียกทำงานของ ELF: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_elf.c#L1305ซึ่งจะตรวจสอบไบต์7f 45 4c 46(ซึ่งเกิดขึ้นกับมนุษย์ด้วย) สามารถอ่านได้สำหรับ.ELF) เรามายืนยันว่าโดยการอ่าน 4 ไบต์แรกของ/bin/lsซึ่งเป็นปฏิบัติการ ELF:

head -c 4 "$(which ls)" | hd 

เอาท์พุท:

00000000  7f 45 4c 46                                       |.ELF|
00000004                                                                 

ดังนั้นเมื่อเคอร์เนลเห็นไบต์เหล่านั้นจะใช้ไฟล์ ELF วางลงในหน่วยความจำอย่างถูกต้องและเริ่มกระบวนการใหม่ด้วย ดูเพิ่มเติมที่: https://stackoverflow.com/questions/8352535/how-does-kernel-get-an-executable-binary-file-running-under-linux/31394861#31394861

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

ฉันไม่คิดว่า POSIX จะระบุ shebangs อย่างไรก็ตาม: https://unix.stackexchange.com/a/346214/32558ถึงแม้ว่ามันจะพูดถึงมันในส่วนของเหตุผลและในรูปแบบ "ถ้าสคริปต์ที่สนับสนุนการดำเนินการได้รับการสนับสนุนจากระบบ อาจเกิดขึ้น "

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

#!/bin/cat
useless text
more useless text
still more useless text

ตั้งชื่อ test.txt ไฟล์และการตั้งค่าบิต exectuable chmod u+x test.txtแล้ว "เรียกว่า" ./test.txtมัน ตามที่คาดไว้เนื้อหาของไฟล์จะถูกส่งออก ในกรณีนี้แมวจะไม่เพิกเฉยต่อเส้น Shebang มันเพียงแค่ส่งออกสายทั้งหมด ล่ามที่มีประโยชน์ใด ๆ จึงควรละเว้นบรรทัด shebang นี้ สำหรับ bash, perl และ PHP เป็นเพียงบรรทัดความคิดเห็น ใช่แล้วสิ่งเหล่านี้ไม่สนใจเส้น Shebang

จากสิ่งที่ฉันรวบรวมเมื่อใดก็ตามที่ไฟล์มีชุดบิตที่ปฏิบัติการได้และถูกเรียกใช้เคอร์เนลจะวิเคราะห์ส่วนหัวของไฟล์เพื่อกำหนดวิธีดำเนินการ (เท่าที่ฉันรู้คุณสามารถเพิ่มตัวจัดการแบบกำหนดเองสำหรับรูปแบบไฟล์แบบกำหนดเองผ่าน LKMs) หากไฟล์ดูเหมือนจะเป็นไฟล์ข้อความที่มี #! การรวมกันในตอนเริ่มต้นการประมวลผลจะถูกส่งไปยังไฟล์ปฏิบัติการอื่น (โดยปกติจะเป็นเชลล์ประเภท) เส้นทางที่จะถูกระบุโดยตรงหลังจาก Shebang ดังกล่าวในบรรทัดเดียวกัน เคอร์เนลจะดำเนินการเพื่อดำเนินการเชลล์และส่งไฟล์เพื่อจัดการ

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