что значит строка bin bash
Зачем нужно ставить #!/bin / bash в начале файла сценария?
Я сделал Баш скрипты раньше, и все они работали нормально без этого в начале. Какой смысл в этом? Будет ли все по-другому?
8 ответов
это соглашение, поэтому оболочка *nix знает, какой интерпретатор запускать.
например, старые ароматы ATT по умолчанию ш (оболочка Борна), в то время как более старые версии BSD по умолчанию csh (оболочка C).
за ним должен следовать путь к файлу исполняемого интерпретатора (который BTW может быть даже относительным, но чаще всего абсолютный.)
ваша точка зрения об этом «работает» даже без shebang только потому, что программа, о которой идет речь, является сценарием оболочки, написанным для той же оболочки, что и та, которую вы используете. Например, вы можете очень хорошо написать файл javascript, а затем поставить #! /usr/bin/js (или что-то подобное), чтобы иметь оболочку javascript сценарий.»
операционная система принимает оболочку по умолчанию для запуска сценария оболочки. поэтому, упоминая путь оболочки в начале скрипта, вы просите ОС использовать эту конкретную оболочку. Это также полезно для мобильность.
каждый дистрибутив имеет оболочку по умолчанию. Bash является значением по умолчанию для большинства систем. Если вы работаете в системе с другой оболочкой по умолчанию, сценарии могут работать не так, как предполагалось, если они написаны специально для Bash.
добавлять #!/bin/bash как первая строка вашего скрипта, сообщает ОС, чтобы вызвать указанный shell для выполнения следующих команд сценарий.
#! часто называют «хэш-Банг», «она-Банг»или» Ша-Банг».
Это называется shebang. Он состоит из знака и восклицательного знака (#!), за которым следует полный путь к интерпретатору, например /bin / bash. Все скрипты под UNIX и Linux выполняются с помощью интерпретатора, указанного в первой строке.
Это может быть полезно для тех, кто использует другую систему, которая не имеет эту библиотеку легко доступны. Если это не объявлено, и у вас есть некоторые функции в скрипте, которые не поддерживаются этой системой, вы должны объявить #/bin/bash. Я столкнулся с этой проблемой раньше на работе, и теперь я просто включаю ее в качестве практики.
Зачем нужно ставить #! / Bin / bash в начале файла сценария?
Раньше я создавал скрипты Bash, и все они отлично работали без #!/bin/bash в начале.
Какой смысл вставлять? Было бы все иначе?
10 ответов
Это соглашение, поэтому оболочка * nix знает, какой интерпретатор запускать.
Например, в старых версиях ATT по умолчанию использовалась sh (оболочка Bourne), а в более старых версиях BSD по умолчанию использовалась csh (оболочка C).
За ним должен следовать путь к файлу исполняемого файла интерпретатора (который, кстати, может быть даже относительным, но чаще всего абсолютным).
Это может быть полезно для тех, кто использует другую систему, в которой эта библиотека недоступна. Если это не объявлено, и в вашем скрипте есть некоторые функции, которые не поддерживаются этой системой, вам следует объявить # / bin / bash. Я сталкивался с этой проблемой раньше на работе, и теперь я просто включаю ее в качестве практики.
Bash часто является оболочкой по умолчанию в большинстве дистрибутивов Linux. Вот почему bash является синонимом оболочки.
Сценарии оболочки часто имеют почти одинаковый синтаксис, но иногда они различаются. Например, индекс массива начинается с 1 в Zsh вместо 0 в bash. Сценарий, написанный для оболочки Zsh, не будет работать так же в bash, если в нем есть массивы.
Чтобы избежать неприятных сюрпризов, вы должны сообщить интерпретатору, что ваш сценарий оболочки написан для оболочки bash. Как ты это делаешь?
Просто начните свой сценарий bash в #! / bin / bash
В каждом дистрибутиве есть оболочка по умолчанию. Bash используется по умолчанию в большинстве систем. Если вы работаете в системе с другой оболочкой по умолчанию, сценарии могут работать не так, как задумано, если они написаны специально для Bash.
Добавление #!/bin/bash в качестве первой строки вашего сценария указывает операционной системе вызвать указанный shell для выполнения команд, которые следуют в сценарии.
#! часто называют «хэш-бах», «ша-бах» или «ша-бах».
Ваша точка зрения на то, что он «работает» даже без shebang, заключается только в том, что рассматриваемая программа является сценарием оболочки, написанным для той же оболочки, что и та, которую вы используете. Например, вы могли бы очень хорошо написать файл javascript, а затем поместить #! /usr/bin/js (или что-то подобное), чтобы получить «сценарий оболочки» javascript.
Операционная система использует оболочку по умолчанию для запуска вашего сценария оболочки. поэтому, упоминая путь к оболочке в начале скрипта, вы просите ОС использовать эту конкретную оболочку. Это также полезно для переносимости.
Что делает строка»#!/bin / sh» означает в сценарии оболочки UNIX?
Я просматривал некоторые учебники по сценарию оболочки и нашел следующий пример программы:
5 ответов
Это называется shebang, и сообщает родительской оболочке, какой интерпретатор должен использоваться для выполнения сценария.
когда вы пытаетесь выполнить программу в unix (с исполняемым битом), операционная система будет смотреть на первые несколько байтов файла. Они образуют так называемое» магическое число», с помощью которого можно определить формат программы и способ ее выполнения.
#! соответствует магическому номеру 0x2321 (посмотрите его в таблице ascii). Когда система видит это магическое число, она знает, что имеет дело с текстовым скриптом и читает до следующего \n (есть предел, но он ускользает от меня атм). Определив интерпретатор (первый аргумент после shebang), он вызовет интерпретатора.
здесь статья в Википедии об этом для получения дополнительной информации.
первая строка сообщает оболочке, что если вы выполняете скрипт напрямую (. /run.sh; в отличие от /bin/sh run.sh), он должен использовать эту программу (/bin/sh в этом случае) для ее интерпретации.
вы также можете использовать его для передачи аргументов, обычно-e (выход при ошибке) или использовать другие программы (/bin/awk, /usr/bin/perl и т. д.).
#!/bin/sh или #!/bin/bash должна быть первая строка скрипта, потому что если вы не используете его в первой строке, система будет рассматривать все команды в этом скрипте как разные команды. Если первая строка #!/bin/sh тогда он будет рассматривать все команды как один скрипт, и он покажет, что этот файл работает в ps command, а не команды внутри файла.
Что такое bash / shell
И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls… (в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
Например, создадим скриптик, который создаст директорию и в ней файлик:
И даже если у такого файла не будет расширения вовсе, его можно будет запустить как скрипт:
Расширение .sh ставится для понимания человеком. Зашел в директорию:
— Ага, что тут у нас? Файлы sh, скрипты какие-то лежат.
Скрипты могут быть простые, а могут быть сложные. Вот, например, в одном проекте мы вначале вручную обновляли тестовые платформы. Для обновления надо:
Переподложить war-файл с приложением (лежат они в директории /opt)
Сервиса два, допустим это test и cloud. Так что шагов уже 6.
Когда обновлять вручную надоело, мы положили на все линукс машины простой скриптик:
Собираешь приложение, подкладываешь к скриптику и запускаешь 1 команду вместо 6. Удобно! Это называется «автоматизация рутины» =)
Другой пример с того же проекта — мы делали серверное приложение. И во время установки приложения на сервере linux нужно выполнить пункты по настройке самой системы. Например, увеличить параметр max_map_count — сколько максимум памяти может использовать процесс.
Приложение в пике работы требует много памяти. Если не настроить параметр, то «тяжеловесная» задача просто упадет с ошибкой «Не хватает памяти». И если мы видим такую ошибку, то в первую очередь идем проверять настройки системы.
Вообще, если вы отдаете установку приложения на откуп «чужим» админам, лучше потом проверять — а всё ли настроено верно? Конечно, обычно на production (машина, с которой работают реальные пользователи) настраивают всё внимательно, это на тестовых стендах могут что-то пропустить. Но лучше перебдеть!
Мы написали скрипт по проверке настройки окружения (символ «#» в начале строки означает, что это комментарий):
В итоге админы настраивают окружение, а потом мы даем им скрипт, просим запустить его и прислать результаты. Я запустила скрипт на «голой» системе, где, разумеется, параметры настроены не были, и вот ответ:
Видим, что все проверки провалились, статус failed. Если и от админов приходит похожая картина, направляем их в документацию по настройке системы. Если к нам приходят с проблемой падения из-за нехватки памяти, снова просим выполнить скрипт. Так проще локализовать ошибку: это в приложении косяк, или окружение настроено плохо?
Просить других людей выполнить 10 команд не очень хорошо. Потому что часть команд может «потеряться» при выполнении — плохо скопировал, забыл выполнить проверку, которую дали сообщением позже. Гораздо проще сделать 1 скрипт и попросить выполнить именно его.
Когда надо писать скрипт?
Когда надо выполнить больше 3 команд за раз — проще выполнить одну, запустить скрипт.
Когда одну и ту же команду надо выполнять чаще 3 раз — лучше автоматизировать эту работу.
По сути своей, bash-скрипты — это та же автоматизация. А когда нужна автоматизация? Когда мы хотим избавиться от рутины, от постоянного выполнения одного и того же действия вручную. Повторяете одно и то же каждый день / неделю? Напишите скрипт. Даже если он на 2-3 строчки будет, это правда удобнее. Поверьте, сама делала небольшие скрипты =)
См также по bash:
Основы BASH. Часть 1 (Хабр) — цикл статей о том, как писать скрипты
См также другие статьи из цикла «Что такое. »:
Введение в Bash Shell
Всем привет. Это перевод из книги по подготовке к экзамену RedHat RHCE. На мой взгляд очень доступно рассказывается об основах bash.
Сценарии оболочки — наука сама по себе. Не вдаваясь в подробности всего, что происходит «под капотом», вы узнаете, как применять базовые элементы для написания собственных скриптов, и анализировать, что происходит в сторонних сценариях оболочки.
Понимание основных элементов сценариев оболочки
По сути, сценарий оболочки представляет собой список команд, которые выполняются последовательно, а также некоторую логику, позволяющую выполнять код только при определённых условиях.
Чтобы понять сложные сценарии оболочки, рекомендуется начать с базовых сценариев.
Ниже показан очень простой скрипт:
Здесь содержатся несколько элементов, которые должны использоваться во всех скриптах. Для начала, есть shebang — это строка #!/bin/bash. Когда скрипт запускается из родительской оболочки, он открывает подоболочку, в которой и выполняются команды, указанные в скрипте.
Эти команды могут быть интерпретированы различными способами. Для того, чтобы понять, как именно они должны интерпретироваться, используется shebang. В примере выше shebang ясно даёт понять, что скрипт должен выполняться оболочкой bash.
Также могут быть указаны другие оболочки. Например, если ваш скрипт содержит код на языке Perl, shebang должен быть #!/usr/bin/perl. Начинать сценарий с shebang является хорошей практикой; если он опущен, код сценария будет выполняться такой же оболочкой, которая используется для запуска скрипта.
Сразу после shebang расположена часть, объясняющая, о чем сценарий. Несколько строк комментариев в начале каждого сценария — хорошая идея. В коротком скрипте часто очевидно, что он делает, но когда сценарий становится длиннее, и по мере того, как всё больше людей вовлекаются в его написание и поддержку, становится менее понятно, что авторы намереваются сделать.
Чтобы избежать такой ситуации, убедитесь, что вы добавили строки комментариев, начиная каждую символом #. Комментарии могут быть не только в первых строках, но и в начале каждого подраздела сценария. Это наверняка поможет, если вы прочитаете свой скрипт через несколько месяцев!
Вы также можете комментировать не только подразделы, но и отдельные строки.
Независимо от того, в какой позиции он используется, всё от символа # и до конца строки является комментарием.
После блока комментариев расположено тело сценария. В вышеуказанном примере это несколько команд, выполняющихся последовательно. Тело сценария оболочки может увеличиваться по мере его развития.
В конце скрипта я включил инструкцию exit 0. Оператор выхода сообщает родительской оболочке, был ли сценарий успешным. Состояние выхода последней команды в сценарии является состоянием выхода самого сценария, если только команда exit 0 не используется в конце сценария.
Полезно знать, что вы можете работать с exit, чтобы сообщить родительской оболочке, как все прошло.
Также вы можете разместить сценарий в каталоге /bin, после чего в любом месте файловой системы просто ввести имя файла, и сценарий выполнится.
Командой vi /bin/datetime создадим в каталоге /bin файл с именем datetime. В созданный файл вставим это содержимое:
Сохранив файл, введите chmod +x /bin/datetime, чтобы дать файлу права на выполнение. Перейдите, к примеру, в домашний каталог с помощью команды cd
и просто введите datetime.
Перейдите, к примеру, в домашний каталог cd
и просто введите datetime.
Использование переменных и входных данных
bash-скрипты — это гораздо больше, чем просто список команд, которые выполняются последовательно. Одна из приятных сторон скриптов заключается в том, что они могут работать с переменными и входными данными, чтобы сделать скрипт гибким. В этом разделе вы узнаете, как с ними работать.
Использование позиционных параметров
При запуске скрипта можно использовать аргументы. Аргумент — это всё, что вы помещаете за командой сценария. Аргументы могут быть использованы для того, чтобы сделать скрипт более гибким. Возьмём команду useradd lisa. В этом примере команда — это useradd, а её аргумент — lisa — указывает, что нужно сделать.
В результате выполнения такой команды должен быть создан пользователь с именем lisa.
В тексте сценария первый аргумент обозначается $1, второй аргумент — $2 и т. д. Листинг 1 показывает, как можно использовать аргументы. Попробуйте запустить этот код, указав в качестве параметров любые имена пользователей.
Под параметрами подразумевается ввод данных перед запуском скрипта. В данном случае в качестве параметров после имени скрипта argument я указал lisa, lori и bob:
В Листинге 2 представлены два новых элемента, которые относятся к аргументам:
Итак, пока есть аргументы, тело сценария выполняется.
Тело цикла for всегда начинается с do и закрывается done, а между этими двумя ключевыми словами перечисляются команды, которые необходимо выполнить. Таким образом, пример сценария будет использовать echo для отображения значения каждого аргумента и останавливаться, когда больше нет доступных аргументов.
Давайте попробуем воспользоваться скриптом из листинга 2 в этом примере:
Переменные
Переменная — это метка, которая используется для обозначения определённого места в памяти, которое содержит определённое значение. Переменные могут быть определены статически с помощью NAME=value или динамическим способом. Существует два решения для динамического определения переменной:
Листинг 3. Пример скрипта, использующего команду read
* — на самом деле тремя источник (прим. переводчика)
Обратите внимание, что при написании команды test с квадратными скобками важно использовать пробелы после открывающей скобки и перед закрывающей скобкой, без пробелов команда не будет работать.
Обратите внимание, что оператор then следует сразу за test. Это возможно, потому что используется точка с запятой (;). Точка с запятой является разделителем команд и может заменить новую строку в скрипте.
В операторе then выполняются две команды: команда echo, которая отображает сообщение на экране, и команда read.
Команда read останавливает сценарий, чтобы пользовательский ввод мог быть обработан и сохранен в переменной TEXT. Поэтому read TEXT помещает все введённые пользователем данные в переменную TEXT, которая будет использоваться позже в скрипте.
Следующая часть представлена оператором else. Команды после оператора else выполняются во всех других случаях, что в данном случае означает «иначе, если аргумент был предоставлен». Если это так, то определяется переменная TEXT и ей присваивается текущее значение $1.
Вы можете попрактиковаться на этом примере при работе с вводом.
Использование условий и циклов
Как вы уже видели, в скрипте могут использоваться условные операторы. Эти условные операторы выполняются только в том случае, если определённое условие выполняется.
В bash есть несколько условных операторов и циклов, которые часто используются.
if then else
Подробнее о test можно узнать в справочнике командой man test.
Основная конструкция if есть if… then… fi.
Она сравнивает одно условие, как показано в следующем примере:
В листинге 3 вы увидели, как можно оценить два условия, включая else в выражении. В листинге 4 показано, как можно оценить несколько условий от if до else. Это полезно, если нужно проверить много разных значений.
Обратите внимание, что в этом примере также используются несколько команд test.
Листинг 4. Пример с if then else
Вместо написания полных операторов if… then вы можете использовать логические операторы || а также &&. || является логическим «ИЛИ» и выполнит вторую часть оператора, только если первая часть не верна; && является логическим «И» и выполнит вторую часть оператора только в том случае, если первая часть верна.
Рассмотрим эти две строки:
В первом примере выполняется проверка, чтобы увидеть, пуст ли $1. Если эта проверка верна (что, в основном, означает, что команда завершается с кодом выхода 0), выполняется вторая команда.
Во втором примере команда ping используется для проверки доступности хоста.
В этом примере используется логическое «ИЛИ» для вывода текста «node is not available» в случае неудачной команды ping.
Вы обнаружите, что часто вместо условного оператора if будут использоваться && и ||. В упражнении ниже вы можете попрактиковаться в использовании условных операторов, используя либо if… then… else, либо && и ||.
Упражнение. Использование if… then… else
В этом упражнении вы поработаете над сценарием, который проверяет что является файлом, а что каталогом.
Цикл for
Цикл for представляет собой отличное решение для обработки диапазонов данных. В листинге 5 вы можете увидеть первый пример с for, где диапазон определяется и обрабатывается, пока в этом диапазоне есть необработанные значения.
Цикл for всегда начинается с ключевого слова for, за которым следует условие, которое необходимо проверить. Затем следует ключевое слово do, за которым следуют команды, которые должны быть выполнены, если условие истинно, завершается цикл с помощью ключевого слова done.
В примере, приведённом в листинге 5, вы можете увидеть, что условие представляет собой диапазон чисел в круглых скобках, назначенных переменной COUNTER.
Внутри ((… )) вычисляются арифметические выражения и возвращается их результат. Например, в простейшем случае, конструкция a=$(( 5 + 3 )) присвоит переменной «a» значение выражения «5 + 3», или 8. Кроме того, двойные круглые скобки позволяют работать с переменными в стиле языка C.
В листинге 6 вы можете увидеть один из моих любимых однострочников с for. Диапазон определяется на этот раз как последовательность чисел, начиная со 100 и доходя до 104.
Обратите внимание, как определяется диапазон: сначала вы указываете первое число, затем две точки и указываете последнее число в диапазоне. При этом с for i in для каждого из этих номеров присваивается переменная i. Каждое из этих чисел присваивается переменной i и затем выполняется команда ping, где опция -c 1 гарантирует, что отправляется только один запрос.
Результат выполнения команды ping не учитывается, поэтому её вывод перенаправляется в /dev/null. На основании состояния выхода команды ping выполняется часть выражения за &&. Таким образом, если хост доступен, отображается строка, указывающая, что он работает.
Понимание while и until
Примечание. Так и не понял, что делает этот скрипт. В моём случае используется CentOS 7 и по умолчанию там нет monitor, хотя в скрипте явно написано: Где-то пол часа гуглил для CetOS программу monitor, но так и не нашёл. И вообще не понятно каким тут боком monitor если используется ps aux. В любом случае так и не понял, что делает этот срипт. Большая просьба помочь решить этот вопрос, чтобы откорректировать текст и/или скрипт.
Сценарий в листинге 7 состоит из двух частей. Во-первых, есть цикл while. Во-вторых, есть всё, что нужно выполнить, когда цикл while больше не оценивается как true.
Ядром цикла while является команда ps, которая имеет значение $1.
Вывод команды ps aux перенаправляются в /dev/tty11. Это позволяет позже прочитать результаты из tty11, если это необходимо, но они не отображаются по умолчанию.
После операторов while следуют команды, которые необходимо выполнить, если проверяемое условие истинно. В данном случае это команда sleep 5, которая приостанавливает выполнение скрипта на 5 секунд.
Пока условие оператора while истинно, цикл продолжает выполняться. Если же условие ложно (что в данном случае означает, что процесс больше не доступен), то цикл останавливается и могут выполняться команды, следующие за ним.