Перейти до вмісту

Модуль 7.1: Основи Bash

Hands-On Lab Available
Ubuntu intermediate 35 min
Launch Lab ↗

Opens in Killercoda in a new tab

Shell Scripting | Складність: [MEDIUM] | Час: 30–35 хв

Перед початком цього модуля:

  • Обов’язково: Модуль 1.1: Архітектура ядра (для розуміння команд).
  • Обов’язково: Базовий досвід роботи в командному рядку.
  • Бажано: Будь-який досвід програмування.

Що ви зможете робити після цього модуля

Розділ «Що ви зможете робити після цього модуля»

Після завершення цього модуля ви зможете:

  • Написати bash-скрипти зі змінними, умовами, циклами та функціями
  • Обробляти помилки безпечно за допомогою set -euo pipefail та trap
  • Обробляти аргументи командного рядка та валідувати вхідні дані у скриптах
  • Дебажити скрипти, що не працюють, за допомогою set -x, shellcheck та систематичного тестування

Чому цей модуль важливий

Розділ «Чому цей модуль важливий»

Скрипти на Bash — це клей, що тримає весь DevOps. Кожне операційне завдання — деплоймент, бекап, перевірка здоров’я систем, аналіз логів — може бути автоматизоване. Bash доступний на будь-якому Linux-сервері, він не потребує встановлення додаткових інтерпретаторів.

Розуміння Bash допоможе вам:

  • Автоматизувати рутину — перестаньте робити одне і те саме руками.
  • З’єднувати команди — будуйте потужні пайплайни обробки даних.
  • Писати портативні рішення — ваш код працюватиме всюди, де є Linux.
  • Працювати швидше на іспитах — CKA/CKAD дозволяють і заохочують використання скриптів.

Bash — це мінімально необхідна навичка автоматизації для інженера.


  • Bash уже понад 35 років — він з’явився у 1989 році як вільна заміна для Bourne shell. І досі залишається стандартом у більшості дистрибутивів.

  • POSIX-сумісність має значення — скрипти з #!/bin/sh більш портативні, але не можуть використовувати специфічні фішки Bash (наприклад, масиви). Alpine Linux використовує ash, а не bash.

  • Коди виходу — це все — кожна команда повертає 0 при успіху і не-0 при помилці. Хороші скрипти завжди перевіряють ці коди.

  • Лапки — причина №1 усіх багів — змінні з пробілами без лапок “ламають” логіку. Завжди пишіть "$var", а не $var.


#!/bin/bash
# Це коментар
echo "Привіт, Світе!"
# Створення та запуск
cat > hello.sh << 'EOF'
#!/bin/bash
echo "Привіт, Світе!"
EOF
chmod +x hello.sh
./hello.sh
# Привіт, Світе!
#!/bin/bash # Використовувати саме Bash
#!/bin/sh # Використовувати системну оболонку (більш портативно)
#!/usr/bin/env bash # Знайти bash у PATH (найбільш портативно)
# Shebang має бути ПЕРШИМ рядком, без пробілів перед #!

ЗміннаЩо містить
$0Назва самого скрипта
$1, $2...Аргументи командного рядка
$#Кількість переданих аргументів
$@Усі аргументи як окремі рядки
$?Код виходу останньої команди (0 = OK)
$$PID поточного процесу

Terminal window
# Базовий if
if [ "$name" = "admin" ]; then
echo "Привіт, адміне"
fi
# Рекомендовано в Bash використовувати [[ ]] — це безпечніше
if [[ "$count" -gt 10 ]]; then
echo "Більше десяти"
fi

Оператори перевірки файлів

Розділ «Оператори перевірки файлів»
  • -f "$file" — чи це звичайний файл.
  • -d "$dir" — чи це директорія.
  • -e "$file" — чи файл взагалі існує.
  • -s "$file" — чи файл не порожній.

Terminal window
# Цикл for по списку
for pod in $(kubectl get pods -o name); do
echo "Працюємо з: $pod"
done
# Цикл while (читання файлу)
while read -r line; do
echo "Рядок: $line"
done < data.txt

Terminal window
# Опис
log_info() {
echo "[INFO] $(date): $1"
}
# Виклик
log_info "Скрипт запущено"

Завжди починайте серйозні скрипти з цих магічних рядків:

#!/bin/bash
set -e # Вийти негайно при помилці будь-якої команди
set -u # Вийти при використанні невизначеної змінної
set -o pipefail # Враховувати помилки в ланцюжках команд (pipes)
# Або коротко:
set -euo pipefail

  1. Яка різниця між var=val та export var=val?

    Відповідь Просте присвоєння робить змінну доступною тільки в поточному скрипті. `export` передає змінну всім дочірнім процесам (іншим командам та скриптам, що запускаються з цього).
  2. Що означає код виходу 0?

    Відповідь Успішне завершення команди. Будь-яке інше число (від 1 до 255) означає помилку.
  3. Як отримати результат виконання команди у змінну?

    Відповідь Використовуючи синтаксис `$(команда)`. Наприклад: `files=$(ls | wc -l)`.
  4. Навіщо використовувати local всередині функцій?

    Відповідь Щоб змінна була доступна тільки всередині цієї функції й не перезаписала випадково однойменну змінну в основній частині скрипта (ізоляція області видимості).

Завдання: Написати скрипт для перевірки наявності файлів.

  1. Створіть файл check.sh:
#!/bin/bash
set -euo pipefail
FILE=${1:-""}
if [[ -z "$FILE" ]]; then
echo "Використання: $0 <назва_файлу>"
exit 1
fi
if [[ -f "$FILE" ]]; then
echo "Файл $FILE існує."
else
echo "Файл $FILE НЕ знайдено."
exit 1
fi
  1. Зробіть його виконуваним: chmod +x check.sh.
  2. Перевірте роботу: ./check.sh /etc/passwd.

Критерії успіху: Скрипт коректно обробляє наявність файлу та відсутність аргументу.


  • Bash — універсальна мова автоматизації Linux.
  • Shebang каже системі, чим запускати файл.
  • set -euo pipefail — золотий стандарт надійності.
  • Лапки навколо змінних — ваш захист від багів.

Далі: Модуль 7.2: Обробка тексту — навчіться майстерно володіти grep, sed та awk для трансформації даних.