Вступ до Dotfiles: як взяти під контроль своє середовище розробки

Примітка: Це дуже проста, вступна стаття. Якщо ви вже знаєте основи управління dotfile, я рекомендую вам прочитати мою другу статтю.

Як розробники, ми прагнемо мінімізувати час, який ми витрачаємо на зайві речі, такі як налаштування нашого середовища, написання зразкового коду, і в основному не робимо нічого, що не стосується найцікавішої частини кодування - створення нових матеріалів.

У цьому контексті уявіть ідеальний світ, де крихітні команди виконують неймовірно складні завдання з урахуванням ваших потреб, де ви можете придбати новий ноутбук сьогодні та встановити всі необхідні інструменти та пакети та налаштувати середовище розробки лише за допомогою декількох терміналів команди, і де все - магія.

Цю цифрову казкову країну можна зробити з легкістю. І є назва для цієї магії: файли крапок.

Без зайвих сумнівів, давайте розгадаємо секрети точкових файлів!

Вступ

Примітка: Ця стаття передбачає, що ви працюєте з Unix-подібною операційною системою, і вона значною мірою покладається на команди терміналу Unix та сценарії оболонки. Якщо ви з ними не знайомі, рекомендую вивчити основи та повернутися сюди. Ось буквар для сценаріїв оболонки.

У UNIX-подібних системах багато файлів конфігурації тощо подібні перед крапкою (.). Ці файли за замовчуванням приховані ОС, і навіть lsкоманда не виявляє їх присутності (ми трохи дізнаємося, як знайти ці файли). Оскільки цим файлам передує крапка, вони називаються dotfiles. Дух.

То як ми можемо знайти ці легендарні файли, якщо вони приховані за замовчуванням? Відкрийте термінал і зробіть наступне:

Примітка: Знак “$” не призначений для введення в терміналі. Він представляє той факт, що текст після нього передбачається набирати в підказці терміналу.
$ cd ~$ ls -a

То що це робить?

Перша команда ( cd ~) переміщується до домашнього каталогу (символ «~» представляє домашній каталог). У домашньому каталозі знаходиться більшість ваших конфігураційних файлів. Тож ми переїжджаємо туди першими.

Друга команда перераховує файли та папки в поточному каталозі. Але тут є якась магія. -aПрапор інструктує команду включити приховані файли в списку.

Бінго! Тепер ми бачимо точкові файли!

Змінення .bash_profile

Зазвичай першим файлом, який більшість людей змінюють, потрапляючи у світ точкових файлів, є файл .bash_profileабо .bashrc. І недарма. Цей файл завантажується під час запуску терміналу, а його команди виконуються під час запуску терміналу.

Однією з причин, чому вам може знадобитися змінити ваш, .bash_profileє налаштування зовнішнього вигляду вашого терміналу (конкретно, підказки терміналу). Це мистецтво і наука саме по собі, і, мабуть, повинна мати цілу книгу, присвячену цьому, тому я не буду особливо висвітлювати цю тему в цій статті. Ви можете розпочати налаштування запиту за допомогою цієї статті.

Натомість давайте розглянемо дві загальні конструкції оболонки, які є, мабуть, одними з найважливіших та найкорисніших частин файлів точок: псевдоніми та функції.

Псевдоніми

Псевдоніми - це просто короткі імена / абревіатури, які ви можете призначити довшій послідовності команд, щоб зменшити час, який потрібно ввести, і таким чином збільшити швидкість. Наприклад, майже кожен розробник використовує git. Той, хто використовує git CLI (і погодьмося - ви повинні використовувати git CLI), ймовірно, використовував довгі команди, подібні до цих:

// commit changes$ git commit -m "some changes"
// push changes to the master branch of origin$ git push origin master

Ці команди досить мало набирати. Якщо ви вважаєте, що це не так, ви передумаєте після того, як почнете використовувати псевдоніми.

Введіть у своєму підказці оболонки наступне:

$ alias gpom="git push origin master"

Тепер, коли ви вводите текст gpom, git push origin masterвиконується! Ви перейшли з 4 слів на 4 букви ! ?

Але є проблема. Закрийте термінал, перезапустіть його та повторіть gpomспробу. Ваш псевдонім зник! Це тому, що псевдонім визначений для поточного сеансу терміналу.

Отже, як нам обійти це і змусити наші псевдоніми чіплятися?

Пам'ятаєте, ми говорили про файл, команди якого виконуються при запуску терміналу? Бінго!

Додайте наступний рядок до вашого .bash_profileабо .bashrcта збережіть його:

alias gpom="git push origin master"

Тепер кожного разу, коли ви запускаєте термінал bash, вищезазначений псевдонім створюється. Життя вже починає ставати чудовим!

