Въведение в Dotfiles: как да поемете контрола върху вашата среда за разработка

Забележка: Това е много основна, уводна статия. Ако вече знаете основите на управлението на dotfile, препоръчвам ви да прочетете втората ми статия.

Като разработчици ние се стремим да сведем до минимум времето, което отделяме за излишни неща, като например създаване на нашата среда, писане на шаблонни кодове и по принцип не правим нищо, което не касае забавната част от кодирането - изграждането на нови неща.

В този контекст, представете си перфектен свят, в който малките команди изпълняват невероятно сложни задачи, съобразени с вашите нужди, където можете да си купите нов лаптоп днес и да инсталирате всички инструменти и пакети, от които се нуждаете, и да настроите вашата среда за разработка с нищо, освен няколко терминала команди и където всичко е магия.

Тази дигитална приказна страна може да бъде направена и с лекота. И има име за тази магия: dotfiles.

Без повече шум, нека разгадаем тайните на точките!

Въведение

Забележка: Тази статия предполага, че работите с подобна на Unix операционна система и тя разчита основно на Unix терминални команди и скриптове на черупки. Ако не сте запознати с тях, препоръчвам да научите основите и да се върнете тук. Ето буква за скриптове на черупки.

В UNIX-подобни системи много конфигурационни файлове и подобни са предшествани с точка (.). Тези файлове са скрити от операционната система по подразбиране и дори lsкомандата не разкрива тяхното присъствие (ще стигнем до начина за намиране на тези файлове след малко). Тъй като тези файлове са предшествани от точка, те се наричат ​​точки. Да.

И така, как да намерим тези легендарни файлове, ако те са скрити по подразбиране? Отворете терминал и направете това:

Забележка: Знакът "$" не е предназначен за въвеждане в терминала. Представлява факта, че текстът след него трябва да бъде въведен в терминален ред.
$ 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е друг текстов редактор, който можете да използвате.

Тъй като псевдонимите по същество заместват пълната команда, можете да създадете псевдоними като част от общ многокоманден CLI инструмент като 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вземете аргументи, и не можете да предавате аргументи на псевдоними.

И сега какво? Не забравяйте, че има супер често срещана програмна конструкция, която взема аргументи? Да, функции! Скриптовете на черупки могат да имат функции, които могат да приемат аргументи. Страхотно! Ако сте малко ръждясали с функции в скриптове на черупки, ето малко напомняне.

Можете да превърнете горната последователност в функция на черупката като тази (този пример е взет от dotfiles на mathiasbynens, който има някои от най-популярните dotfiles наоколо. Други хора с отлични dotfiles, към които да се отнасят, са изброени и свързани към тях в края на статията):

# 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! :)