Шебанг определяет оболочку, которая запускает скрипт?

Это может быть глупый вопрос, но я все же задаю его. Если бы я объявил Шебанг

#!/bin/bash 

в начале my_shell_script.sh, так что я всегда должен вызывать этот скрипт с помощью Bash

[my@comp]$bash my_shell_script.sh

или я могу использовать, например,

[my@comp]$sh my_shell_script.sh

а мой скрипт определяет работающую оболочку с помощью шебанга? То же самое происходит с kshоболочкой? Я использую AIX.

Притон #! является читаемым человеком экземпляр магического числа , состоящего из байтов строки 0x23 0x21, которая используется в exec()семействе функций для определения , является ли файл , который будет выполняться сценарий или двоичным. Когда присутствует exec()shebang, вместо этого будет запускаться исполняемый файл, указанный после shebang.

Обратите внимание, что это означает, что если вы вызываете сценарий, указав интерпретатор в командной строке, как это делается в обоих случаях, приведенных в вопросе, exec()он выполнит интерпретатор, указанный в командной строке, он даже не будет смотреть на сценарий.

Итак, как уже отмечали другие, если вы хотите exec()вызвать интерпретатор, указанный в строке shebang, сценарий должен иметь установленный исполняемый бит и вызываться как ./my_shell_script.sh.

Поведение легко продемонстрировать с помощью следующего скрипта:

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

Объяснение:

• #!/bin/kshопределяет kshбыть переводчиком.

• $$ содержит PID текущего процесса.

• /proc/pid/exe является символической ссылкой на исполняемый файл процесса (по крайней мере, в Linux; в AIX /proc/$$/object/a.out - ссылка на исполняемый файл).

• readlink выведет значение символической ссылки.

Пример:

Примечание : я показываю это на Ubuntu, где оболочка по умолчанию /bin/shявляется символической ссылкой на тир ИЭ /bin/dashи /bin/kshявляется символической ссылкой /etc/alternatives/ksh, которая , в свою очередь , является символической ссылкой на /bin/pdksh.

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

Да. Кстати это не глупый вопрос. Ссылка на мой ответ здесь . Начиная скрипт с #!

• Это называется шебанг или линия "взрыва".

• Это не что иное, как абсолютный путь к интерпретатору Bash.

• Он состоит из знака числа и символа восклицательного знака (#!), За которым следует полный путь к интерпретатору, например / bin / bash.

  Все сценарии в Linux выполняются с использованием интерпретатора, указанного в первой строке. Почти все сценарии bash часто начинаются с #! / Bin / bash (при условии, что Bash был установлен в / bin). Это гарантирует, что Bash будет использоваться для интерпретации сценария, даже если он выполняется под другой оболочкой. Шебанг был представлен Деннисом Ричи между версией 7 Unix и 8 в Bell Laboratories. Затем он был также добавлен к линии BSD в Беркли.

Игнорирование строки переводчика (шебанг)

Если вы не укажете строку интерпретатора, по умолчанию обычно используется / bin / sh. Но рекомендуется установить #! / Bin / bash line.

execСистемный вызов ядра Linux понимает shebangs ( #!) изначально

Когда вы делаете на Bash:

./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файлов . Этот механизм даже поддерживает обработчики по расширению файла. Другое приложение - для прозрачного запуска исполняемых файлов другой архитектуры с 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. Как и ожидалось, содержимое файла выводится. В этом случае кошка не игнорирует линию Шебанга. Он просто выводит все строки. Таким образом, любой полезный интерпретатор должен игнорировать эту строку Шебанга. Для bash, perl и PHP это просто строка комментария. Так что да, они игнорируют линию Шебанга.

Из того, что я собрал, всякий раз, когда файл имеет установленный исполняемый бит и вызывается, ядро ​​анализирует заголовок файла, чтобы определить, как поступить (насколько я знаю, вы можете добавить собственные обработчики для пользовательских форматов файлов через LKM). Если файл выглядит как текстовый файл с #! В начале в комбинации его выполнение отправляется другому исполняемому файлу (обычно это своего рода оболочка), путь к которому должен быть указан непосредственно после указанного шебанга в той же строке. Затем ядро ​​переходит к выполнению оболочки и передает файл для обработки.

Короче говоря, не имеет значения, с какой оболочкой вы вызываете скрипт - ядро ​​в любом случае отправит выполнение соответствующему.