Окружение и настройка оболочки

Предыдущие темы показали, как устроена командная строка: команда, опции, аргументы, файловая система, права, потоки ввода-вывода и конвейеры. Во всех примерах оболочка работала «как есть», с настройками по умолчанию. Однако каждая оболочка получает от своего родителя набор переменных, ищет программы в списке каталогов, читает собственные файлы настроек при запуске и хранит историю команд. Эти механизмы определяют, какая команда будет выполнена при вводе python, почему скрипт работает в терминале, но не работает из планировщика, и почему слово sort даёт разный порядок строк на разных компьютерах.

Тема рассматривает окружение оболочки как управляемую среду. Сначала различаются переменные оболочки и переменные окружения, объясняется, как окружение передаётся дочерним процессам. Затем разбирается переменная PATH и порядок поиска команд, в том числе своя программа в каталоге ~/bin. Третий раздел посвящён файлам запуска: в каком порядке и при каких условиях bash читает свои настройки, как работает команда source, зачем нужны алиасы. Четвёртый раздел описывает приглашение PS1, историю команд и локаль, которая влияет на сортировку. Пятый раздел знакомит с современными утилитами для интерактивной работы — fzf, rg, fd, bat, ncdu и tldr — и объясняет, почему им не место в скриптах. Завершает тему терминальный мультиплексор tmux: он позволяет сохранять сеанс работы при разрыве связи, что особенно важно при работе по SSH, о которой пойдёт речь в теме 11.

Переменные оболочки и переменные окружения

Переменная оболочки

Переменная оболочки (англ. shell variable) — это имя, которое хранит значение внутри текущей оболочки. Присваивание записывается без пробелов вокруг знака равенства, а значение, содержащее пробелы, берётся в кавычки:

X=1
echo "$X"

1

Имя переменной, как правило, пишется латинскими буквами, цифрами и знаком подчёркивания, а сама переменная видна только в том процессе, где создана. Эта область видимости — ключевое отличие от переменной окружения, и её удобно проверить небольшим опытом. Создадим переменную в текущей оболочке и запустим новую копию bash через -c, чтобы она вывела значение:

X=1
bash -c 'echo "X=[$X]"'

X=[]

Новая копия bash не получила X. Квадратные скобки в выводе добавлены здесь, чтобы показать пустую строку; они присутствуют в команде только внутри кавычек.

Экспорт и наследование окружения

Чтобы переменная стала доступна программам, которые запускает оболочка, её нужно экспортировать командой export. Экспортированная переменная попадает в окружение (англ. environment) — набор пар «имя — значение», который операционная система передаёт новому процессу при его создании ¹:

X=1
export X
bash -c 'echo "X=[$X]"'

X=[1]

Теперь дочерний процесс получил копию значения. Экспорт можно совместить с присваиванием: export X=1 делает то же самое в одну строку. Переменная, экспортированная один раз, остаётся экспортированной в текущей оболочке до её завершения или до команды unset.

Существует и третий способ передать значение одной команде — записать присваивание перед самой командой. Такое присваивание действует только на время её выполнения и не меняет переменную в текущей оболочке:

X=2 bash -c 'echo "X=[$X]"'
echo "после: X=[$X]"

X=[2]
после: X=[1]

Этот приём часто используется для одноразовых настроек, например LC_ALL=C sort file.txt, о котором пойдёт речь в разделе о локали.

Дочерний процесс не меняет окружение родителя

Окружение передаётся по одному направлению: от родителя к потомку. Дочерний процесс получает копию переменных, и любые его изменения остаются у него. Проверим это:

X=1
export X
bash -c 'export X=99; echo "внутри: $X"'
echo "в родителе: $X"

внутри: 99
в родителе: 1

Причина в модели процессов. Когда оболочка запускает программу, операционная система создаёт новый процесс и копирует в него окружение; у родителя есть своя копия, и ни одна из сторон не видит памяти другой. Из этого следует важное правило: программа, запущенная из оболочки, не может изменить её переменные. Поэтому, например, обычная программа не может сменить текущий каталог оболочки. Команда cd — встроенная (англ. builtin), то есть выполняется самой оболочкой, а не отдельным процессом, поэтому она и меняет каталог. Тот же принцип объясняет, почему скрипт, который выполнен как bash script.sh, не может задать переменную в текущей оболочке: чтобы это сделать, его нужно выполнить через source, о котором речь пойдёт ниже.

Отдельная проверка показывает, что окружение действительно собирается из экспортированных переменных и ничего более. Запуск с пустым окружением env -i оставляет только несколько переменных, которые оболочка создаёт сама:

env -i bash --norc -c 'env'

PWD=/home/student
SHLVL=0
_=/usr/bin/env

Здесь HOME, PATH, USER и LANG отсутствуют: их некому было передать. Значение PWD здесь заменено на домашний каталог пользователя, остальные строки выведены без изменений.

Просмотр переменных: env, printenv, export, declare

Для просмотра переменных используются несколько команд, которые отличаются по охвату. Команда env и команда printenv показывают окружение, то есть только экспортированные переменные. Команда export -p выводит экспортированные переменные в виде, пригодном для повторного ввода. Команда declare -p показывает переменную со всеми её атрибутами, включая то, экспортирована ли она. Сравним вывод для переменной X, экспортированной ранее:

X=1
export X
printenv X
declare -p X

1
declare -x X="1"

Флаг -x в выводе declare -p означает экспорт. Для переменной без экспорта флаг отсутствует, поэтому по выводу declare -p удобно проверять, попала ли переменная в окружение. Полный список переменных текущей оболочки выдаёт команда set, но её вывод содержит и функции, поэтому на практике удобнее сочетать её с grep.

Таблица сводит команды просмотра.

Все перечисленные команды, кроме set, описаны в справочных страницах ⁷. Выходной формат printenv и env совпадает: отличие лишь в том, что printenv без аргумента печатает окружение, а с аргументом — значение одной переменной.

Поиск команд и переменная PATH

Порядок поиска команды

Когда пользователь вводит имя команды, оболочка должна решить, что именно запустить. Ответ зависит от порядка поиска: сначала bash раскрывает алиасы (если они раскрываются в данном контексте), затем распознаёт ключевые слова оболочки (например, if), после них ищет функции, встроенные команды и, наконец, программы в каталогах из переменной PATH. Этот порядок совпадает с порядком строк в выводе type -a. Первый найденный вариант побеждает. Этот порядок позволяет переопределить внешнюю программу алиасом или функцией, но на практике он редко становится источником проблем. Гораздо чаще встречается с другим: программа есть, но оболочка её не находит.

Переменная PATH содержит список каталогов, разделённых двоеточием. Оболочка просматривает их слева направо и запускает первый файл с нужным именем, для которого у пользователя есть право выполнения. Посмотрим на список каталогов, разбив его построчно:

echo "$PATH" | tr ':' '\n' | head -n 4

/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin

Это первые четыре каталога PATH свежей установки Ubuntu, заданного в файле /etc/environment; дальше следуют /sbin, /bin, /usr/games, /usr/local/games и /snap/bin. Установщики программ и файлы запуска часто добавляют в начало списка свои каталоги, например ~/.local/bin.

Порядок важен: если две программы с одинаковым именем лежат в разных каталогах, побеждает программа из каталога, который встречается раньше. Именно поэтому системные программы, установленные администратором в /usr/local/bin, находятся раньше /usr/bin. Каталоги /usr/local описаны стандартом иерархии файловой системы ⁵ как место для программ, установленных локально, вне пакетного менеджера.

Пусть команда ls находится в каталоге /usr/bin. Выясним, какая программа будет запущена:

type ls
command -v ls

ls is /usr/bin/ls
/usr/bin/ls

Команда type сообщает, как будет интерпретировано имя: как встроенная команда, алиас, функция или внешний файл. Команда command -v печатает только путь или имя, что удобно в скриптах. Для встроенных команд результат иной:

type -a echo

echo is a shell builtin
echo is /usr/bin/echo
echo is /bin/echo

Здесь показаны все три варианта echo: встроенный в оболочку, и два внешних файла. Встроенный echo будет выполнен, потому что он найден раньше внешних программ. Внешние версии нужны, когда вызывается /usr/bin/echo напрямую или когда запускается другая оболочка.

Каталог ~/bin и собственная команда

Пользователь может создать собственную программу и вызывать её по имени, если её каталог есть в PATH. Традиционное место для личных программ — каталог ~/bin. Дистрибутивы Ubuntu добавляют его в PATH в файле ~/.profile автоматически, но только если каталог существует на момент входа в систему. Проверим на примере.

Создадим каталог для эксперимента и простой скрипт, который печатает строку:

mkdir -p /tmp/demo-bin
printf '#!/bin/bash\necho "hello from mycmd"\n' > /tmp/demo-bin/mycmd
chmod +x /tmp/demo-bin/mycmd
mycmd
echo "код возврата: $?"

bash: mycmd: command not found
код возврата: 127

Каталог /tmp/demo-bin не входит в PATH, поэтому оболочка не находит программу и возвращает код 127, который стандартно означает «команда не найдена». Добавим каталог в PATH на время одной команды:

PATH=/tmp/demo-bin:$PATH mycmd
echo "код возврата: $?"

