как запустить скрипт shell на консоли unix или mac?

<p>я знаю это, забудь об этом и заново изучи. время записать это.</p>

<p>чтобы запустить неисполняемый скрипт <code>sh</code>, используйте:</p><pre><code>sh myscript </code></pre><p>чтобы запустить неисполняемый скрипт <code>bash</code>, используйте:</p><pre><code>bash myscript </code></pre><p>запустить исполняемый файл (любой файл с разрешением на выполнение); вы просто указываете его по пути:</p><pre><code>/foo/bar /bin/bar ./bar </code></pre><p>чтобы сделать скрипт исполняемым, дайте ему необходимое разрешение:</p><pre><code>chmod +x bar ./bar </code></pre><p>когда файл является исполняемым,<strong> kernel </strong>отвечает за выяснение того, как его выполнить. для недвоичных файлов это делается путем просмотра первой строки файла. он должен содержать <code>hashbang</code>:</p><pre><code>#! /usr/bin/env bash </code></pre><p>hashbang сообщает ядру, какую программу запустить (в этом случае команда <code>/usr/bin/env</code> запускается с аргументом <code>bash</code>). затем сценарий передается программе (в качестве второго аргумента) вместе со всеми аргументами, которые вы указали сценарию в качестве последующих аргументов.</p><p>это означает, что<strong> каждый исполняемый скрипт должен иметь хеш-банг </strong>. если это не так, вы не говорите ядру, что это <em>is</em>, и поэтому ядро не знает, какую программу использовать для его интерпретации. это может быть <code>bash</code>, <code>perl</code>, <code>python</code>, <code>sh</code> или что-то еще. (на самом деле ядро часто использует оболочку пользователя по умолчанию для интерпретации файла, что очень опасно, потому что он может вообще не быть подходящим интерпретатором или может анализировать некоторые из них, но с небольшими поведенческими различиями, такими как случай между <code>sh</code> и <code>bash</code>).</p><h1>примечание к <code>/usr/bin/env</code></h1><p>чаще всего вы увидите такие хэш-челки:</p><pre><code>#!/bin/bash </code></pre><p>в результате ядро запустит программу <code>/bin/bash</code> для интерпретации сценария. к сожалению, <code>bash</code> не всегда поставляется по умолчанию и не всегда доступен в <code>/bin</code>. в то время как на машинах linux это обычно так, есть ряд других машин posix, где <code>bash</code> поставляется в разных местах, таких как <code>/usr/xpg/bin/bash</code> или <code>/usr/local/bin/bash</code>.</p><p>поэтому для написания переносимого скрипта bash мы не можем полагаться на жесткое программирование местоположения программы <code>bash</code>. posix уже имеет механизм для решения этой проблемы: <code>path</code>. идея состоит в том, что вы устанавливаете свои программы в один из каталогов, находящихся в <code>path</code>, и система должна быть в состоянии найти вашу программу, когда вы захотите запустить ее по имени.</p><p>к сожалению, вы<strong> <em>не можете</em> </strong>просто сделайте это:</p><pre><code>#!bash </code></pre><p>ядро не будет (некоторые могут) выполнять поиск <code>path</code> для вас. существует программа, которая может выполнять поиск <code>path</code>, однако она называется <code>env</code>. к счастью, почти во всех системах программа <code>env</code> установлена в <code>/usr/bin</code>. поэтому мы запускаем <code>env</code>, используя жестко заданный путь, который затем <code>path</code> ищет <code>bash</code> и запускает его, чтобы он мог интерпретировать ваш скрипт:</p><pre><code>#!/usr/bin/env bash </code></pre><p>у этого подхода есть один недостаток: согласно posix, hashbang может иметь<strong> один аргумент </strong>. в этом случае мы используем <code>bash</code> в качестве аргумента программы <code>env</code>. это означает, что у нас нет места для передачи аргументов в <code>bash</code>. так что нет способа конвертировать что-то вроде <code>#!/bin/bash -exu</code> в эту схему. вы должны будете поставить <code>set -exu</code> после хеш-бенга.</p><p>этот подход также имеет еще одно преимущество: некоторые системы могут поставляться с <code>/bin/bash</code>, но пользователю может не понравиться этот код, он может обнаружить, что он содержит ошибки или устарел, и, возможно, установил свою собственную <code>bash</code> где-то еще. это часто имеет место в os x (mac), где apple поставляет устаревший <code>/bin/bash</code>, и пользователи устанавливают обновленный <code>/usr/local/bin/bash</code>, используя что-то вроде homebrew. когда вы используете подход <code>env</code>, который выполняет поиск <code>path</code>, вы учитываете предпочтения пользователя и используете его предпочтительный bash по сравнению с тем, который поставлялась его системой.</p>

<p>чтобы запустить shell-скрипт 'file.sh':</p><pre><code>sh file.sh bash file.sh </code></pre><p>другой вариант - установить разрешение на выполнение с помощью команды chmod:</p><pre><code>chmod +x file.sh </code></pre><p>теперь запустите файл .sh следующим образом:</p><pre><code>./file.sh </code></pre>

<p>для bourne shell:</p><pre><code>sh myscript.sh </code></pre><p>для баш:</p><pre><code>bash myscript.sh </code></pre>

<p>если вы хотите, чтобы скрипт выполнялся в текущей оболочке (например, вы хотите, чтобы он мог влиять на ваш каталог или среду), вы должны сказать:</p><pre><code>. /path/to/script.sh </code></pre><p>или же </p><pre><code>source /path/to/script.sh </code></pre><p>обратите внимание, что <code>/path/to/script.sh</code> может быть относительным, например, <code>. bin/script.sh</code> запускает <code>script.sh</code> в каталоге <code>bin</code> в текущем каталоге.</p>

<p>расширение файла .command назначено terminal.app. двойной щелчок на любом файле .command запустит его.</p>

<p>сначала дайте разрешение на исполнение: -<br> <code>chmod +x script\_name</code> </p><ol> <li>если скрипт не является исполняемым: -<br> для запуска файла сценария sh: -<br> <code>sh script\_name</code><br> для запуска файла сценария bash: -<br> <code>bash script\_name</code></li> <li>если скрипт исполняемый: -<br> <code>./script\_name</code></li> </ol><p><strong> <em>note</em> </strong>: - вы можете проверить, является ли файл исполняемым или нет, используя 'ls -a'</p>