Содержание статьи
.файлы
Помнится, как-то я прочитал статью, которая произвела на меня сильное впечатление. Речь там шла немного не о том, о чем поговорим сегодня мы, однако главная идея та же: большинство системных утилит используют стандартные пути для хранения своих конфигурационных файлов, поэтому совсем несложно создать персонализированную коллекцию настроек для разных программ и восстанавливать их от одного деплоя операционной системы к другому.
Эта концепция стара как мир и носит название «дотфайлы» — файлы, названия которых начинаются с точки, а так как большинство конфигов в никсах и правда начинаются с точки (чтобы стать скрытыми и не мозолить глаза юзеру в выводе ls), то все вполне логично.
Удобнее всего, на мой взгляд, организовать хранение дотфайлов в системе управления версиями (CVS), чтобы можно было клонировать репозиторий одним действием при настройке новой системы. Однако это накладывает определенные условия на то, что́ смогут содержать твои конфиги, так как нельзя забывать, что CVS — штука публичная.
Приватными репозиториями пользоваться бессмысленно — это убьет все преимущества такой организации дотфайлов: например, их не повытаскиваешь из скриптов по отдельности без токенов авторизации. Кто-то может использовать облака для более удобной синхронизации, чтобы избежать миллионов пушей по каждой мелочи. В любом случае это вопрос вкуса, и в этой статье я покажу один из способов, как можно хранить свои настройки на GitHub.
Итак, у меня есть два репозитория.
Первый — dotfiles-linux — конфигурационные файлы для приложений на Linux.
Второй — dotfiles-windows — конфигурационные файлы для приложений на Windows.
В первом репозитории две ветки: master и wsl. Ветка wsl отвечает за версии дотфайлов, которые я использую во втором репозитории для персонализации Windows Subsystem for Linux. Когда при настройке винды я заметил, что никсовые конфиги не получается юзать для WSL «в чистом виде», то решил вести отдельную ветку, которую позже включил в dotfiles-windows в качестве подмодуля.
Результат такой: когда я разворачиваю дотфайлы на новой системе с Windows, я должен выполнить изнутри WSL следующие команды.
~$ WIN_DOTFILES_DIR="$(wslpathcmd.exe /C "echo %USERPROFILE%" | tr -d "\r")/.dotfiles"Первым действием с помощью wslpath, который резолвит пути между хостовой ОС и WSL, я создаю переменную с именем директории, куда я клонирую репозиторий с моими дотфайлами для Windows. В моем случае директория будет называться /mnt/c/Users/snovvcrash/.dotfiles.
~$ git clone https://github.com/snovvcrash/dotfiles-windows "${WIN_DOTFILES_DIR}"Далее я выкачиваю dotfiles-windows по этому пути.
~$ ln -sv "${WIN_DOTFILES_DIR}/wsl" ~/.dotfilesПоследним действием я создаю символическую ссылку в файловой системе WSL. Она будет указывать на подмодуль /mnt/c/Users/snovvcrash/.dotfiles/wsl, который мы заберем с гита, как показано ниже.
/mnt/c/Users/snovvcrash/.dotfiles$ git submodule update --init --remote
/mnt/c/Users/snovvcrash/.dotfiles$ git submodule foreach "git checkout $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)"Здесь я инициализирую git-подмодуль для данного репозитория на основании настроек .gitmodules, а потом восстанавливаю стейт detached HEAD для всех подгрузившихся подмодулей, так как по дефолту они выкачиваются с отваленными головами.
Если интересно настроить такую же схему, как у меня, это можно сделать с помощью одной команды, которая добавит подмодуль wsl в твой репозиторий дотфайлов из существующего ремоута.
/mnt/c/Users/snovvcrash/.dotfiles$ git submodule add https://github.com/snovvcrash/dotfiles-linux wslРезультат такой же, как если бы я вручную изменил конфиг .gitmodules с помощью git config.
/mnt/c/Users/snovvcrash/.dotfiles$ git config -f .gitmodules submodule.wsl.branch wslПро концепцию хранения дотфайлов поговорили, а что же, собственно, можно в них хранить? Я остановлюсь только на нескольких тулзах, которыми постоянно пользуюсь в Linux: описание всего, что там лежит, может растянуться на долгие часы.
Zsh
С какого-то момента я перестал воспринимать Bash как шелл, в котором можно комфортно работать. Да, разумеется, если жизнь заставит (особенно если это реверс-коннект с машины-жертвы), можно юзать и обычный /bin/sh без автодополнения, истории и управляющих символов. Но даже реверс-шелл можно довести до ума, проапгрейдив его до PTY, чего уж говорить о дефолтной оболочке на своей машине. Поэтому я использую Zsh. Не писал о нем только ленивый, так что сразу перейдем к минимальному набору приятностей, нужных, чтобы удобно с ним существовать.
Oh My Zsh
В первую очередь это, конечно же, фреймворк Oh My Zsh, позволяющий играючи управлять дополнениями и плагинами Zsh. Маст-хэвом я считаю zsh-syntax-highlighting для подсветки синтаксиса команд в терминале и zsh-autosuggestions для предложения автозавершения команд на основе твоей истории. Установка сводится к выполнению трех простых действий, после которых нужно перелогиниться, чтобы изменения возымели эффект.
$ apt install zsh -y && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
$ git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
$ git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
$ sed -i 's/plugins=(git)/plugins=(git zsh-syntax-highlighting zsh-autosuggestions)/g' ~/.zshrcПродолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
