Почему скрипт bash работает без .sh?
У меня есть скрипт bash, который по ошибке был назван .py (например, test.py) Этот скрипт работает без проблем. (./test.py) Если это может быть полезно, вот информация из команды ls -l: -rwxr-xr-x.
Мой вопрос в том, почему скрипт (test.py) выполняется без правильного имени (test.sh) Может ли это вызвать проблему?
Содержимое скрипта выглядит так:
#!/bin/bash
export SINGULARITYENV_LC_ALL=C.UTF-8
export SINGULARITYENV_LANG=C.UTF-8
CONTAINER=/mnt/pynet-pytorch-181.sif
# Pretrain
DATA=/mnt/Dataset/
EXPERIMENT_NAME=./2022_12_16/
srun -c 4 --gres=gpu:a6000:1 --mem=32G singularity exec -B /mnt:/mnt/ \
--nv $CONTAINER \
python train.py --dataroot $DATA \
--device "cuda" \
--pre_denoising False \
--experiment_name $EXPERIMENT_NAME \
--epochs 200
Я попытался запустить другой скрипт bash с той же проблемой именования *.py снова он выполняется без проблем. Хотя я не понимаю, почему это работает.
Ответы 1
Unix не заботятся о расширениях.
Если файл является исполняемым + доступным для чтения (для двоичных файлов он даже не должен быть доступным для чтения) и начинается с #!, исполняемый файл, который следует за ним, вызывается с именем скрипта в качестве аргумента.
В вашем случае ОС выполнит /bin/bash path_to_your_script YourArguments.... И bash тоже не заботится о расширениях.
Примечание: для лучшей переносимости вы можете использовать #!/urs/bin/env bash вместо #!/bin/bash, так как не во всех системах есть bash в /bin/bash (env будет искать фактический путь, используя переменную окружения $PATH). Или просто используйте оболочку POSIX в /bin/sh.
Как предлагает Эллиот Фриш , вы также можете прочитать https://en.wikipedia.org/wiki/Shebang_(Unix), особенно если вы хотите возиться с пользовательскими строками шебанга, потому что строки шебанга сами по себе не являются скриптами и ограничены по длине (например, 128 или 256 байт) и передаче аргументов: а именно, они поддерживают только аргумент.
См. также статью в Википедии о shebang
/usr/bin/env не имеет ничего общего с переносимостью. 1) Стандарт POSIX не требует, чтобы он присутствовал, и 2) если он присутствует, его не требуется устанавливать под /usr/bin, и 3) он просто перекладывает ответственность за поиск соответствующего интерпретатора с установщика (который должен нести ответственность за установку правильного шебанга, а не автора) для конечного пользователя (который должен знать, какой интерпретатор необходим, и гарантировать, что его можно найти с помощью поиска пути).
Кроме того, /usr/bin/env bash не приносит никакой пользы, если пользователь PATH не находит нужную версию bash, требуемую сценарием.
@chepner Наиболее портативно просто использовать /bin/sh, но если вам нужен bash, /usr/bin/env bash пока мне больше всего помог. (Пытались использовать сценарии, работающие в Linux, Cygwin, FreeBSD и MacOS).
Скорее всего, единственные пользователи, которые видят положительную разницу, — это пользователи macOS, которые установили более новую версию bash наряду со старой /bin/bash, которую Apple до сих пор поставляет. (И большинство из них, вероятно, достаточно осведомлены, чтобы редактировать шебанг или просто игнорировать шебанг в пользу bash ....) Насколько переносимым станет ваш скрипт, если вы начнете использовать функции, характерные для bash 5 или выше? Насколько я знаю, большинство дистрибутивов ОС по-прежнему поставляются с bash 4.4 (или даже раньше), несмотря на то, что bash 5 была выпущена почти 4 года назад.
Это работает из-за
#!/bin/bashв начале скрипта. Она называется шебанг: en.wikipedia.org/wiki/Shebang_(Unix).