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

Да это делает. По тому, как это не глупый вопрос. Ссылка для моего ответа здесь. Запуск Сценария С #!

• Это называют хижиной или строкой "удара".

• Это - только полный путь к интерпретатору Bash.

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

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

Игнорирование строки интерпретатора (хижина)

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

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

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

Фактически, если вы так понимаете, исполняемый файл, указанный в строке shebang, является просто исполняемым файлом. Имеет смысл использовать какой-нибудь текстовый интерпретатор в качестве исполняемого файла, но в этом нет необходимости. Просто для пояснения и демонстрации я провел довольно бесполезный тест:

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

Назвал файл test.txt и установил исполняемый бит chmod u + x test.txt , затем «назвал» его: ./test.txt . Как и ожидалось, выводится содержимое файла. В этом случае кошка не игнорирует линию шебанг. Он просто выводит все строки. Таким образом, любой полезный интерпретатор должен иметь возможность игнорировать эту строку shebang. Для bash, perl и PHP это просто строка комментария. Так что да, они игнорируют строку shebang.

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

Я не заметил, что OP спрашивал об AIX, я собираюсь сказать, что я знаю о Linux, и держу пари, что есть сильные аналогии или, по крайней мере, удовлетворят большинство гуглеров, которые ищут Linux:-)

Когда вы делаете на 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 определяет шебанги :https://unix.stackexchange.com/a/346214/32558, хотя упоминает об этом в разделах обоснования и в форме "если исполняемые скрипты поддерживаются системой, что-то может произойти".