Примітка. Ви можете використовувати nanoтекстовий редактор для редагування своїх текстових файлів. У домашньому каталозі введіть, nano .bash_profileщоб відкрити файл за допомогою nano, внесіть зміни та збережіть файл, натиснувши, Ctrl+Xа потім, yколи буде запропоновано. Vimце ще один текстовий редактор, яким ви можете скористатися.

Оскільки псевдоніми по суті замінюють повну команду, ви можете псевдоніми використовувати як частину загального інструменту командного інтерфейсу командного інтерфейсу, такого як git, щоб полегшити всі його команди. Просто додайте це до свого .bash_profile:

alias g="git"

І ви можете ввести "g" замість "git", де б ви не хотіли використовувати "git". Солодко!

Ось декілька поширених псевдонімів, які ви можете використовувати:

alias home="cd ~"alias ..='cd ..'alias '?=man'# Git CLI aliasesalias g="git"alias gi="git init"alias gra="git remote add"alias gs="git status"...# Aliases for NPMalias nr="npm run"alias ni="npm install"alias nid="npm install -D"...

Функції

Псевдоніми можуть значно покращити наш робочий процес, але вони не можуть зробити одну справу: працювати з аргументами.

Скажімо, вам набридло виконувати дві команди, щоб створити новий каталог і cdввійти до нього:

$ mkdir new_folder$ cd new_folder

І ви хотіли зробити для цього псевдонім. Але ви не можете, оскільки обидва mkdirі cdберуть аргументи, і ви не можете передавати аргументи в псевдоніми.

І що тепер? Пам'ятайте, існує надзвичайно поширена конструкція програмування, яка приймає аргументи? Так, функції! Сценарії оболонки можуть мати функції, які можуть приймати аргументи. Чудово! Якщо ви трохи іржаві з функціями в сценаріях оболонки, ось невелике нагадування.

Ви можете перетворити наведену вище послідовність у функцію оболонки, як ця (цей приклад взятий з файлів точок mathiasbynens, у якого є кілька найпопулярніших файлів точок. Інші люди з відмінними файлами точок, на які можна посилатися, перераховані та пов’язані з ними в кінці Стаття):

# Create a new directory and enter itfunction mkd() { mkdir -p "[email protected]" && cd "$_";}

Знову ж таки, ви можете помістити це у свій, .bash_profileі функція буде доступна під час будь-якого термінального сеансу.

Примітка. Вам доведеться перезапустити термінал, щоб будь-які зміни .bash_profileвступили в силу. Якщо це звична робота, запустіть, source .bash_profileщоб додати зміни до поточного термінального сеансу. Ще краще, в дусі точкових файлів, зробіть псевдонім типу alias reload="source .bash_profile"!

Точкові файли та спільний доступ

Why do people commit their development environments — their dotfiles — to version control? Why do they put it up on GitHub for everyone to see? Same reason as always: to track how your dotfiles evolve over time and, most importantly, to share your dotfiles and inspire other people.

If you look at any mature dotfiles repo, you’ll realize that there are always snippets taken from other dotfiles repos and the like. They may even have multiple contributors and maintainers. We share dotfiles to collectively help each other build better environments and workflows.

This also allows people to use features of version control to make each others’ dotfiles better. One example of this is using the GitHub Issue Tracker to discuss issues and improvements.

I was inspired to work on my dotfiles from the dotfiles of pradyunsg, who has an impressive dotfiles repo of his own.

My own dotfiles are fairly basic and very immature right now, and they’ll get better over time. But this also means that beginners in the world of dotfiles will be less intimidated when they check the repo out.

Like many other people, I’ve added some support for customization of my dotfiles, so it might be a good idea for people who are new to the idea of dotfiles to fork the repo and try making it their own. More details in the repository. Do check them out and give me feedback!

Here’s a list of a people whose dotfiles are much more expansive and might inspire you:

  • pradyunsg
  • mathiasbynens
  • paulmillr
  • holman

Conclusion

These are the very fundamentals of creating your development environment using dotfiles. However, there is a lot more to this, which we’ll continue looking at in the next article in this series.

Some of the topics we’ll look at in the next article in the series are:

  • Creating an environment to organize, track and painlessly work with dotfiles
  • Splitting our dotfiles to make managing them easier and more scalable (notice it is dotfiles, not dotfile)
  • Writing scripts to setup (bootstrap) a new system with our dotfiles
  • Making our dotfiles easy to share by adding support for customization

That concludes the first part of the series on dotfiles! Here’s a link to the next one.

I loved the idea of dotfiles so much that it inspired me to create a basic dotfile management framework - autodot. The framework is in its infancy, so I’m looking for enthusiastic people who can give me feedback for the framework, contribute to it by telling me about bugs and making feature requests, and contribute to the code and documentation. Do take some time out for this! :)

ajmalsiddiqui/autodot

autodot - A dotfile management system that makes sharing your dotfiles easy while keeping you in the loop.github.com

Also, connect with me on GitHub and LinkedIn.

Good luck and Happy Coding! :)