hello from mycmd
код возврата: 0

Чтобы сохранить путь во всех будущих сеансах, каталог нужно добавить в файл запуска (раздел про файлы запуска ниже). Типичная строка выглядит так:

export PATH="$HOME/bin:$PATH"

Заметим порядок: новый каталог добавлен в начало. Так собственная программа с тем же именем, что и системная, будет иметь приоритет. Если поставить каталог в конец, системная программа найдётся первой. Оба варианта встречаются на практике, и выбор зависит от того, нужно ли переопределять системные команды. Главная ошибка здесь — писать PATH=$HOME/bin:PATH без знака доллара. Такая строка присваивает переменной буквальную строку /home/student/bin:PATH, после чего ни одна команда, которой нет в этом каталоге, не будет найдена. Эта ошибка включена в лабораторную работу.

Команды type, command и hash

Оболочка запоминает найденные пути в специальной таблице, чтобы не просматривать PATH при каждом вызове. Команда hash показывает эту таблицу, а команда hash -r её очищает. После того как программа установлена или перенесена, таблица может указывать на старый путь. Проверим:

hash -r
ls > /dev/null
hash

hits	command
   1	/usr/bin/ls

Столбец hits показывает число обращений к записи. Если программа переустановлена в другой каталог, достаточно выполнить hash -r или открыть новую оболочку. Команда type показывает, какой файл будет вызван при обычном поиске; при сомнениях в том, что оболочка вызывает именно эту программу, полезно сравнить вывод type с выводом hash.

Файлы запуска оболочки

Login и non-login, interactive и non-interactive

Поведение bash при запуске определяется двумя независимыми признаками. Первый — login или non-login. Login-оболочка (англ. login shell) — это та, с которой начинается сеанс пользователя: вход на консоль, по SSH, в WSL-дистрибутив при первом запуске. Вторая оболочка, запущенная из первой командой bash, — non-login. Признак login проверяется переменной $0 (имя начинается с дефиса) или опцией --login. Второй признак — interactive или non-interactive. Интерактивная оболочка получает команды с терминала, а неинтерактивная выполняет скрипт или команду из аргументов -c. Документация bash определяет оба признака в разделе INVOCATION ².

Различие важно, потому что каждый случай читает свой набор файлов. Пользователь, который открыл терминал в графическом окружении, получает обычно non-login interactive оболочку: это окно эмулятора терминала, которое запускает bash без входа в систему. Пользователь, который подключился по SSH, получает login interactive оболочку. Скрипт, запущенный из cron, получает non-login non-interactive оболочку. Все три случая различаются набором файлов, и именно поэтому настройка, сделанная в одном месте, может не работать в другом.

Порядок чтения файлов

Правила чтения документированы в справочном руководстве bash ². Для login-оболочки bash сначала читает системный файл /etc/profile, затем ищет в домашнем каталоге ~/.bash_profile, ~/.bash_login и ~/.profile и выполняет первый существующий и читаемый файл из этого списка. Остальные не читаются. При выходе из интерактивной login-оболочки выполняется ~/.bash_logout. Для interactive non-login оболочки bash читает /etc/bash.bashrc и ~/.bashrc. Схема порядка показана на рисунке.

Сравнение порядка чтения удобно провести опытом. Создадим домашний каталог во временном месте и в каждый файл запуска поместим команду echo, которая печатает имя файла:

T=$(mktemp -d)
for f in .profile .bashrc .bash_profile .bash_login .bash_logout; do
    echo "echo 'читается $f'" > "$T/$f"
done
touch "$T/.sudo_as_admin_successful"
HOME=$T bash -l -c 'true'

читается .bash_profile

Login-оболочка прочитала .bash_profile и не трогала .profile и .bash_login, поскольку первый файл из списка уже существует. Проверим остальные варианты, сохранив тот же домашний каталог:

HOME=$T bash -i </dev/null 2>/dev/null
echo "== login interactive"
HOME=$T bash -li </dev/null 2>/dev/null

читается .bashrc
== login interactive
читается .bash_profile
читается .bash_logout

Первая строка относится к interactive non-login оболочке: она прочитала .bashrc. Во второй части login-оболочка прочитала .bash_profile и при выходе выполнила .bash_logout. Файл .bashrc в этом случае не был прочитан, потому что .bash_profile его не подключает. Вопрос, почему обычно .bashrc всё-таки работает и в SSH-сеансе, решается файлом ~/.profile в Ubuntu. Посмотрим его содержимое в домашней директории стандартного пользователя:

grep -n 'bashrc' ~/.profile

13:    # include .bashrc if it exists
14:    if [ -f "$HOME/.bashrc" ]; then
15:	. "$HOME/.bashrc"

В Ubuntu ~/.profile подключает ~/.bashrc, поэтому при отсутствии ~/.bash_profile login-оболочка тоже получает настройки из .bashrc. Если создать собственный ~/.bash_profile, этот механизм перестанет работать автоматически: .profile больше не будет прочитан. Эта особенность — частая причина, по которой алиасы «пропадают» при входе по SSH.

Заметим также, что системный файл /etc/bash.bashrc читается каждой интерактивной оболочкой до ~/.bashrc. В Ubuntu в нём, например, печатается подсказка о команде sudo для пользователей группы sudo, пока не создан файл ~/.sudo_as_admin_successful. Поэтому в опыте выше этот файл создан заранее, чтобы подсказка не мешала выводу.

Команда source и повторная загрузка настроек

Файл запуска — обычный скрипт, но выполняется он особым образом. Обычный запуск bash file создаёт новый процесс, и переменные, которые в нём задаются, остаются там. Команда source file (в POSIX-записи — точка: . file) выполняет команды этого файла в текущей оболочке ⁴. Сравним два способа:

printf 'SRC_VAR=from_file\n' > /tmp/demo_src.sh
bash -c 'bash /tmp/demo_src.sh; echo "после bash: [${SRC_VAR-}]"'
bash -c 'source /tmp/demo_src.sh; echo "после source: [${SRC_VAR-}]"'

после bash: []
после source: [from_file]

Команда source используется после редактирования ~/.bashrc: вместо закрытия терминала достаточно выполнить source ~/.bashrc. Важно помнить, что повторная загрузка добавляет команды к уже существующему состоянию. Строка PATH="$HOME/bin:$PATH", выполненная дважды, даст каталог ~/bin в переменной PATH два раза. Для одноразовых проверок это безвредно, но в длинных файлах стоит следить за такими повторами.

Алиасы и функции в ~/.bashrc

Алиас (англ. alias) — короткое имя для команды с заранее заданными аргументами. Он объявляется командой alias и раскрывается оболочкой до разбора команды:

alias ll='ls -l'
alias

alias ll='ls -l'

Алиасы не раскрываются в неинтерактивной оболочке по умолчанию. Скрипт, в котором есть алиас, сообщит об ошибке, если алиас не включён явно:

printf 'alias ll="ls -l"\nll /tmp/words.txt\n' > /tmp/alias_demo.sh
bash /tmp/alias_demo.sh

/tmp/alias_demo.sh: line 2: ll: command not found

Для скриптов правильнее использовать функции, а алиасы оставить для интерактивной работы. Функция (англ. function) — именованный блок команд, который может принимать аргументы. Подробный синтаксис функций рассматривается в теме 14. Здесь достаточно одной строки, которая часто встречается в ~/.bashrc:

mkcd() { mkdir -p "$1" && cd "$1"; }
mkcd /tmp/demo-project
pwd

/tmp/demo-project

Здесь mkcd создаёт каталог и переходит в него. Функция работает, потому что переход cd выполняется внутри текущей оболочки; внешняя программа не смогла бы это сделать. Такие короткие функции в ~/.bashrc заменяют алиасы, которым нужны аргументы.

Приглашение, история и локаль

Приглашение PS1

Приглашение (англ. prompt) — строка, которую bash печатает перед вводом команды. Его текст хранится в переменной PS1 (primary prompt). В строке могут быть escape-последовательности, которые bash заменяет на значения: имя пользователя, каталог, время, код возврата. Полный перечень приведён в руководстве bash ². Основные из них собраны в таблице.

Код возврата последней команды в таблицу не вошёл: bash не имеет отдельной escape-последовательности для него. Вместо неё используется $?. Строка PS1 подвергается раскрытию параметров, поэтому $? в ней работает. Для проверки можно раскрыть строку вручную с помощью оператора @P, который появился в bash версии 4.4:

p='[$?] \u@\h:\W\$ '
false
echo "${p@P}"
true
echo "${p@P}"

[1] student@ubuntu:tmp$ 
[0] student@ubuntu:tmp$ 

Ровно так работает приглашение, которое настраивается в лабораторной работе: цифра в начале показывает код возврата предыдущей команды.

