Что такое bash? [закрыт]
Закрыт. На этот вопрос невозможно дать объективный ответ. Ответы на него в данный момент не принимаются.
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.
Закрыт 6 лет назад .
Подскажите для понимания: можно ли сказать, что Bash — это просто расширение функционала Shell, как в случае PowerShell к cmd?
Отслеживать
67.3k 197 197 золотых знаков 74 74 серебряных знака 216 216 бронзовых знаков
задан 5 авг 2016 в 10:08
Kris Kolean Kris Kolean
13 2 2 бронзовых знака
2 — думаю нет. bash вроде бы более старый чем windows.
1 — странный вопрос.
5 авг 2016 в 10:14
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
unix shell (оболочка операционной системы unix) — это стандарт, являющийся частью набора стандартов posix.
программа bash — это одна из множества реализаций стандарта unix shell.
да, как и практически любая из реализаций практически любого стандарта, программа bash «умеет» значительно больше, чем описано в стандарте unix shell, но называть программу «расширением стандарта», естественно, неправильно.
Источник: ru.stackoverflow.com
Что такое оболочка Bash и почему она так важна для Linux
О болочке Bash уже более 30 лет, и она все еще пользуется успехом. Что она делает, откуда она взялась и почему она до сих пор остается самой распространенной оболочкой в системах Linux?
Что такое оболочка
Когда вы открываете окно терминала и вводите команды, что-то должно интерпретировать, что вы намеревались сделать, и запустить задачи, которые вы просили. Программное обеспечение, которое это делает, и есть оболочка. Оболочка — это интерпретатор команд. Он сканирует то, что вы набираете, и выбирает команды, имена каталогов, имена файлов и имена программ, чтобы понять, чего вы пытаетесь достичь.
Люди часто используют фразы «окна терминала», «командная строка» и «оболочка» как синонимы, но это три разные вещи. Окно терминала — это программное представление физического терминала телетайпа. Это дает вам соединение с компьютером. Чтобы делать что-нибудь полезное, вы должны иметь возможность вводить инструкции в командной строке. Командная строка предоставляется оболочкой, а окно терминала позволяет вам получить доступ к оболочке.
Оболочки также позволяют объединить набор команд в текстовый файл, называемый скриптом. Все команды в скрипте выполняются за вас каждый раз, когда вы запускаете скрипт. Скрипты обеспечивают эффективность, повторяемость и удобство.
Первой оболочкой Unix была оболочка Томпсона под названием sh. Она была написана Кеном Томпсоном, который, возможно, является самым ключевым членом отцов-основателей оригинальной Unix в Bell Labs. Оболочка Томпсона использовалась в качестве оболочки Unix по умолчанию вплоть до Unix 6 версии включительно. В 1979 году она была заменена оболочкой Bourne в версии Unix 7.
Оболочка Bourne
Оболочка Bourne, написанная Стивеном Борном, была обновленной заменой оболочки Томпсона. Она даже была запущена с использованием той же команды, что и оболочка Томпсона (sh) для обеспечения обратной совместимости с существующими скриптами. Обратная совместимость была важна, но были добавлены новые функции, которые мы используем до сих пор.
Оболочка Bourne была интерактивной оболочкой и языком скриптов. Она поддерживает выполнение задач переднего и заднего плана, а также элементарное управление заданиями. Были добавлены каналы и перенаправление, а также улучшена обработка циклов.
Оболочка теперь содержала несколько встроенных команд, а это означало, что ей не нужно было передавать все внешним утилитам, что делало ее более эффективной. Оболочка Bourne даже поддерживала способ автоматизировать отправку данных в команды.
Оболочка Bourne подняла планку и стала новым стандартом.
Появление Bash
В 1984 году, когда проект GNU объявил о своем намерении создать бесплатный клон Unix, написанный с нуля и с новой разрешающей лицензией, команде потребовалась оболочка. Когда выяснилось, что программист, который работал над оболочкой для проекта GNU не смог ничего предоставить, Брайану Фоксу было поручено написать клон оболочки Bourne.
Она была названа Bourne Again Shell, или Bash. Частично это было данью уважения Стивену Борну, а частично — игрой слов. После его выпуска в 1989 году Чет Рэми внес в Bash несколько исправлений ошибок. В конце концов он стал соавтором оболочки Bash. В настоящее время он по-прежнему поддерживает проект Bash.
Линус Торвальдс, создатель ядра Linux, сказал, что первыми двумя программами, которые он запускал на своем новом ядре в 1991 году, были Bash и gcc, компилятор GNU. Объединение утилит GNU с ядром Linux было взаимовыгодным. Операционной системе GNU требовалось ядро, а ядру Linux требовалось все остальное, что составляет клон Unix.
Поскольку Bash — это стандартная оболочка GNU, она стала стандартной оболочкой для всех дистрибутивов GNU/Linux. Теперь Linux поддерживает огромное количество людей по всему миру. Оболочка Bash тоже остается популярной.
Bash включает в себя и улучшает набор функций оболочки Bourne, но она также черпает вдохновение из других оболочек, таких как оболочка C (csh) и KornShell (ksh). Например, расширение тильды «~» до значения, содержащегося в переменной среды $HOME, пришла из оболочки C, а команда fc, которая вызывает редактор по умолчанию для команд в истории команд, пришла из KornShell.
Bash представил файлы конфигурации, такие как файлы «.bashrc» и «.bash_profile». Редактирование командной строки в Bash намного превзошло возможности предыдущих оболочек. Манипуляции с ранее выполненными командами в истории команд были улучшенной версией функции оболочки C. Массивы были улучшены за счет снятия ограничений на их размер.
Оболочка Bash стремится соответствовать стандарту POSIX P1003.2/ISO 9945.2 Shell и утилит.
Почему Bash по-прежнему важен
Bash не смог бы продержаться так долго — более 30 лет — в качестве оболочки Linux по умолчанию, если бы он не подходил для этой работы. Благодаря долгому сроку службы и огромной базе пользователей, Bash является очень стабильной. Доступно множество альтернативных оболочек, от старых оболочек, таких как оболочка C и KornShell, до более новых оболочек, таких как оболочка Z (zsh) и Friendly Interactive Shell (fish). Как оболочка Z, так и оболочка Fish имеют некоторые функции, которых нет в Bash, а также, возможно, лучшие способы достижения некоторых из тех же вещей, что есть у Bash. Так почему же Bash до сих пор остается доминирующей оболочкой?
Использование оболочки, которая совместима с POSIX, имеет значение для многих дистрибутивов Linux, но гораздо важнее совместимость с предыдущими выпусками. Внесение изменений, которые могут нарушить работу существующих скриптов, очевидно, не лучший шаг.
Будет ли когда-нибудь заменен Bash
То, что сейчас может показаться невероятным, на самом деле может случиться позже. Возможно, настанет день, когда Bash будет заменен в качестве оболочки Linux по умолчанию, независимо от того, будет это по-прежнему стандартная оболочка GNU или нет. Или, может быть, это будет Bash, но улучшенный далеко за пределы оболочки, которую мы используем сегодня. Но что бы ни пришло на смену сегодняшнему Bash, оно должно быть либо полностью (или почти) обратно совместимым, либо иметь столько преимуществ, что на недостатки можно было закрыть глаза.
Начиная с macOS версии 10.15, Apple отказалась от Bash и приняла оболочку Z в качестве оболочки по умолчанию. У Apple есть проблемы с Стандартной общественной лицензией GNU (GPL) v.3. К сожалению, это лицензия, которую использует Bash. Последней версией Bash, выпущенной под GPL v.2, была версия 3.2 2007 года. Текущая версия — 5.1. Apple отставала почти на полтора десятилетия.
Единственный способ, которым Apple могла включить обновленную оболочку без перехода на GPL v.3, — это вообще перейти на другую оболочку. Однако вы все равно можете вернуться к Bash в macOS, если хотите.
Существует огромная разница между рабочей станцией опытного пользователя и бизнес-сервером Linux, которым необходимо удаленно управлять через соединение SSH. Из почти 1,5 миллиона серверов Amazon EC2 более 93% работают под управлением Linux. Почти 75% веб-серверов работают под управлением Linux. Такие организации, как Red Hat, Amazon и Google, используют Linux внутри компании.
Трудно представить, какие преимущества могла бы предложить новая оболочка, которая оправдала бы такие глобальные изменения. Вот почему Bash занимает такое важное место.
Источник: guidepc.ru
Жизнь — это движение! А тестирование — это жизнь 🙂
И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls… (в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
Например, создадим скриптик, который создаст директорию и в ней файлик:
mkdir /home/test cd /home/test touch test.txt
Так, команды записали, осталось сохранить их в файлик.
Скрипты хранят в файлах с расширением .sh, поэтому назовем файл first_script.sh. Но есть нюанс — линуксу плевать на ваше расширение файла. Его может вообще не быть, и все равно скрипт останется скриптом. Почему? Потому что у любого скрипта в первой строке должен содержаться путь к интерпретатору. Например:
#!/bin/bash или #!/bin/sh
Весь файл целиком:
#!/bin/bash mkdir /home/test cd /home/test touch test.txt
И даже если у такого файла не будет расширения вовсе, его можно будет запустить как скрипт:
sh first_script # Проверяем директорию /home — там появилась папка test с файлом test.txt внутри.
Расширение .sh ставится для понимания человеком. Зашел в директорию:
— Ага, что тут у нас? Файлы sh, скрипты какие-то лежат.
Скрипты могут быть простые, а могут быть сложные. Вот, например, в одном проекте мы вначале вручную обновляли тестовые платформы. Для обновления надо:
- Остановить сервис.
- Переподложить war-файл с приложением (лежат они в директории /opt)
- Запустить сервис
Сервиса два, допустим это test и cloud. Так что шагов уже 6.
Когда обновлять вручную надоело, мы положили на все линукс машины простой скриптик:
#!/bin/bash service test stop cp test.war /opt/jboss-test/bin service test start service cloud stop cp cloud.war /opt/jboss-cloud/bin service cloud start
Собираешь приложение, подкладываешь к скриптику и запускаешь 1 команду вместо 6. Удобно! Это называется «автоматизация рутины» =)
Другой пример с того же проекта — мы делали серверное приложение. И во время установки приложения на сервере linux нужно выполнить пункты по настройке самой системы. Например, увеличить параметр max_map_count — сколько максимум памяти может использовать процесс.
Приложение в пике работы требует много памяти. Если не настроить параметр, то «тяжеловесная» задача просто упадет с ошибкой «Не хватает памяти». И если мы видим такую ошибку, то в первую очередь идем проверять настройки системы.
Вообще, если вы отдаете установку приложения на откуп «чужим» админам, лучше потом проверять — а всё ли настроено верно? Конечно, обычно на production (машина, с которой работают реальные пользователи) настраивают всё внимательно, это на тестовых стендах могут что-то пропустить. Но лучше перебдеть!
Мы написали скрипт по проверке настройки окружения (символ «#» в начале строки означает, что это комментарий):
#!/bin/sh # # check sysctl # if [ -f /proc/sys/vm/max_map_count ] [ $(cat /proc/sys/vm/max_map_count) -ge 16777216 ]; then echo «vm.max_map_count: ok» else echo «vm.max_map_count: failed» fi if [ -f /proc/sys/vm/overcommit_memory ] [ $(cat /proc/sys/vm/overcommit_memory) -eq 2 ]; then echo «vm.overcommit_memory: ok» else echo «vm.overcommit_memory: failed» fi if [ -f /proc/sys/vm/overcommit_ratio ] [ $(cat /proc/sys/vm/overcommit_ratio) -eq 100 ]; then echo «vm.overcommit_ratio: ok» else echo «vm.overcommit_ratio: failed» fi if [ -f /proc/sys/vm/swappiness ] [ $(cat /proc/sys/vm/swappiness) -le 10 ]; then echo «vm.swappiness: ok» else echo «vm.swappiness: failed» fi
В итоге админы настраивают окружение, а потом мы даем им скрипт, просим запустить его и прислать результаты. Я запустила скрипт на «голой» системе, где, разумеется, параметры настроены не были, и вот ответ:
Видим, что все проверки провалились, статус failed. Если и от админов приходит похожая картина, направляем их в документацию по настройке системы. Если к нам приходят с проблемой падения из-за нехватки памяти, снова просим выполнить скрипт. Так проще локализовать ошибку: это в приложении косяк, или окружение настроено плохо?
Просить других людей выполнить 10 команд не очень хорошо. Потому что часть команд может «потеряться» при выполнении — плохо скопировал, забыл выполнить проверку, которую дали сообщением позже. Гораздо проще сделать 1 скрипт и попросить выполнить именно его.
Когда надо писать скрипт?
- Когда надо выполнить больше 3 команд за раз — проще выполнить одну, запустить скрипт.
- Когда одну и ту же команду надо выполнять чаще 3 раз — лучше автоматизировать эту работу.
По сути своей, bash-скрипты — это та же автоматизация. А когда нужна автоматизация? Когда мы хотим избавиться от рутины, от постоянного выполнения одного и того же действия вручную. Повторяете одно и то же каждый день / неделю? Напишите скрипт.
Даже если он на 2-3 строчки будет, это правда удобнее. Поверьте, сама делала небольшие скрипты ?
См также по bash:
Основы BASH. Часть 1 (Хабр) — цикл статей о том, как писать скрипты
См также другие статьи из цикла «Что такое. »:
Источник: okiseleva.blogspot.com
Bash shell что это за программа
В проекте GNU (GNU’s Not Unix) предоставляются инструментальные средства для администрирования UNIX-подобных системы, которые являются свободным программным обеспечением и соответствуют стандартам UNIX.
Оболочка Bash является sh-совместимой командной оболочкой, в которую добавлены полезные возможности из оболочек Korn shell (ksh) и C shell (csh). Оболочка реализована в соответствие со стандартом «IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools». В нем предлагаются функциональные улучшения в сравнении с sh, причем как для программирования, так и использования в интерактивном режиме; в стандарт добавлен режим редактирования командной строки, неограниченный размер истории команд, управление заданиями, функции командной оболочки и алиасы, индексированные массивы неограниченного размера и целочисленная арифметика по любому основанию от двух до шестидесяти четырех. Bash может без модификации выполнять большинство скриптов sh.
Как и в других проектах GNU, инициатива с программой bash была запущена с тем, чтобы сохранить, защитить и расширить свободное использование, изучение, копирование, модифицирование и распространения программного обеспечения. Общеизвестно, что такие условия стимулируют творчество. То же самое касается и программы bash, имеющей массу дополнительных функций, которые не могут предложить другие командные оболочки.
Возможности, которые есть только в bash
Вызов оболочки
Кроме односимвольных параметров, указываемых в командной строке оболочки и которые можно сконфигурировать с помощью встроенной команды set, есть несколько многосимвольных параметров, которыми вы можете пользоваться. В этой и в следующей главах мы рассмотрим пару наиболее популярных параметров; полный список параметров можно найти в документации Bash, выберите Bash features → Invoking Bash (Возможности Bash → Вызов Bash).
Файлы, используемые при запуске bash
Эти файлы являются скриптами, которые считываются и исполняются bash, когда она запускается. В следующих разделах описываются различные способы запуска командной оболочки, и указываются файлы, которые при этом считываются.
Вызов в интерактивном режиме с регистрацией в системе, т.е. с использованием параметра ‘—login’
Интерактивный режим означает, что вы можете вводить команды. Командная оболочка работает, поскольку должен быть активирован скрипт. Командная оболочка с регистрацией означает, что вы сможете перейти в командную оболочку только после аутентификации в системе, как правило, после ввода имени пользователя и пароля.
Считываются следующие файлы:
- /etc/profile
- ~/.bash_profile , ~/.bash_login или ~/.profile: считывается первый из существующих файлов
- ~/.bash_logout при выходе их оболочки.
Сообщения об ошибках выводятся в случае, если конфигурационные файлы существуют, но не читаются. Если файл не существует, bash будет искать следующий файл.
Вызов интерактивной командной оболочки без регистрации в системе
Вход в командную оболочку без регистрации означает, что вам не требуется аутентификация в системе. Например, когда вы открываете терминальное окно, щелкнув для этого по иконке или выбрав пункт меню, т. е. запускаете оболочку shell, не требующую регистрации.
Считываются следующие файлы:
- ~/.bashrc
Обычно ссылка на этот файл указывается в файле ~/.bash_profile :
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
Дополнительную информацию об инструкции условного исполнения if смотрите в главе 7 «Инструкции условного исполнения».
Неинтерактивное обращение к оболочке
Все скрипты используются в командной оболочке в неинтерактивном режиме. Скрипты программируются для выполнения определенных задач и не могут выполнять другую работу, на которую они не запрограммированы.
Считываются следующие файлы:
- определяется переменной BASH_ENV
Для поиска этих файлов переменная PATH не используется, так что если вы хотите использовать эти файлы, следует задать полный путь и имя файла.
Вызов с помощью команды sh
Bash пытается вести себя как исторически известная программа Bourne sh, при этом также соблюдается соответствие стандарту POSIX.
Считываются следующие файлы:
- /etc/profile
- ~/.profile
При интерактивном вызове переменная ENV может указывать на дополнительную информацию, используемую при запуске оболочки
Режим POSIX
Этот режим можно включить либо с помощью встроенной команды set:
set -o posix
либо вызвать программу bash с параметром —posix . После этого bash будет работать как можно ближе к стандарту POSIX для командных оболочек. То же самое можно сделать с помощью установки переменной POSIXLY_CORRECT .
Считываются следующие файлы:
- определяются переменной ENV .
Дистанционный вызов
При вызове с помощью команды rshd считываются следующие файлы:
- ~/.bashrc
Помните об опасности использования таких команд, как rlogin, telnet, rsh and rcp. Они небезопасны сами по себе, поскольку передают по сети конфиденциальную информацию в незашифрованном виде. Если вам нужны средства дистанционного выполнения команд, передачи файлов и так далее, воспользуйтесь реализацией Secure Shell, которая обычно известна как SSH и доступна без всяких ограничений по ссылке http://www.openssh.org . Также есть клиентские программы для систем, отличных от UNIX; обратитесь на ваш локальный сервер с программным обеспечением.
Вызов в случае, когда UID не совпадает с EUID
В этом случае файлы настройки не читаются.
Интерактивные командные оболочки
Что такое интерактивная командная оболочка?
Интерактивная командная оболочка обычно читает данные из терминала пользователя и пишет данные в этот терминал: вход и выход подключены к терминалу. Bash запускается в интерактивном режиме, когда команда bash вызывается без аргументов, кроме случаев, когда параметром является строка, откуда осуществляется чтение, или когда командная оболочка вызывается с тем, чтобы читать данные из стандартного входного потока, в котором есть возможность устанавливать параметры позиционирования (смотрите главу 3 «Среда окружения Bash»).
Командная оболочка интерактивная?
Можно проверить, посмотрев содержимое специального параметра «-«, если оболочка shell интерактивная, то будет выдано следующее:
eddy:~> echo $- himBH
В неинтерактивных командных оболочках значение строки приглашения PS1 не установлено.
Свойства интерактивной командной оболочки
Особенности интерактивного режима:
- Bash считывает файлы запуска.
- По умолчанию включено управление выполнением заданий.
- Установлены значения для строк приглашения; для многострочных команд значение строки приглашения PS2 установлено равным «>». Это приглашение вы также увидите в случае, если команда не завершена, например, когда вы забыли указать кавычки или элементы структуры команды, которые не могут быть опущены, и т.д.
- По умолчанию команды считываются из командной строки с помощью функции readline.
- При получении символа EOF (End Of File — конец файла) bash интерпретирует параметр ignoreeof вместо немедленного завершения работы командной оболочки.
- По умолчанию включены история команд и расширенные возможности истории команд. Когда происходит выход из командной оболочки, история сохраняется в файле, на который указывает переменная HISTFILE . По умолчанию переменная HISTFILE указывает на файл ~/.bash_history .
- Включены расширенные возможности, позволяющие использовать алиасы.
- Если не используется команда trap, сигнал SIGTERM игнорируется.
- Если не используется команда trap, сигнал SIGINT перехватывается и обрабатывается. Следовательно, если, например, будут нажаты клавиши Ctrl+C, то это не приведет к выходу из вашей интерактивной командной оболочки.
- В параметре huponexit задается, что при посылке сигнала SIGHUP происходит прекращение выполнения всех заданий.
- При чтении команд происходит их выполнение.
- Bash периодически проверяет почту.
- Bash может быть настроен так, что когда встречается переменная с неопределенным значением, то происходит выход из оболочки. В интерактивном режиме такое действие отключено.
- Когда при выполнении встроенных команд оболочки возникают ошибки перенаправления, то это не приводит к выходу из командной оболочки.
- Когда в режиме POSIX встроенные команды возвращают коды ошибок, то это не приводит к выходу из командной оболочки. Список встроенных команд приводится в разделе «Встроенные команды командной оболочки».
- Проблемы с выполнением команды exec не приводят к выходу из командной оболочки.
- Синтаксические ошибки, обнаруженные парсером, не приводят к выходу из командной оболочки.
- По умолчанию включена простая проверка синтаксиса встроенной команды cd.
- Включен автоматический выход из командной оболочки, который происходит при превышении таймаута, указанного в переменной TMOUT .
- в разделе «Переменные»;
- в разделе «О параметрах bash»;
- дополнительную информацию о сигналах смотрите в главе 12 «Перехват сигналов»;
- в разделе «Расширенные возможности командной оболочки» обсуждаются различные дополнительные возможности, используемые при вводе команд.
Условные выражения
Условные выражения используются в составной команде [[ и во встроенных командах test и [.
Выражения могут быть унарными или бинарными. Унарные выражения часто используются для проверки состояния файла. Для того, чтобы выполнить операцию, вам нужен всего лишь один объект, например, файл.
Есть операторы, работающие со строками, а также операторы сравнения чисел; есть бинарные операторы, для которых для того, чтобы выполнить операцию, требуется два объекта. Если аргумент FILE одного из операторов имеет вид /dev/fd/N , то проверяется дескриптор файла N. Если аргумент FILE одного из операторов имеет вид /dev/stdin , /dev/stdout или /dev/stderr , то соответственно проверяется дескриптор файла 0, 1 или 2.
Условные выражения подробно рассматриваются в главе 7 «Условные инструкции».
Дополнительную информацию о дескрипторах файлов смотрите в разделе «Перенаправление и дескрипторы файлов».
Арифметические операции в командной оболочке
Оболочка shell позволяет с помощью расширений оболочки или с помощью встроенной функции let выполнять арифметические операции.
Действия осуществляются над целыми числами с фиксированной разрядной сеткой без проверки на переполнение, хотя деление на 0 отлавливается и помечается как ошибка. Операторы, их приоритет и ассоциативность точно такие же, как и в языке C, смотрите главу 3 «Среда окружения Bash».
Алиасы
Алиасы позволяют заменить строку одним словом и использовать его как начало простой команды. Командная оболочка поддерживает использование списка алиасов, которые можно включать и отключать с помощью команд alias и unalias.
Bash всегда читает, как минимум, одну полную входную строку перед тем, как выполнить любую из команд, находящуюся на этой строке. Алиасы раскрываются, когда команда читается, а не когда она исполняется. Поэтому определение алиаса, указанное на той же самой строке, где находится еще какая-нибудь команда, не вступит в силу до тех пор, пока не будет прочитана следующая строка. На команды, находящиеся в той же самой строке за определением алиаса, новый алиас действовать не будет.
Алиасы раскрываются, когда читается определение функции, а не тогда, когда функция выполняется, поскольку определение функции само является составной командой. В результате алиасы, определяемые внутри функции, будут недоступными до тех пор, пока функция не будет выполнена.
Мы подробнее рассмотрим алиасы в разделе «Алиасы».
Массивы
В bash предлагаются одномерные массивы переменных. В качестве массива может использоваться любая переменная; массив объявляется явно с помощью встроенной команды declare. Ограничений на размер массива нет, доступ к элементам массива и присваивание им значений не обязательно должны выполняться последовательно. Массивы начинаются с нулевого индекса. Смотрите главу 10 «Подробнее о переменных».
Стек директориев
Стек директориев — это список директориев, которые недавно посещались. По мере того, как посещаются директории, они добавляются в стек с помощью встроенной команды pushd, а с помощью встроенной команды popd директории удаляются из стека и заменяются другими.
Содержимое стека можно посмотреть с помощью команды dirs или проверив содержимое переменной DIRSTACK .
Более подробную информацию о работе этого механизма можно найти в документации bash.
Строка приглашения
Bash позволяет настроить строку приглашения (prompt) по своему вкусу. Смотрите раздел «Управление строкой приглашения» в документации bash.
Ограниченный доступ к командной оболочке
Когда вызов оболочки осуществляется с помощью команды rbash или с использованием параметров —restricted или -r , происходит следующее:
- Встроенная команда cd отключается.
- Невозможно задать или изменить значения переменных SHELL , PATH , ENV или BASH_ENV
- В именах команд нельзя использовать косую черту (слэш).
- С именами файлов, в которых есть слэш, не допускается использовать встроенную команду . (точка)
- Во встроенной команде hash в параметре -p не допускается использовать слэш.
- При запуске оболочки отключен импорт функций.
- При запуске оболочки игнорируется значение переменной SHELLOPTS .
- Отключено перенаправление результата работы с помощью операций >, >|, >> и >>.
- Отключена встроенная команда exec.
- Во встроенной команде enable отключены параметры -f и -d .
- Нельзя изменять значение переменной PATH с помощью встроенной команды command.
- Отключить ограничение доступа невозможно.
Когда обнаружена команда, которая должна выполнить скрипт, в командной оболочке, которая создается для выполнения этого скрипта, с помощью команды rbash отключаются все ограничения.
- в разделе «Переменные»
- в разделе «Дополнительные параметры Bash»
- в документации Info Bash → Basic Shell Features → Redirections (Информация о Bash → Основные возможности команлной оболочки → Перенаправления)
- redirection в разделе «Перенаправление и доскрипторы файлов»: дополнительные возможности.
| Предыдущий раздел: | Оглавление | Следующий раздел: |
| Обычно используемые командные оболочки | Исполнение команд |
Источник: rus-linux.net
Home
И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls… (в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
Например, создадим скриптик, который создаст директорию и в ней файлик:
mkdir /home/test cd /home/test touch test.txt
Так, команды записали, осталось сохранить их в файлик. Скрипты хранят в файлах с расширением .sh, поэтому назовем файл first_script.sh. Но есть нюанс — линуксу плевать на ваше расширение файла. Его может вообще не быть, и все равно скрипт останется скриптом. Почему?
Потому что у любого скрипта в первой строке должен содержаться путь к интерпретатору. Например:
#!/bin/bash или #!/bin/sh
Весь файл целиком:
#!/bin/bash mkdir /home/test cd /home/test touch test.txt
И даже если у такого файла не будет расширения вовсе, его можно будет запустить как скрипт:
sh first_script # Проверяем директорию /home — там появилась папка test с файлом test.txt внутри.
Расширение .sh ставится для понимания человеком. Зашел в директорию:
— Ага, что тут у нас? Файлы sh, скрипты какие-то лежат.
Скрипты могут быть простые, а могут быть сложные. Вот, например, в одном проекте мы вначале вручную обновляли тестовые платформы. Для обновления надо:
- Остановить сервис.
- Переподложить war-файл с приложением (лежат они в директории /opt)
- Запустить сервис
Сервиса два, допустим это test и cloud. Так что шагов уже 6.
Когда обновлять вручную надоело, мы положили на все линукс машины простой скриптик:
#!/bin/bash service test stop cp test.war /opt/jboss-test/bin service test start service cloud stop cp cloud.war /opt/jboss-cloud/bin service cloud start
Собираешь приложение, подкладываешь к скриптику и запускаешь 1 команду вместо 6. Удобно! Это называется «автоматизация рутины» =)
Другой пример с того же проекта — мы делали серверное приложение. И во время установки приложения на сервере linux нужно выполнить пункты по настройке самой системы. Например, увеличить параметр max_map_count — сколько максимум памяти может использовать процесс.
Приложение в пике работы требует много памяти. Если не настроить параметр, то «тяжеловесная» задача просто упадет с ошибкой «Не хватает памяти». И если мы видим такую ошибку, то в первую очередь идем проверять настройки системы.
Вообще, если вы отдаете установку приложения на откуп «чужим» админам, лучше потом проверять — а всё ли настроено верно? Конечно, обычно на production (машина, с которой работают реальные пользователи) настраивают всё внимательно, это на тестовых стендах могут что-то пропустить. Но лучше перебдеть!
Мы написали скрипт по проверке настройки окружения (символ «#» в начале строки означает, что это комментарий):
#!/bin/sh # # check sysctl # if [ -f /proc/sys/vm/max_map_count ] [ $(cat /proc/sys/vm/max_map_count) -ge 16777216 ]; then echo «vm.max_map_count: ok» else echo «vm.max_map_count: failed» fi if [ -f /proc/sys/vm/overcommit_memory ] [ $(cat /proc/sys/vm/overcommit_memory) -eq 2 ]; then echo «vm.overcommit_memory: ok» else echo «vm.overcommit_memory: failed» fi if [ -f /proc/sys/vm/overcommit_ratio ] [ $(cat /proc/sys/vm/overcommit_ratio) -eq 100 ]; then echo «vm.overcommit_ratio: ok» else echo «vm.overcommit_ratio: failed» fi if [ -f /proc/sys/vm/swappiness ] [ $(cat /proc/sys/vm/swappiness) -le 10 ]; then echo «vm.swappiness: ok» else echo «vm.swappiness: failed» fi
В итоге админы настраивают окружение, а потом мы даем им скрипт, просим запустить его и прислать результаты. Я запустила скрипт на «голой» системе, где, разумеется, параметры настроены не были, и вот ответ:
Видим, что все проверки провалились, статус failed. Если и от админов приходит похожая картина, направляем их в документацию по настройке системы. Если к нам приходят с проблемой падения из-за нехватки памяти, снова просим выполнить скрипт. Так проще локализовать ошибку: это в приложении косяк, или окружение настроено плохо?
Просить других людей выполнить 10 команд не очень хорошо. Потому что часть команд может «потеряться» при выполнении — плохо скопировал, забыл выполнить проверку, которую дали сообщением позже. Гораздо проще сделать 1 скрипт и попросить выполнить именно его.
Когда надо писать скрипт?
- Когда надо выполнить больше 3 команд за раз — проще выполнить одну, запустить скрипт.
- Когда одну и ту же команду надо выполнять чаще 3 раз — лучше автоматизировать эту работу.
По сути своей, bash-скрипты — это та же автоматизация. А когда нужна автоматизация? Когда мы хотим избавиться от рутины, от постоянного выполнения одного и того же действия вручную. Повторяете одно и то же каждый день / неделю? Напишите скрипт.
Даже если он на 2-3 строчки будет, это правда удобнее. Поверьте, сама делала небольшие скрипты =)
См также по bash:
Основы BASH. Часть 1 (Хабр) — цикл статей о том, как писать скрипты
См также другие статьи из цикла «Что такое. »:
Источник: www.software-testing.ru