Чтобы запустить неисполняемый сценарий sh , используйте:

sh myscript

Для запуска неисполняемого bash сценарий, используйте:

bash myscript

Для запуска исполняемого файла (который представляет собой любой файл с разрешениями на выполнение); вы просто указываете его по пути:

/foo/bar
/bin/bar
./bar

Чтобы сделать скрипт исполняемым, дайте ему необходимое разрешение:

chmod +x bar
./bar

Когда файл является исполняемым, ядро ​​ отвечает за выяснение того, как его запустить. Для небинарных файлов это делается путем просмотра первой строки файла. Он должен содержать хэш-код :

#! /usr/bin/env bash

Хэш-код сообщает ядру, какую программу следует запустить (в этом случае команда / usr / bin / env запускается с аргументом bash ). Затем сценарий передается программе (в качестве второго аргумента) вместе со всеми аргументами, которые вы дали сценарию в качестве последующих аргументов.

Это означает , что каждый исполняемый скрипт должен иметь хэш-банг . Если это не так, вы не сообщаете ядру, что оно , и поэтому ядро ​​не знает, какую программу использовать для его интерпретации. Это может быть bash , perl , python , sh или что-то еще. (На самом деле ядро ​​часто будет использовать оболочку пользователя по умолчанию для интерпретации файла, что очень опасно, потому что это может быть неправильный интерпретатор вообще или оно может быть в состоянии проанализировать некоторые из них, но с небольшими поведенческими различиями, такими как случай между sh и bash ).

Замечание по / usr / bin / env

Чаще всего вы увидите такие хэш-взломы:

#!/bin/bash

В результате ядро ​​запускает программу / bin / bash для интерпретации сценария. К сожалению, bash не всегда поставляется по умолчанию и не всегда доступен в / bin . Хотя на машинах Linux это обычно так, существует ряд других машин POSIX, на которых bash поставляется в разных местах, например / usr / xpg / bin / bash или / usr / local / bin / bash .

Поэтому, чтобы написать переносимый сценарий bash, мы не можем полагаться на жесткое кодирование местоположения программы bash . В POSIX уже есть механизм для решения этой проблемы: PATH . Идея состоит в том, что вы устанавливаете свои программы в один из каталогов, которые находятся в PATH , и система должна иметь возможность найти вашу программу, когда вы захотите запустить ее по имени.

К сожалению, вы не можете просто сделать это:

#!bash

Ядро не будет (некоторые могут) выполнять поиск PATH за вас. Существует программа, которая может выполнять поиск по PATH за вас, но она называется env . К счастью, почти все системы имеют программу env , установленную в / usr / bin . Итак, мы запускаем env , используя жестко запрограммированный путь, который затем выполняет PATH поиск bash и запускает его, чтобы он мог интерпретировать ваш сценарий:

#!/usr/bin/env bash

Это У подхода есть одна обратная сторона: согласно POSIX, хэшбэнг может иметь один аргумент . В этом случае мы используем bash в качестве аргумента программы env . Это означает, что у нас не осталось места для передачи аргументов в bash . Так что нет возможности преобразовать что-то вроде #! / Bin / bash -exu в эту схему. Вместо этого вам нужно будет поставить set -exu после хэшбэнга.

У этого подхода есть еще одно преимущество: некоторые системы могут поставляться с / bin / bash , но пользователю он может не понравиться, он может найти его ошибочным или устаревшим и, возможно, установил свой собственный ] bash где-нибудь еще. Это часто имеет место в OS X (Mac), где Apple отправляет устаревший / bin / bash , а пользователи устанавливают обновленный / usr / local / bin / bash , используя что-то вроде Homebrew. Когда вы используете подход env , который выполняет поиск PATH , вы принимаете во внимание предпочтения пользователя и используете его предпочтительный bash вместо того, с которым его система поставляла.