Цветовые последовательности (например, \e[1;32m) не занимают видимых позиций на экране, но bash считает их символами, если они не обрамлены \[ и \]. Ошибка выглядит так: длинная команда при редактировании переносится неправильно, а текст затирает начало строки. Поэтому каждая управляющая последовательность цвета должна стоять внутри \[ \].

История команд

История (англ. history) хранит команды, введённые в интерактивной оболочке, и позволяет повторять их. Команда history показывает нумерованный список, !! повторяет последнюю команду, а Ctrl+R ищет в истории по подстроке. Размер истории задаётся переменной HISTSIZE: это число команд, которое помнится в текущем сеансе, по умолчанию bash устанавливает значение 500 после чтения файлов запуска ². Размер файла истории задаётся переменной HISTFILESIZE, а сам файл по умолчанию — ~/.bash_history.

Переменная HISTCONTROL определяет, какие команды не попадают в историю. Её значения, перечисленные в руководстве bash, таковы: ignorespace — не записывать команды, начинающиеся с пробела; ignoredups — не записывать команду, совпадающую с предыдущей; ignoreboth — оба правила сразу; erasedups — удалять из истории все прежние совпадения. Значение, не входящее в этот список, игнорируется без предупреждения. Проверим на опыте. Опыт проводится с опцией --norc, чтобы файл ~/.bashrc не переопределил настройки:

printf 'echo one\necho one\n echo secret\necho two\nhistory\nexit\n' | HISTFILE=/tmp/h.txt HISTCONTROL=ignoreboth bash --norc -i 2>/dev/null | tail -4
cat /tmp/h.txt

two
    1  echo one
    2  echo two
    3  history
echo one
echo two
history
exit

Повтор echo one удалён правилом ignoredups, а команда с ведущим пробелом — правилом ignorespace. Строка echo secret не попала ни в историю, ни в файл. Команда echo two выполнена и записана, потому что отличается от предыдущей.

Поведение без HISTCONTROL иное:

printf 'echo one\necho one\n echo secret\nhistory\nexit\n' | HISTFILE=/tmp/h2.txt bash --norc -i 2>/dev/null | tail -4
cat /tmp/h2.txt

    1  echo one
    2  echo one
    3   echo secret
    4  history
echo one
echo one
 echo secret
history
exit

Здесь все команды сохранены, включая команду с пробелом в начале. Поэтому пароли и другие секреты лучше вводить с ведущим пробелом, если установлен ignorespace, либо не вводить в командной строке вовсе.

Переменная HISTSIZE ограничивает число записей. Пример с HISTSIZE=3:

printf 'echo a\necho b\necho c\necho d\nhistory\nexit\n' | HISTFILE=/tmp/h3.txt HISTSIZE=3 HISTFILESIZE=3 bash --norc -i 2>/dev/null | tail -3
cat /tmp/h3.txt

    3  echo c
    4  echo d
    5  history
echo d
history
exit

В истории осталось три последние записи, а в файле — тоже три строки. Нумерация продолжается и не сбрасывается, поэтому номер команды не равен числу записей.

Обычно эти переменные задаются в ~/.bashrc. Ubuntu по умолчанию задаёт HISTCONTROL=ignoreboth, HISTSIZE=1000 и HISTFILESIZE=2000. Значения, которые видит текущая интерактивная оболочка, можно проверить командой bash -ic:

bash -ic 'echo "HISTSIZE=$HISTSIZE HISTFILESIZE=$HISTFILESIZE HISTCONTROL=$HISTCONTROL"'

HISTSIZE=1000 HISTFILESIZE=2000 HISTCONTROL=ignoreboth

Этот вывод получен в интерактивной оболочке, которая прочитала ~/.bashrc. Без --norc значения, которые задаёт ~/.bashrc, перекрывают заданные в командной строке (в Ubuntu он задаёт все три переменные), поэтому при экспериментах с историей полезно помнить о --norc.

Локаль и сортировка

Локаль (англ. locale) — набор правил, который определяет язык сообщений, кодировку символов, формат дат и порядок сортировки. Текущая локаль задаётся переменными LANG и LC_*. Переменная LC_ALL, если задана, переопределяет все остальные. Посмотрим, какие локали доступны в системе:

echo "LANG=$LANG LC_ALL=[$LC_ALL]"
locale -a

LANG=C.UTF-8 LC_ALL=[]
C
C.utf8
POSIX

В этой среде установлены только три локали. Список на другом компьютере может быть иным: на Ubuntu с русским интерфейсом обычно есть ru_RU.utf8. Наличие локали проверяется по выводу locale -a.

Локаль влияет на порядок сортировки, и это наиболее заметное следствие для работы с текстом. Проверим на файле из восьми слов с кириллицей и латиницей:

LC_ALL=C sort /tmp/words.txt

Apple
zebra
Банан
Яблоко
абрикос
апельсин
жук
ёж

В локали C сортировка идёт по числовым значениям байтов: все заглавные латинские буквы идут раньше строчных, а кириллица — после латиницы, и буква ё оказывается последней. Порядок C.UTF-8 для этих слов совпадает с C: эта локаль сортирует по кодам символов. Порядок ru_RU иной, поскольку локаль учитывает правила алфавита. Её можно собрать в любом каталоге пользователя из исходных данных пакета locales, без прав root:

mkdir -p /tmp/locale-demo
localedef -i ru_RU -f UTF-8 /tmp/locale-demo/ru_RU.UTF-8
LOCPATH=/tmp/locale-demo LC_ALL=ru_RU.UTF-8 sort /tmp/words.txt

Apple
zebra
абрикос
апельсин
Банан
ёж
жук
Яблоко

Русские слова теперь упорядочены по алфавиту и не зависят от регистра. Латинские слова в этой локали оказались первыми; правила сравнения, заданные локалью, описаны в руководстве по sort ³.

Если локаль не установлена, bash и sort не прекращают работу, а используют C. Проверим:

LC_ALL=ru_RU.UTF-8 locale 2>&1 | head -n 2

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory

Опасность в том, что скрипт, который сортирует данные, будет давать разный порядок на компьютерах с разными локалями. Поэтому для данных, которые должны совпадать, в скриптах принято явно задавать LC_ALL=C.

Современные утилиты для интерактивной работы

Зачем нужны современные утилиты и где им место

Классические инструменты grep, find, cat, du и man, о которых шла речь в предыдущих темах, присутствуют в любой системе, а их поведение описано в руководствах ^{3 7}. Рядом с ними за последние годы появились программы, которые решают те же задачи удобнее для человека, сидящего за терминалом: быстрее ищут, по умолчанию пропускают ненужное, подсвечивают результат и умеют диалог. Рассмотрим шесть таких утилит обзорно: цель раздела — понимать, что они делают и как их подключить, а не изучать каждую полностью. Все они ставятся из репозитория Ubuntu одной командой (команда требует прав root, поэтому приведена как пример):

sudo apt install fzf ripgrep fd-find bat ncdu tldr

В лабораторной работе допускается установка без root: пакет скачивается командой apt-get download и распаковывается в личный каталог, как описано в задании.

Сразу сформулируем правило, ради которого этот раздел и помещён в тему об окружении. Эти программы предназначены для интерактивной работы и настраиваются в ~/.bashrc. В скриптах, в заданиях cron, в инструкциях для других людей и на чужих серверах опираются на grep, find, cat и du: они гарантированно есть, их поведение не меняется от версии к версии и не зависит от настроек пользователя. Скрипт, который вызывает rg или fd, перестанет работать на машине, где их не установили.

Нечёткий поиск: fzf

Программа fzf (англ. fuzzy finder, «нечёткий поисковик») читает список строк со стандартного ввода, показывает его в интерактивном окне и по мере набора сужает до строк, содержащих введённые символы в заданном порядке, но не обязательно подряд. Стрелки выбирают строку, Enter печатает её на стандартный вывод. Таким образом fzf — ещё один фильтр, пригодный для конвейера: ls | fzf, history | fzf. Ключ --filter (или -f) отключает окно и печатает совпадения сразу, упорядочив их по близости совпадения. Это позволяет показать принцип без интерактивного окна. Пусть в файле hist.txt записано несколько команд:

fzf --filter 'tar gz' < hist.txt
echo ---
fzf --filter 'rsy' < hist.txt

tar xzf backup.tar.gz
tar czf backup.tar.gz ~/docs
---
rsync -av src/ dst/

Запрос из двух слов (tar и gz) означает, что строка должна содержать оба; запрос rsy нашёл rsync, хотя это лишь начало слова. Порядок строк определяется оценкой совпадения: сначала те, где искомые символы стоят ближе друг к другу.

Главная польза fzf проявляется после подключения к оболочке: он заменяет встроенные сочетания клавиш. В Ubuntu пакет устанавливает готовый файл привязок, и подключается он одной строкой в ~/.bashrc, как сообщает документация пакета в /usr/share/doc/fzf/README.Debian. Условие -f защищает от ошибки, если пакета нет на этом компьютере:

if [ -f /usr/share/doc/fzf/examples/key-bindings.bash ]; then
    source /usr/share/doc/fzf/examples/key-bindings.bash
fi

После перезапуска оболочки (или source ~/.bashrc) сочетание Ctrl+R открывает не построчный поиск bash, а окно fzf со всей историей: вводится любой фрагмент команды, а выбранная строка попадает в командную строку для правки. Ctrl+T вставляет в командную строку путь к файлу, выбранный из дерева каталогов, Alt+C переходит в выбранный каталог. Проверить, что привязки установлены, можно командой bind -X, которая перечисляет сочетания клавиш, связанные с функциями оболочки:

source /usr/share/doc/fzf/examples/key-bindings.bash
bind -X

"\C-r": "__fzf_history__"
"\C-t": "fzf-file-widget"

Без подключения файла bind -X в этой оболочке ничего не выводит: Ctrl+R остаётся стандартным обратным поиском readline, о котором говорилось в разделе об истории. Привязки работают только в интерактивной оболочке, поэтому поместить их нужно в ~/.bashrc, а не в ~/.profile. В версиях fzf начиная с 0.48 подключение выполняется командой eval "$(fzf --bash)"; точную строку для установленной версии даёт man fzf. Окно выбора в тексте не воспроизводится, так как это интерактивный экран; его вид зависит от версии, а набор клавиш остаётся прежним.

Быстрый поиск по содержимому и по именам: rg и fd

Программа ripgrep вызывается командой rg. Она ищет регулярное выражение в файлах так же, как grep -r, но по умолчанию обходит каталог рекурсивно, учитывает файл .gitignore, пропускает скрытые файлы и каталоги и двоичные файлы, а на больших деревьях работает заметно быстрее. Разницу показывает небольшой проект с каталогом build, файлом журнала run.log (оба перечислены в .gitignore) и скрытым файлом .env; во всех файлах записана строка TODO:

grep -r 'TODO' . --exclude-dir=.git | sort
echo ---
rg 'TODO' . | sort

./.env:TODO secret
./build/out.txt:TODO generated
./docs/notes.md:TODO: write tests
./run.log:TODO in log
./src/main.py:TODO: fix parser
---
./docs/notes.md:TODO: write tests
./src/main.py:TODO: fix parser

Для человека, который ищет по исходному коду, второй результат удобнее: нет сгенерированных и служебных файлов. Но для задачи «найти везде, включая секреты и журналы» он неверен, и об этом нужно помнить: rg --hidden включает скрытые файлы, а rg --no-ignore отключает .gitignore. Имена опций близки к grep: -i игнорирует регистр, -n показывает номера строк, -c считает строки, -l выводит только имена файлов, -t py ограничивает поиск типом файлов. Есть и ловушка: команда rg шаблон без пути, когда стандартный ввод перенаправлен (в скрипте, фоновом задании или конвейере), читает не текущий каталог, а стандартный ввод и может «зависнуть» в ожидании данных. В скриптах путь указывают явно: rg шаблон ..

Аналог find называется fd. Он ищет по имени (по умолчанию как по регулярному выражению), так же пропускает игнорируемые и скрытые файлы и выводит результат без лишних опций:

fdfind .
echo ---
fdfind -H -I . -E .git

./docs
./docs/notes.md
./src
./src/main.py
---
./.env
./.gitignore
./build
./build/out.txt
./docs
./docs/notes.md
./run.log
./src
./src/main.py

Здесь -H включает скрытые файлы, -I отключает учёт .gitignore, -E .git исключает каталог .git. Полезные ключи: -e json — только файлы с расширением, -t f — только обычные файлы, -t d — только каталоги, -x команда — выполнить команду для каждого найденного файла.

Обратите внимание, что в примере вызвана команда fdfind, а не fd. Причина в конфликте имён. Имя fd в Debian и Ubuntu уже занято другим пакетом, поэтому пакет fd-find устанавливает программу как fdfind, а документация пакета (/usr/share/doc/fd-find/README.Debian) сообщает, что /usr/bin/fd принадлежит программе fdclone. Аналогичная история у bat: в Ubuntu она называется batcat. Привычное короткое имя возвращают алиасом или ссылкой. Ссылка в ~/bin удобнее алиаса, так как работает и в скриптах, и в других оболочках; каталог ~/bin и его место в PATH разобраны выше в этой теме:

mkdir -p ~/bin
ln -s "$(command -v fdfind)" ~/bin/fd
ln -s "$(command -v batcat)" ~/bin/bat
type fd
fd --version

fd is /home/student/bin/fd
fd 8.3.1

(Путь /home/student/bin/fd — пример вывода; в учебной проверке ссылка создавалась в другом каталоге.) Алиасный вариант записывается в ~/.bashrc строкой alias fd=fdfind; он действует только в интерактивной оболочке, и скрипт, написанный на таком имени, не заработает. Заметим, что до создания ссылки команда type fd сообщает fd: not found, потому что в каталогах из PATH программы с таким именем нет.

Просмотр, диск и подсказки: bat, ncdu, tldr

Программа bat (в Ubuntu — batcat) похожа на cat: выводит содержимое файла, но добавляет заголовок с именем файла, нумерацию строк, подсветку синтаксиса и при необходимости открывает длинный файл в постраничном просмотрщике. Когда её вывод направлен не на терминал, а в канал или файл, оформление отключается, и она ведёт себя как cat, поэтому конвейеры не ломаются. Опцией --decorations=always оформление можно включить принудительно:

batcat --decorations=always --color=never --style=header,grid,numbers --paging=never src/main.py docs/notes.md | cat

─────┬──────────────────────────────────────────────────────────────────────────
     │ File: src/main.py
─────┼──────────────────────────────────────────────────────────────────────────
   1 │ TODO: fix parser
─────┴──────────────────────────────────────────────────────────────────────────
─────┬──────────────────────────────────────────────────────────────────────────
     │ File: docs/notes.md
─────┼──────────────────────────────────────────────────────────────────────────
   1 │ TODO: write tests
─────┴──────────────────────────────────────────────────────────────────────────

Программа ncdu (англ. NCurses Disk Usage) отвечает на вопрос «куда делось место на диске». Команда du -sh показывает одно число для каталога; ncdu каталог строит интерактивный список подкаталогов, упорядоченный по размеру, по которому можно перемещаться стрелками, входить в каталоги и удалять файлы клавишей d. Опция -x не выходит за пределы одной файловой системы, чтобы не сканировать смонтированные диски. Интерактивный экран в тексте не воспроизводится; убедиться в работе можно и в неинтерактивном режиме: ncdu -o файл сохраняет результат сканирования в файл в формате JSON, то есть в том же формате, который разобран в теме 6 вместе с jq:

ncdu -o - data | head -n 3 | cut -c1-110
du -sh data

[1,1,{"progname":"ncdu","progver":"1.15.1","timestamp":1792342598},
[{"name":"/tmp/t0616/l6/data","asize":4096,"dsize":4096,"dev":2096,"ino":678366},
{"name":"access.jsonl","asize":5311316,"dsize":5312512,"ino":678583},
8.8M	data

(Значения timestamp, dev и ino и абсолютный путь зависят от машины.) Размеры в этой записи даны в байтах: asize — размер содержимого, dsize — место, занятое на диске блоками.

Наконец, tldr отвечает на вопрос «как вызвать команду в типовом случае». Справка man полна, но для редкой команды вроде tar приходится читать страницы, чтобы найти один пример. Проект tldr собирает короткие страницы, написанные сообществом, из нескольких типовых примеров. В Ubuntu 22.04 и 24.04 пакет tldr устанавливает клиент под именем tldr-hs (в других дистрибутивах команда может называться tldr; точное имя показывает dpkg -L tldr). При первом запуске клиент скачивает базу страниц (tldr-hs --update, потребуется доступ в сеть), после чего работает без сети:

tldr-hs tar | head -n 8

tar
Archiving utility.Often combined with a compression method, such as gzip or bzip2.More information: https://www.gnu.org/software/tar/manual/tar.html.

 - [c]reate an archive and write it to a [f]ile:
   tar cf {{path/to/target.tar}} {{path/to/file1 path/to/file2 ...}}

 - [c]reate a g[z]ipped archive and write it to a [f]ile:
   tar czf {{path/to/target.tar.gz}} {{path/to/file1 path/to/file2 ...}}

(В выводе убраны управляющие последовательности цвета; клиент tldr-hs склеил две первые строки описания, так что это его особенность, а не ошибка.) Фрагменты в двойных фигурных скобках — подстановочные места, которые нужно заменить своими значениями. tldr не заменяет man: он не даёт полного перечня опций и не объясняет, почему команда устроена так, как устроена. Но как быстрая «напоминалка» он удобен, а полную справку по ссылке в начале страницы или в man всегда можно открыть следом.

Подведём итог по всем шести утилитам. Они ускоряют интерактивную работу и подключаются к оболочке строками в ~/.bashrc и ссылками в ~/bin, то есть теми же механизмами, что разобраны в этой теме. Они не входят в стандартные наборы, поведение их по умолчанию (игнорирование файлов, оформление) отличается от классического, а имена в Ubuntu не совпадают с привычными. Поэтому всё, что должно работать у других людей и без личной настройки, пишется на классических grep, find, cat, du и man.

Мультиплексор tmux

Сессии, окна и панели

Терминальный мультиплексор (англ. terminal multiplexer) позволяет запустить в одном терминале несколько сеансов оболочки и отсоединиться от них, не завершая процессы. Один из наиболее распространённых — tmux. Его модель состоит из трёх уровней: сессия (англ. session) содержит окна (англ. window), окно делится на панели (англ. pane). Каждая панель — отдельная оболочка. Иерархия показана на рисунке.

Создадим сессию в фоновом режиме, добавим окно и разделим его на две панели:

tmux new-session -d -s demo -x 80 -y 24
tmux new-window -t demo -n second
tmux split-window -t demo:1 -h
tmux ls
tmux list-windows -t demo

demo: 2 windows (created Mon Oct 12 13:16:28 2026)
0: bash- (1 panes) [80x24] [layout b25d,80x24,0,0,0] @0
1: second* (2 panes) [80x24] [layout 020a,80x24,0,0{40x24,0,0,1,39x24,41,0,2}] @1 (active)

Здесь demo:1 означает окно с индексом 1 в сессии demo. Звёздочка рядом с second показывает текущее окно, а (2 panes) — число панелей. Список панелей выводится так:

tmux list-panes -t demo -F '#{pane_index} #{pane_current_command} #{pane_width}x#{pane_height}'

0 bash 40x24
1 bash 39x24

Фоновый режим -d нужен для скриптов и примеров. В интерактивной работе сессия создаётся без него, и терминал сразу оказывается внутри неё.

Основные клавиши

Все команды tmux, кроме запуска, вводятся после префикса: по умолчанию это Ctrl+B. Нажатие Ctrl+B, затем клавиши команды, передаёт команду tmux. Таблица содержит основные клавиши, которые описаны в справке tmux ⁶. Список всех привязок выводится командой tmux list-keys -N -T prefix, а справка по сочетаниям — клавишей ? после префикса.

Вывод tmux list-keys -N содержит те же привязки с краткими английскими описаниями. Таблица не полна, однако покрывает повседневные действия.

Отключение и подключение

Главная причина использовать tmux — возможность отсоединиться от сессии, не завершив процессы в ней. Если терминал закрыт или связь по SSH оборвалась, сессия продолжает работать на сервере. Чтобы вернуться, достаточно подключиться заново и выполнить tmux attach. Проверим отсоединение на опыте. Эксперимент требует псевдотерминала, поэтому подключение выполняется через программу на Python, которая имитирует клиента:

python3 -I - <<'EOF'
import os, pty, time, select
pid, fd = pty.fork()
if pid == 0:
    os.execvp("tmux", ["tmux", "attach", "-t", "demo"])
def drain(t):
    end = time.time() + t
    while time.time() < end:
        r, _, _ = select.select([fd], [], [], 0.1)
        if r:
            try: os.read(fd, 4096)
            except OSError: break
drain(1.0)
os.write(fd, b"\x02d")   # Ctrl+B, затем d: отсоединение
drain(1.0)
os.waitpid(pid, 0)
print("клиент отсоединён")
EOF
tmux ls

клиент отсоединён
demo: 2 windows (created Mon Oct 12 13:16:28 2026)

Клиент отсоединился, а сессия с двумя окнами осталась. Чтобы подключиться снова в обычном терминале, выполняется tmux attach -t demo. Если сессия одна, имя можно не указывать. Для завершения сессии служит tmux kill-session -t demo.

При работе по SSH сочетание tmux и отсоединения решает практическую задачу: длительная операция, например копирование большого каталога, продолжается на сервере даже после обрыва связи. Ниже в этом курсе, в теме 16, такие операции окажутся частью резервного копирования.

Итоги темы

Окружение оболочки состоит из переменных, которые делятся на переменные оболочки и переменные окружения. Переменная становится частью окружения после экспорта, и только экспортированные переменные получают дочерние процессы. Дочерний процесс работает с копией окружения, поэтому его изменения не возвращаются родителю. Это объясняет и поведение команды cd, которая выполняется самой оболочкой, и различие между обычным запуском файла и source. Переменная PATH задаёт порядок поиска программ; личный каталог ~/bin добавляется в неё через файл запуска, и порядок каталогов определяет, какая программа будет вызвана.

Файлы запуска различаются для login и non-login, interactive и non-interactive оболочек. Порядок их чтения определяет, где нужно задавать настройку: в ~/.bashrc для интерактивной работы, в ~/.profile или ~/.bash_profile для входа в систему. Приглашение PS1, история команд и локаль тоже задаются переменными, которые можно проверить и изменить. Локаль особенно важна при сортировке: результат скрипта может зависеть от неё, поэтому в скриптах принято задавать LC_ALL=C для данных, которые должны совпадать на разных компьютерах.

Современные утилиты fzf, rg, fd, bat, ncdu и tldr ускоряют интерактивную работу и подключаются теми же механизмами — строками в ~/.bashrc и ссылками в ~/bin, но в скриптах по-прежнему используются классические grep, find, cat и du. Терминальный мультиплексор tmux дополняет эти знания: он сохраняет работу при разрыве связи и позволяет держать несколько оболочек в одном окне. Эта возможность понадобится при работе по SSH в теме 11, где удалённый сеанс будет обычным способом администрирования учебного сервера, а затем в теме 16, где резервное копирование должно переживать обрыв связи. Тема 9 покажет, как системные службы запускаются без участия терминала, и это дополнит картину: пользовательская оболочка настраивается файлами запуска, а фоновые службы — юнит-файлами systemd.

Литература

1. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019. Открытая версия: https://linuxcommand.org/tlcl.php
2. Free Software Foundation. GNU Bash Reference Manual. — https://www.gnu.org/software/bash/manual/
3. Free Software Foundation. GNU Coreutils Manual. — https://www.gnu.org/software/coreutils/manual/
4. The Open Group. The Open Group Base Specifications Issue 7 (IEEE Std 1003.1-2017), Shell Command Language. — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
5. Linux Foundation. Filesystem Hierarchy Standard 3.0. — 2015. https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
6. tmux wiki. — https://github.com/tmux/tmux/wiki
7. The Linux man-pages project. — https://man7.org/linux/man-pages/

Дополнительные материалы

Вопросы для самопроверки

1. Чем переменная оболочки отличается от переменной окружения, и что делает команда export?
2. Почему дочерний процесс не может изменить переменную своего родителя? Ответ опишите через модель процессов.
3. Почему команда cd — встроенная, а не внешняя программа? Что изменилось бы, будь она внешней?
4. В каком порядке bash ищет команду: алиасы, ключевые слова, функции, встроенные команды, внешние программы? Как проверить этот порядок командой type -a?
5. Почему строка PATH=$HOME/bin:PATH ломает поиск команд, а PATH=$HOME/bin:$PATH работает?
6. Чем отличаются login-оболочка и interactive-оболочка? Приведите пример каждого вида.
7. Какой файл запуска читает login-оболочка, если существуют ~/.bash_profile и ~/.profile?
8. Почему в Ubuntu ~/.bashrc обычно читается и при входе по SSH, хотя формально login-оболочка его не читает?
9. Чем source файл отличается от bash файл с точки зрения переменных?
10. Почему алиас не работает в скрипте по умолчанию, а функция работает? Что нужно сделать, чтобы алиас раскрывался в скрипте?
11. Что выводит escape-последовательность \w в PS1, и почему код возврата получают через $??
12. Почему при HISTCONTROL=ignoreboth команда с ведущим пробелом не попадает в историю, и когда это полезно?
13. Почему сортировка строк в локали C отличается от ru_RU.UTF-8, и какой риск это создаёт для скриптов?
14. Что произойдёт с процессом в tmux, если клиент отсоединился? Какой процесс хранит сессию?
15. Зачем в скриптах, запускаемых из cron, задавать PATH и LC_ALL явно?
16. Чем fzf отличается от grep и как он подключается к Ctrl+R через ~/.bashrc?
17. Почему rg и fd могут не показывать файлы, которые находят grep -r и find?
18. Почему в Ubuntu fd называется fdfind, bat — batcat, и как вернуть короткие имена?
19. Почему в скриптах и на чужих серверах нужно опираться на grep и find, а не на современные утилиты?

Глоссарий темы

Шпаргалка

Переменные и окружение:

X=1                     # переменная оболочки
export X                # переменная окружения
X=2 команда             # значение только для одной команды
env -i bash --norc -c env   # пустое окружение
printenv X              # значение из окружения
declare -p X            # атрибуты, -x означает экспорт

Поиск команд:

echo "$PATH" | tr ':' '\n'    # список каталогов построчно
type имя                      # что будет вызвано
command -v имя                # путь или имя, удобно в скриптах
hash -r                       # очистить кэш путей
export PATH="$HOME/bin:$PATH" # добавить каталог в начало

Файлы запуска и алиасы:

source ~/.bashrc              # перечитать настройки в текущей оболочке
bash --norc -i               # интерактивная оболочка без ~/.bashrc
alias ll='ls -lh'             # алиас
shopt -s expand_aliases       # раскрывать алиасы в скрипте

Приглашение и история:

PS1='[$?] \u@\h:\w\$ '        # код возврата в приглашении
HISTCONTROL=ignoreboth        # без повторов и команд с пробелом
HISTSIZE=5000                 # размер истории в памяти
history                       # список команд

Локаль:

locale -a                                # установленные локали
LC_ALL=C sort файл               # порядок по байтам
LOCPATH=~/locale LC_ALL=ru_RU.UTF-8 sort файл   # локаль из домашнего каталога
localedef -i ru_RU -f UTF-8 ~/locale/ru_RU.UTF-8

Современные утилиты (только для интерактивной работы):

source /usr/share/doc/fzf/examples/key-bindings.bash   # Ctrl+R, Ctrl+T, Alt+C через fzf (в ~/.bashrc)
bind -X                                 # какие клавиши связаны с функциями
fzf --filter 'слово1 слово2' < файл     # нечёткий отбор без окна
rg -n шаблон .                          # поиск; --hidden, --no-ignore снимают пропуски
fdfind -e md                            # поиск по имени; -H скрытые, -I без .gitignore
ln -s "$(command -v fdfind)" ~/bin/fd   # вернуть короткое имя
batcat файл                             # cat с нумерацией и подсветкой
ncdu -x ~                               # интерактивный анализ занятого места
tldr-hs tar                             # короткие примеры (в Ubuntu 22.04 имя tldr-hs)

tmux:

Типичные ошибки

1. Симптом: bash: mycmd: command not found после создания программы в ~/bin. Причина: каталог не входит в PATH или файл запуска не был прочитан. Исправление: проверить echo "$PATH", добавить каталог в ~/.bashrc или ~/.profile, открыть новую оболочку или выполнить source.
2. Симптом: после правки PATH перестали работать обычные команды (ls, cat). Причина: строка вида PATH=$HOME/bin:PATH без знака доллара, которая присвоила буквальную строку. Исправление: PATH=$HOME/bin:$PATH; при уже испорченной сессии открыть новую.
3. Симптом: переменная, заданная в скрипте, пуста после его выполнения. Причина: скрипт запущен как отдельный процесс, а переменная задана в нём. Исправление: выполнять скрипт через source, если нужна переменная в текущей оболочке, или передавать результат через вывод.
4. Симптом: алиас ll работает в терминале, но не в скрипте. Причина: алиасы в неинтерактивной оболочке не раскрываются. Исправление: использовать функцию или включить shopt -s expand_aliases перед определением и использованием алиаса.
5. Симптом: изменения в ~/.bashrc не видны в новом сеансе по SSH. Причина: login-оболочка читает ~/.bash_profile или ~/.profile, а при наличии ~/.bash_profile файл ~/.profile не читается. Исправление: подключить ~/.bashrc из ~/.bash_profile или проверить порядок чтения скриптом startup-order.sh.
6. Симптом: в истории нет повторяющихся команд, и это кажется ошибкой. Причина: HISTCONTROL=ignoredups или ignoreboth. Исправление: это ожидаемое поведение; при необходимости задать HISTCONTROL= пустым значением.
7. Симптом: настройка HISTCONTROL или HISTSIZE не действует. Причина: опечатка в значении (bash игнорирует неизвестные значения без сообщения) или ~/.bashrc, который переопределяет значение позже. Исправление: проверить значение командой echo "$HISTCONTROL" и сверить с руководством bash.
8. Симптом: порядок строк в отчёте на одном компьютере отличается от другого. Причина: разные локали (C и ru_RU.UTF-8). Исправление: в скриптах, которые сравнивают данные, задавать LC_ALL=C явно.
9. Симптом: sort работает без ошибок, но порядок не такой, как ожидалось. Причина: указанная локаль не установлена, и sort использует C без предупреждения. Исправление: проверить наличие локали командой locale -a.
10. Симптом: bash: ...: command not found в задании cron, хотя та же команда работает в терминале. Причина: cron запускает скрипт с коротким PATH, заданным планировщиком. Исправление: указать полные пути к программам или задать PATH в начале скрипта.
11. Симптом: сессия tmux исчезла после обрыва связи. Причина: сессия была запущена в оболочке, которая завершилась вместе с SSH-клиентом, без tmux, либо сервер tmux был перезапущен. Исправление: запускать длительные задачи внутри tmux и проверять tmux ls после подключения.
12. Симптом: fd: command not found или bat: command not found после установки пакетов fd-find и bat. Причина: в Ubuntu программы называются fdfind и batcat из-за конфликта имён с другими пакетами. Исправление: ссылка ln -s "$(command -v fdfind)" ~/bin/fd или алиас в ~/.bashrc (алиас в скриптах не работает).
13. Симптом: rg не находит строку, которую находит grep -r. Причина: rg пропускает скрытые файлы, файлы из .gitignore и двоичные файлы. Исправление: rg --hidden --no-ignore, и помнить, что в скриптах нужен предсказуемый grep.
14. Симптом: rg шаблон без пути ничего не печатает и не завершается. Причина: стандартный ввод перенаправлен, и rg читает его вместо каталога. Исправление: указать путь явно: rg шаблон ..
15. Симптом: после добавления строки в ~/.bashrc Ctrl+R работает по-старому. Причина: файл привязок fzf не подключён, путь к нему другой или оболочка не перечитала файл. Исправление: проверить ls /usr/share/doc/fzf/examples/, выполнить source ~/.bashrc и посмотреть bind -X.

Что почитать и посмотреть

1. Free Software Foundation. GNU Bash Reference Manual. — https://www.gnu.org/software/bash/manual/ — разделы «Bash Startup Files», «Shell Variables», «Bash History Facilities» и «Controlling the Prompt» описывают поведение из теории подробно и с примерами.
2. Раздел INVOCATION в справке man bash (man bash, затем /INVOCATION) — краткое и точное описание порядка чтения файлов запуска, которое удобно держать под рукой.
3. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019. Открытая версия: https://linuxcommand.org/tlcl.php — главы о переменных оболочки, окружении и настройке bash написаны для читателя без опыта работы в терминале.
4. The Open Group. Shell Command Language. — https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html — стандарт, определяющий поведение оболочки, переменные и команду ., который на практике совпадает с source в bash.
5. Free Software Foundation. GNU Coreutils Manual, раздел о sort. — https://www.gnu.org/software/coreutils/manual/ — правила сравнения строк, опции -f, -n, -k и влияние локали.
6. tmux wiki. — https://github.com/tmux/tmux/wiki — официальная документация по сессиям, окнам, панелям и настройке клавиш.
7. Справочные страницы man7.org: man 1 tmux, man 1 localedef, man 7 environ — https://man7.org/linux/man-pages/ — environ(7) кратко описывает окружение процесса.
8. explainshell.com — вставьте в поле строку вида alias ll='ls -lh' или HISTCONTROL=ignoreboth и посмотрите разбор по частям; удобно для проверки чужих строк из ~/.bashrc.
9. OverTheWire Bandit (https://overthewire.org/wargames/bandit/) — учебная игра на командную строку; уровни тренируют работу с окружением и поиском файлов.
10. Страницы man fzf, man rg, man fdfind, man ncdu и репозиторий проекта tldr-pages (https://github.com/tldr-pages/tldr) — справка по опциям утилит из обзорного подраздела и каталог коротких примеров; читайте по мере необходимости.

Лабораторная работа 8. Настройка рабочего окружения

• Раздел курса: тема 8 «Окружение и настройка оболочки»

Введение

Теория темы 8 показала, что поведение оболочки определяется окружением: переменными, которые передаются дочерним процессам, каталогами из PATH, файлами запуска, историей и локалью. В этой работе каждое из этих утверждений проверяется на практике и настраивается собственное рабочее окружение: создаётся команда в ~/bin, в ~/.bashrc добавляются функция и приглашение с кодом возврата, выясняется порядок чтения файлов запуска и осваивается базовый сценарий tmux.

Работа состоит из основной (базовой) части (части 1–7) и продвинутой (углублённой, по желанию) части (части 8 и 9). Часть 9 знакомит с удобными утилитами для интерактивной работы.

Цель работы

Освоить настройку рабочего окружения оболочки bash: наследование переменных, поиск команд по PATH, файлы запуска, историю, локаль и терминальный мультиплексор tmux.

После выполнения работы получится:

• объяснить, какие переменные попадают в окружение дочернего процесса, и подтвердить это опытом с export и без него;
• добавить каталог в PATH, создать собственную команду в ~/bin и проверить её поиск командами type и command -v;
• написать в ~/.bashrc алиас, функцию и приглашение PS1, которое показывает код возврата предыдущей команды;
• установить, какие файлы запуска читаются для каждого вида оболочки, и объяснить порядок их чтения;
• объяснить, почему сортировка одних и тех же строк зависит от локали, и воспроизвести оба варианта порядка;
• создать сессию tmux, отсоединиться от неё и подключиться снова, не потеряв процессов;
• (продвинутая часть) подключить fzf к истории команд, вернуть короткое имя fd ссылкой в ~/bin и объяснить, почему скрипты не должны на эти утилиты опираться.

Теоретический минимум

Необходимый материал изложен в теории темы 8: разделы «Переменные оболочки и переменные окружения», «Поиск команд и переменная PATH», «Файлы запуска оболочки», «Приглашение, история и локаль», «Мультиплексор tmux» и для части 9 — «Современные утилиты для интерактивной работы».

Команды работы:

Разница между переменными оболочки и переменными окружения проверяется так: переменная без export не видна дочерней программе, а после export видна. Приглашение PS1 содержит escape-последовательности, перечисленные в таблице темы; код возврата в них не входит и выводится через $?.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с bash версии 5 и пакетом tmux.
• Пакет locales (по умолчанию установлен в Ubuntu; если нет — sudo apt install locales) и пакет tmux:

sudo apt install tmux locales

• Архив окружения lr-env: words.txt, bashrc-buggy.sh, startup-order.sh, README.md.

Порядок выполнения работы

Работа выполняется в обычной учётной записи, права root не требуются. Рабочий каталог — ~/lab-08/lr-env. Архив окружения распаковать и перейти в рабочий каталог:

unzip ~/Downloads/lr-env.zip -d ~/lab-08 && cd ~/lab-08/lr-env

До начала работы сделать копии своих файлов запуска, чтобы при ошибке можно было вернуть прежнее состояние:

cp ~/.bashrc ~/.bashrc.orig
cp ~/.profile ~/.profile.orig
cp ~/.bash_logout ~/.bash_logout.orig

В журнал работы по каждой части заносятся три вещи: предсказание (записывается до выполнения команды), команды с выводом и объяснение расхождения между предсказанием и результатом. Предсказание записывается отдельной строкой в формате «ожидаю: …». Если предсказание совпало с выводом, объяснение всё равно записывается: почему результат именно такой.

Часть 1. Переменные и наследование окружения

Задание

1. Предсказать, будет ли видна переменная GREETING в дочерней оболочке, если она задана без export. Записать ответ, затем выполнить:

GREETING=hello
bash -c 'echo "в дочерней: [$GREETING]"'

2. Выполнить то же после export GREETING. Сравнить результаты.

3. Проверить, что присваивание перед командой действует только на её время:

GREETING=hi bash -c 'echo "в дочерней: [$GREETING]"'
echo "в родителе: [$GREETING]"

4. Из дочернего процесса установить GREETING=changed и вывести значение в родителе. Объяснить результат, опираясь на модель процессов из теории.

5. Выполнить env -i bash --norc -c 'env' и перечислить переменные, которые остались. Объяснить, почему HOME и PATH отсутствуют.

6. Сравнить вывод printenv GREETING и declare -p GREETING для переменной до и после export. Найти признак экспорта в выводе declare -p.

Что должно получиться

В журнале работы: таблица «команда — предсказание — вывод — объяснение» для пунктов 1–5, а также вывод declare -p до и после экспорта с подписью, какой флаг означает экспорт.

Часть 2. Собственная команда в ~/bin

Задание

1. Проверить, существует ли каталог ~/bin и входит ли он в PATH:

ls -ld ~/bin
echo "$PATH" | tr ':' '\n' | grep -n bin

2. Если каталога нет, создать его: mkdir -p ~/bin. Затем создать скрипт hello-lab в этом каталоге, который печатает название работы, имя пользователя и текущую дату. Например, содержимое файла:

#!/bin/bash
echo "Лабораторная работа 8: настройка окружения, пользователь: $USER, дата: $(date +%F)"

Сделать файл исполняемым: chmod +x ~/bin/hello-lab.

3. Предсказать результат команд hello-lab и type hello-lab, если ~/bin входит в PATH. Выполнить их.

4. Открыть новую оболочку, не меняя файлы запуска, и выполнить hello-lab. Если команда не найдена, выяснить причину: какой файл запуска добавляет ~/bin в PATH и был ли прочитан этот файл при запуске.

5. Добавить ~/bin в PATH в ~/.bashrc (если каталога нет в PATH) одной строкой, включающей $PATH. Выполнить source ~/.bashrc и проверить command -v hello-lab.

6. Выяснить, с каким числом записей добавляется каталог при повторной загрузке ~/.bashrc: выполнить source ~/.bashrc дважды и посчитать вхождения ~/bin в PATH. Объяснить результат и предложить условие, которое предотвращает повтор.

Что должно получиться

В журнале работы: вывод command -v hello-lab и type hello-lab, строка, добавленная в ~/.bashrc, и объяснение пункта 4. Если при выполнении пункта 4 hello-lab сразу найден, объяснить, почему это произошло.

Часть 3. Найти и исправить ошибки в настройках

Файл bashrc-buggy.sh из архива содержит четыре ошибки. Его нельзя подключать к собственному ~/.bashrc: проверять каждую строку в подоболочке, чтобы не испортить текущую сессию.

Задание

1. Выполнить файл в подоболочке и вывести PATH, алиас ll и значение HISTCONTROL:

bash -c 'source ./bashrc-buggy.sh; echo "PATH=$PATH"; alias ll; echo "HISTCONTROL=[$HISTCONTROL]"'

2. Предсказать, что будет выведено для каждой строки файла до выполнения. Записать предсказания, затем выполнить строки по одной, в подоболочке, и сравнить.

3. Для каждой найденной ошибки определить симптом, причину и исправление. Особое внимание уделить ошибке с PATH: после неё в подоболочке не находится ни одна команда, которой нет в каталоге $HOME/bin. Выяснить это, выполнив bash -c 'source ./bashrc-buggy.sh; ls'.

4. Исправить файл: сохранить исправленную копию как bashrc-fixed.sh и повторить пункт 1 для неё. Проверить, что HISTCONTROL принимает одно из значений, описанных в теории; если значение неизвестно, bash его молча игнорирует.

5. Объяснить, почему в строке с PS1 цветовые последовательности заключены в \[ и \], а что будет, если их убрать. Для обоснования использовать раздел «Приглашение PS1» теории.

Что должно получиться

В журнале работы: таблица «строка — симптом — причина — исправление» для четырёх ошибок; вывод исправленного файла в подоболочке; текст исправленной строки PS1.

Часть 4. Порядок чтения файлов запуска

Задание

1. Предсказать, какие файлы будут прочитаны для каждого из четырёх вариантов запуска: bash -c, bash -i, bash -l -c, bash -li. Записать ответы в таблицу «вариант — ожидаемые файлы».

2. Выполнить скрипт сверки:

bash startup-order.sh

Скрипт создаёт временные каталоги HOME с файлами-маркерами и печатает прочитанные файлы для пяти сценариев. Сравнить результат с предсказанием.

3. Проверить, какой файл читается первым из трёх кандидатов для login-оболочки. Создать в своём домашнем каталоге ~/.bash_profile с одной строкой echo "читается .bash_profile", выполнить bash -l -c 'true' и записать вывод. Затем удалить ~/.bash_profile и повторить команду: теперь должен читаться ~/.profile. Предсказать результат каждого шага до выполнения.

4. Добавить в свои настоящие файлы запуска ~/.bashrc, ~/.profile и ~/.bash_logout первой строкой команду echo "читается <имя файла>". Копии, сделанные в начале работы, нужны только для отката. Затем выполнить bash -li (интерактивная login-оболочка), выйти командой exit и зафиксировать порядок вывода. Сравнить его с таблицей из пункта 1.

5. Удалить добавленные строки и вернуться к исходным файлам: cp ~/.bashrc.orig ~/.bashrc, cp ~/.profile.orig ~/.profile, cp ~/.bash_logout.orig ~/.bash_logout. Проверить, что файлы совпадают с копиями (cmp).

Что должно получиться

В журнале работы: таблица «вариант — предсказание — результат», вывод startup-order.sh и объяснение, почему ~/.bashrc читается в сценарии 5 и не читается в сценарии 4 предыдущих проверок. Указать также, какие файлы в пункте 4 удалены и восстановлены.

Часть 5. Настройка ~/.bashrc: алиас, функция, PS1 и история

Задание

1. Добавить в конец ~/.bashrc четыре настройки:

• алиас ll='ls -lh';
• функцию mkcd() { mkdir -p "$1" && cd "$1"; };
• приглашение с кодом возврата предыдущей команды, например:

PS1='[$?] \u@\h:\w\$ '

Квадратные скобки здесь — часть приглашения, а не синтаксис, и это сделано намеренно: они показывают код возврата. Цветовые последовательности, если они нужны, заключаются в \[ и \];

• настройку истории: HISTCONTROL=ignoreboth и HISTSIZE=5000.

2. Применить изменения командой source ~/.bashrc. Проверить каждую настройку по отдельности: type ll, type mkcd, echo "$HISTSIZE".

3. Предсказать приглашение после команды, которая завершилась ошибкой, например ls /несуществующий, и после true. Выполнить обе команды и сравнить приглашения. Если приглашение не меняется, объяснить причину: PS1 должен раскрываться при каждом показе приглашения, а значение $? меняется после каждой команды.

4. Создать каталог через функцию: mkcd ~/lab-08/проба && pwd. Предсказать результат до выполнения.

5. Проверить работу истории. Выполнить две одинаковые команды подряд, затем команду с пробелом в начале и посмотреть history. Объяснить, почему повтор и команда с пробелом не попали в список.

6. Убедиться, что приглашение без source в новом терминале совпадает с настроенным: открыть новую вкладку и сравнить.

Что должно получиться

В журнале работы: строки, добавленные в ~/.bashrc; вывод type ll и type mkcd; два приглашения (после ошибки и после true) с объяснением; вывод history с объяснением, какие команды отсутствуют и почему.

Часть 6. Локаль и сортировка

Задание

1. Выполнить locale -a и записать, какие локали установлены. Если ru_RU.utf8 в списке нет, собрать её в домашнем каталоге без прав root:

mkdir -p ~/locale
localedef -i ru_RU -f UTF-8 ~/locale/ru_RU.UTF-8

2. Предсказать порядок строк words.txt при сортировке в локалях C, C.UTF-8 и ru_RU.UTF-8. Записать предсказания.

3. Выполнить три сортировки:

LC_ALL=C sort words.txt
LC_ALL=C.UTF-8 sort words.txt
LOCPATH=~/locale LC_ALL=ru_RU.UTF-8 sort words.txt

4. Сравнить результаты с предсказаниями. Объяснить, почему C и C.UTF-8 дают одинаковый порядок для этих слов, а ru_RU — иной.

5. Выполнить LC_ALL=ru_RU.UTF-8 locale 2>&1 | head -n 2 без LOCPATH и объяснить вывод. Следует обратить внимание: sort в этом случае не выводит предупреждения и использует C, что опасно для скриптов. Сформулировать, почему скрипты, которые сортируют данные для сравнения, должны задавать LC_ALL=C явно.

6. Найти в man sort или в справке sort --help опцию, которая не зависит от регистра (-f), и сравнить её результат с обычной сортировкой в ru_RU.

Что должно получиться

В журнале работы: таблица «локаль — предсказание — результат»; объяснение различия C и ru_RU; вывод locale без LOCPATH и вывод опции -f.

Часть 7. tmux: отключение и подключение

Задание

1. Создать сессию с именем lab08:

tmux new-session -d -s lab08
tmux ls

2. Добавить второе окно и разделить его на две панели:

tmux new-window -t lab08 -n work
tmux split-window -t lab08:1 -h
tmux list-panes -t lab08:1

3. Запустить в левой панели окна work долгую команду, передав её в панель командой send-keys (сессия пока не подключена к терминалу):

tmux send-keys -t lab08:1.0 'for i in $(seq 1 600); do echo "тик $i $(date +%T)"; sleep 1; done > ~/lab-08/ticks.txt' Enter

Предсказать, продолжится ли она после отсоединения.

4. Подключиться к сессии в интерактивном терминале командой tmux attach -t lab08. Выполнить отсоединение клавишами Ctrl+B, затем d. Выполнить tmux ls и проверить, что сессия осталась.

5. Подключиться снова, перейти к окну work клавишами Ctrl+B, затем 1 (или n), и выполнить tail -n 3 ~/lab-08/ticks.txt в правой панели этого окна, чтобы убедиться, что процесс работал во время отсоединения.

6. Разделить панель по горизонтали клавишами Ctrl+B, затем ". Переключиться между панелями стрелками, посмотреть номер каждой панели клавишами Ctrl+B, затем q.

7. Завершить сессию: tmux kill-session -t lab08. Предсказать, будет ли остановлен процесс из пункта 3.

Что должно получиться

В журнале работы: вывод tmux ls до и после отсоединения; вывод tail из пункта 5; объяснение, почему процесс продолжал работать; ответ на вопрос пункта 7 с проверкой по tmux ls.

Часть 8. Продвинутая часть: BASH_ENV и чистое окружение

Задание

1. Создать файл ~/lab-08/env-hook.sh с одной строкой: echo "загружен BASH_ENV". Предсказать, будет ли этот текст выведен при запуске скрипта bash -c 'echo proverka' с переменной BASH_ENV=$HOME/lab-08/env-hook.sh в окружении. Выполнить и сравнить.

2. Выполнить ту же команду с env -u BASH_ENV и объяснить разницу. Описать, в какой ситуации переменная BASH_ENV полезна, а в какой становится источником ошибок (подсказка: скрипты в cron или при запуске из другого окружения).

3. Запустить скрипт с окружением, которое содержит только PATH и HOME: env -i PATH=/usr/bin:/bin HOME=$HOME bash -c 'echo "$LANG|$USER"'. Объяснить, почему переменные LANG и USER пусты.

4. Сравнить вывод LC_ALL=C sort words.txt и env -i PATH=/usr/bin:/bin bash -c 'sort words.txt'. Определить, какие переменные окружения влияют на порядок, и объяснить, почему скрипты из планировщика могут сортировать иначе, чем в терминале.

Что должно получиться

В журнале работы: вывод пунктов 1–4 с объяснением; короткий абзац о том, какие переменные окружения следует задавать явно в скриптах, запускаемых из планировщика.

Часть 9. Продвинутая часть: современные утилиты в интерактивной работе

Часть выполняется по желанию и опирается на раздел теории «Современные утилиты для интерактивной работы» (fzf, rg, fd, bat, ncdu и tldr).

Задание

1. Установите утилиты. Если есть права root, выполните sudo apt install fzf ripgrep fd-find bat ncdu tldr. Без root скачайте пакеты в отдельный каталог и распакуйте в личный, не затрагивая систему:

mkdir -p ~/lab-08/pkg/debs ~/lab-08/pkg/root && cd ~/lab-08/pkg/debs
apt-get download fzf ripgrep fd-find
for f in *.deb; do dpkg -x "$f" ~/lab-08/pkg/root; done
export PATH="$HOME/lab-08/pkg/root/usr/bin:$PATH"

Для bat и tldr при установке без root могут понадобиться дополнительные библиотеки; если запуск сообщает о недостающем .so, пропустите эти две программы и отметьте это в журнале. Проверьте fzf --version и rg --version. 2. Выясните, почему fd не найден: выполните type fd и type fdfind. Создайте ссылку ln -s "$(command -v fdfind)" ~/bin/fd (если пакет bat установлен, то же для batcat и имени bat), выполните type fd и сравните вывод с выводом до создания ссылки. Предскажите, найдётся ли fd в новой оболочке, если каталога ~/bin не было при входе в систему, и проверьте предсказание по разделу о ~/bin. 3. В каталоге ~/lab-08/lr-env выполните rg -c 'locale' . и grep -rc 'locale' .. Предскажите, чем различаются результаты. Затем создайте каталог ~/lab-08/demo, запишите в него файл .hidden.txt со строкой TODO и файл plain.txt с такой же строкой, выполните git init в каталоге, добавьте plain.txt в .gitignore и сравните вывод grep -r TODO ., rg TODO . и rg --hidden --no-ignore TODO .. Объясните каждое различие. 4. Подготовьте файл hist.txt из истории: history | cut -c8- > ~/lab-08/hist.txt. Выполните fzf --filter 'слово1 слово2' < ~/lab-08/hist.txt, подставив два слова из своих команд, и объясните, как упорядочены строки. Подключите привязки в ~/.bashrc блоком из теории (с проверкой существования файла), выполните source ~/.bashrc и убедитесь, что bind -X показывает __fzf_history__. Откройте Ctrl+R в обычном терминале и найдите команду из этой работы; опишите, чем это отличается от встроенного поиска. 5. Сформулируйте в журнале ответ: какие из установленных утилит допустимо вызывать в скрипте, который будет выполняться по расписанию на другом сервере, и почему. Перепишите команду rg -n TODO и fd -e md через grep и find.

Что должно получиться

В журнале работы: вывод пунктов 1–4 с предсказаниями и объяснениями, строки, добавленные в ~/.bashrc, вывод bind -X, ссылка в ~/bin с выводом type fd, ответ на вопрос п. 5 с переписанными командами.

Журнал работы

Для себя ведите записи в порядке «предсказание — команда — фактический вывод — объяснение расхождения». Выводы команд сохраняйте полностью, а не пересказывайте. В конце отметьте, что оказалось неожиданным и как вы это проверили.

Контрольные вопросы

1. Почему переменная, заданная без export, не видна дочерней программе, но видна встроенной команде echo?
2. Что выводит declare -p X для экспортированной переменной и какой флаг означает экспорт?
3. Почему строка PATH=$HOME/bin:PATH ломает поиск команд, и как это проявляется в подоболочке?
4. В каком порядке bash ищет команду: что побеждает, если имя совпадает с алиасом, функцией и внешней программой?
5. Почему source ~/.bashrc меняет переменную в текущей оболочке, а bash ~/.bashrc — нет?
6. Какой файл читает login-оболочка Ubuntu, если существуют ~/.bash_profile и ~/.profile, и почему ~/.bashrc в этом случае может не читаться?
7. Что показывает последовательность \u@\h:\w, и зачем код возврата получают через $?, а не через escape-последовательность?
8. Почему значение HISTCONTROL=ignoreboht не вызывает ошибки, и как обнаружить опечатку?
9. Почему LC_ALL=C даёт порядок, отличный от ru_RU.UTF-8, и какие риски это создаёт для скриптов?
10. Почему процесс tmux продолжает работать после отсоединения, и какая часть системы его хранит?
11. Какие действия из лабораторной работы потребовали бы root, и почему все они выполнялись без него?
12. Почему запуск скрипта из cron может давать другой результат, чем тот же скрипт в терминале, даже при одинаковом PATH?
13. Почему в Ubuntu команда называется fdfind, а не fd, и чем ссылка в ~/bin лучше алиаса?
14. Почему rg TODO . может не найти строку, которую находит grep -r TODO .?
15. Почему привязки fzf помещают в ~/.bashrc, а не в ~/.profile, и почему скрипты не должны вызывать rg, fd и bat?