Самоучитель по написанию скриптов Bash для начинающих. Часть 1
Выпускаем серию статей о том, как писать скрипты Bash. Подойдет начинающим!
Что такое Bash/Shell/Scripting
Bash — это интерпретатор командного языка. Он широко доступен в различных операционных системах и является командным интерпретатором по умолчанию в большинстве систем GNU/Linux. Название является акронимом для ‘Bourne-Again SHell’.
Shell — это макропроцессор, который позволяет выполнять команды в интерактивном или неинтерактивном режиме.
Скриптинг позволяет автоматически выполнять команды, которые в противном случае выполнялись бы интерактивно одна за другой.
Основы сценариев оболочки Bash
Не отчаивайтесь, если вы не поняли ни одного из приведенных выше определений. Это совершенно нормально, ведь именно поэтому вы читаете эту статью.
Если вы не знали, Bash Scripting является обязательным навыком для любой работы в Linux системного администрирования, даже если работодатель может не требовать этого в явном виде.
Скорее всего, в данный момент вы сидите за компьютером, открыли окно терминала и задаетесь вопросом: «Что же мне делать с этой штукой?».
Так вот, в окне терминала перед вами находится shell, а shell позволяет вам с помощью команд взаимодействовать с компьютером, следовательно, получать или хранить данные, обрабатывать информацию и выполнять различные другие простые или даже очень сложные задачи.
Попробуйте это прямо сейчас! Используйте клавиатуру и введите несколько команд, таких как date, cal, pwd или ls, после чего нажмите клавишу ENTER.
Вы только что сделали то, что с помощью команд и командной оболочки взаимодействовали с компьютером, чтобы получить текущую дату и время (date), просмотреть календарь (cal), проверить расположение текущего рабочего каталога (pwd) и получить список всех файлов и каталогов, расположенных в нем (ls).
*у нас в папке пока ничего нет, поэтому команда ls не дала вывода.
Что такое скриптинг (сценарии Bash)
Теперь представьте, что выполнение всех вышеперечисленных команд является вашей ежедневной задачей. Каждый день вы должны безошибочно выполнять все вышеперечисленные команды, а также сохранять наблюдаемую информацию. Вскоре это станет чрезвычайно утомительной задачей, обреченной на провал. Поэтому очевидная идея — придумать способ выполнения всех команд вместе. Именно здесь скриптинг становится вашим спасением.
Чтобы понять, что подразумевается под сценариями, используйте shell в сочетании с вашим любимым текстовым редактором, например vi, чтобы создать новый файл task.sh, содержащий все вышеперечисленные команды, каждую в отдельной строке. После этого сделайте новый файл исполняемым с помощью команды chmod с опцией +x. И наконец, запустите новый скрипт, добавив к его имени ./.
Как видите, с помощью сценариев можно автоматизировать любое взаимодействие с оболочкой. Более того, теперь можно автоматически выполнять наш новый сценарий task.sh ежедневно в любое заданное время с помощью планировщика заданий cron и сохранять вывод сценария в файл при каждом его выполнении. Однако это уже другая история, а пока давайте сосредоточимся на предстоящей задаче.
Что такое Bash
До сих пор мы рассматривали shell и сценарии. А что насчет Bash? Где находится bash? Как уже упоминалось, bash является интерпретатором по умолчанию во многих системах GNU/Linux, поэтому мы использовали его, даже не осознавая этого. Вот почему наш предыдущий сценарий оболочки работает даже без определения bash в качестве интерпретатора. Чтобы узнать, какой у вас интерпретатор по умолчанию, выполните команду echo $SHELL:
Существуют различные другие интерпретаторы оболочки, такие как Korn shell, C shell и другие. Поэтому хорошей практикой является явное определение интерпретатора оболочки, который будет использоваться для интерпретации содержимого скрипта.
Чтобы определить интерпретатор вашего скрипта как Bash, сначала найдите полный путь к его исполняемому двоичному файлу с помощью команды which, добавьте к нему префикс shebang #! и вставьте его в качестве первой строки вашего скрипта. Существуют и другие способы определения интерпретатора командной оболочки, но это — надежное начало.
С этого момента все наши сценарии будут включать определение интерпретатора оболочки #!/bin/bash.
Имена файлов и разрешения
Далее давайте кратко обсудим права доступа к файлам и имена файлов. Вы, наверное, уже заметили, что для выполнения сценария shell файл должен быть сделан исполняемым с помощью команды chmod +x FILENAME. По умолчанию все вновь созданные файлы не являются исполняемыми, независимо от суффикса расширения файла.
На самом деле, расширение файла в системах GNU/Linux не имеет никакого значения, кроме того, что при выполнении команды ls для перечисления всех файлов и каталогов сразу становится ясно, что файл с расширением .sh — это, скорее всего, сценарий оболочки, а файл с .jpg — сжатое с потерями изображение.
В системах GNU/Linux команда file может быть использована для определения типа файла. Как видно из приведенного ниже примера, расширение файла не имеет никакого значения, а интерпретатор оболочки, в данном случае, имеет больший вес.
Таким образом, имя shell-сценария 0_xyz вполне допустимо, но по возможности его следует избегать.
Выполнение скриптов Bash
Далее поговорим об альтернативном способе выполнения сценариев bash. В упрощенном виде сценарий bash — это не что иное, как текстовый файл, содержащий инструкции, которые должны быть выполнены в порядке сверху вниз. То, как интерпретируются инструкции, зависит от определенного shebang или способа выполнения скрипта. Рассмотрим следующий видеопример:
Другим способом выполнения сценариев bash является явный вызов интерпретатора bash, например, $ bash date.sh, что позволяет выполнить сценарий без необходимости делать сценарий оболочки исполняемым и без объявления shebang непосредственно в сценарии оболочки. При явном вызове исполняемого двоичного файла bash содержимое нашего файла date.sh загружается и интерпретируется как сценарий оболочки Bash.
Относительный и абсолютный путь
Наконец, прежде чем мы запрограммируем наш первый официальный сценарий оболочки bash, давайте кратко обсудим навигацию оболочки и разницу между относительным и абсолютным путем к файлу.
Наверное, лучшая аналогия для объяснения относительного и абсолютного пути к файлу — это представить файловую систему GNU/Linux как многоэтажное здание. Корневой каталог (входная дверь здания), обозначенный /, обеспечивает вход во всю файловую систему (здание), а значит, дает доступ ко всем каталогам (уровням/комнатам) и файлам (людям).
Чтобы перейти в комнату 1 на уровне 3, нам сначала нужно войти в главную дверь /, затем пройти на уровень 3 level3/ и оттуда войти в комнату 1. Следовательно, абсолютный путь к этой конкретной комнате в здании — /level3/room1. Отсюда, если мы хотим посетить комнату2 на уровне 3, нам сначала нужно покинуть наше текущее местоположение — комнату1, введя ../, а затем включить название комнаты room2. Мы взяли относительный путь к room2, который в данном случае будет ../room2. Мы уже находились на уровне 3, поэтому не было необходимости покидать все здание и идти по абсолютному пути через главный вход /level3/room2.
К счастью, в GNU/Linux есть простой инструмент компас, который поможет вам ориентироваться в файловой системе в виде команды pwd. Эта команда при выполнении всегда выводит ваше текущее местоположение. В следующем примере используются команды cd и pwd для навигации по файловой системе GNU/Linux с использованием абсолютных и относительных путей.
Выполните команду cd без аргументов, чтобы мгновенно перейти в домашний каталог пользователя из любого места. Выполните команду cd — для переключения между двумя последними посещенными местами. В каком каталоге вы оказались после выполнения команд cd ~ и cd .
Навигация по файловой системе GNU/Linux — это простая, но для многих очень запутанная тема. Ознакомьтесь с навигацией по файловой системе GNU/Linux, прежде чем переходить к следующим разделам этого учебника.
Hello World Bash Shell Скрипт
Теперь пришло время написать наш первый, самый простой сценарий оболочки bash. Целью этого сценария является не что иное, как вывод «Hello World» с помощью команды echo на вывод терминала. Используя любой текстовый редактор, создайте новый файл с именем hello-world.sh, содержащий следующий код:
После этого сделайте ваш скрипт исполняемым с помощью командыchmod и запустите его, используя относительный путь ./hello-world.sh:
$ chmod +x hello-world.sh
$ linuxconfig.org:~$ ./hello-world.sh
Hello World
$
Следующий видеопример предлагает альтернативный способ создания приведенного выше сценария hello-world.sh. В нем используется команда which для вывода полного пути к интерпретатору bash. Этот вывод одновременно перенаправляется с помощью знака перенаправления > и одновременно создается новый файл hello-world.sh.
What is the Bash file extension?
I have written a bash script in a text editor, what extension do I save my script as so it can run as a bash script? I’ve created a script that should in theory start an ssh server. I am wondering how to make the script execute once I click on it. I am running OS X 10.9.5.
Its usually .sh , but the extension isn’t required to exist at all. Linux is not Windows. The program that shall interpret your script is determined in its first line, that should be #!/bin/bash . It may even include parameters.
@anubhava How would i get my script to execute if i were just to double click on it and not actually type » bash myscript»
5 Answers 5
Disagreeing with the other answers, there’s a common convention to use a .sh extension for shell scripts — but it’s not a useful convention. It’s better not to use an extension at all. The advantage of being able tell that foo.sh is a shell script because of its name is minimal, and you pay for it with a loss of flexibility.
To make a bash script executable, it needs to have a shebang line at the top:
and use the chmod +x command so that the system recognizes it as an executable file. It then needs to be installed in one of the directories listed in your $PATH . If the script is called foo , you can then execute it from a shell prompt by typing foo . Or if it’s in the current directory (common for temporary scripts), you can type ./foo .
Neither the shell nor the operating system pays any attention to the extension part of the file name. It’s just part of the name. And by not giving it a special extension, you ensure that anyone (either a user or another script) that uses it doesn’t have to care how it was implemented, whether it’s a shell script (sh, bash, csh, or whatever), a Perl, Python, or Awk script, or a binary executable. The system is specifically designed so that either an interpreted script or a binary executable can be invoked without knowing or caring how it’s implemented.
UNIX-like systems started out with a purely textual command-line interface. GUIs like KDE and Gnome were added later. In a GUI desktop system, you can typically run a program (again, whether it’s a script or a binary executable) by, for example, double-clicking on an icon that refers to it. Typically this discards any output the program might print and doesn’t let you pass command-line arguments; it’s much less flexible than running it from a shell prompt. But for some programs (mostly GUI clients) it can be more convenient.
Shell scripting is best learned from the command line, not from a GUI.
(Some tools do pay attention to file extensions. For example, compilers typically use the extension to determine the language the code is written in: .c for C, .cpp for c++, etc. This convention doesn’t apply to executable files.)
Keep in mind that UNIX (and UNIX-like systems) are not Windows. MS Windows generally uses a file’s extension to determine how to open/execute it. Binary executables need to have a .exe extension. If you have a UNIX-like shell installed under Windows, you can configure Windows to recognize a .sh extension as a shell script, and use the shell to open it; Windows doesn’t have the #! convention.