En introduktion til Dotfiles: hvordan du tager kontrol over dit udviklingsmiljø

Bemærk: Dette er en meget grundlæggende, indledende artikel. Hvis du allerede kender det grundlæggende i dotfile management, vil jeg anbefale dig at læse min anden artikel.

Som udviklere stræber vi efter at minimere den tid, vi bruger på overflødige ting, som at oprette vores miljø, skrive kedelpladekode og dybest set ikke gøre noget, der ikke vedrører den sjove del af kodning - opbygning af nye ting.

Forestil dig i denne sammenhæng en perfekt verden, hvor små kommandoer udfører utroligt komplekse opgaver, der er skræddersyet til dine behov, hvor du kunne købe en ny bærbar computer i dag og installere alle de værktøjer og pakker, du har brug for, og opsætte dit udviklingsmiljø med intet andet end et par terminaler kommandoer, og hvor alt er magisk.

Dette digitale eventyrland kan laves og med lethed. Og der er et navn til denne magi: dotfiles.

Uden yderligere ado, lad os opklare dotfiles hemmeligheder!

Introduktion

Bemærk: Denne artikel antager, at du arbejder med et Unix-lignende operativsystem, og det er stærkt afhængig af Unix-terminalkommandoer og shell-scripting. Hvis du ikke er fortrolig med disse, anbefaler jeg at lære det grundlæggende og komme tilbage her. Her er en primer til shell-scripting.

I UNIX-lignende systemer foregår mange konfigurationsfiler og lignende med en prik (.). Disse filer er som standard skjult af operativsystemet, og selv lskommandoen afslører ikke deres tilstedeværelse (vi kommer til, hvordan man finder disse filer lidt). Da disse filer er forud for en prik, kaldes de dotfiles. Duh.

Så hvordan finder vi disse legendariske filer, hvis de er skjult som standard? Åbn en terminal, og gør dette:

Bemærk: “$” -tegnet er ikke beregnet til at blive skrevet i terminalen. Det repræsenterer det faktum, at teksten efter den formodes at blive skrevet i en terminalprompt.
$ cd ~$ ls -a

Så hvad gør dette?

Den første kommando ( cd ~) flytter ind i hjemmemappen (symbolet “~” repræsenterer hjemmemappen). Hjemmappen er, hvor de fleste af dine konfigurationsfiler findes. Så vi flytter der først.

Den anden kommando viser filerne og mapperne i det aktuelle bibliotek. Men der er noget magi her. Den -aflaget instruerer kommandoen til at inkludere skjulte filer på listen.

Bingo! Vi kan nu se dotfilerne!

Ændring af .bash_profile

Normalt er den første fil, som de fleste mennesker ændrer, når de kommer ind i dotfiles-verdenen, den .bash_profileeller den .bashrc. Og med god grund. Denne fil indlæses, når du starter din terminal, og dens kommandoer udføres ved start af terminalen.

En af grundene til, at du måske vil ændre din .bash_profileer at tilpasse udseendet på din terminal (for at være specifik, din terminalprompt). Dette er en kunst og en videnskab i sig selv og burde sandsynligvis have en hel bog dedikeret til det, så jeg vil ikke dække dette emne meget i denne artikel. Du kan komme i gang med at tilpasse din prompt med denne artikel.

Lad os i stedet se på to almindelige skalkonstruktioner, der måske er blandt de vigtigste og nyttige dele af dotfiles: aliaser og funktioner.

Aliaser

Aliaser er simpelthen korte navne / akronymer, som du kan tildele til en længere rækkefølge af kommandoer for at reducere, hvor lang tid du tager at skrive det og dermed øge din hastighed. For eksempel bruger næsten alle udviklere git. Enhver, der bruger git CLI (og lad os indse det - du skal bruge git CLI), har sandsynligvis brugt lange kommandoer som disse:

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

Disse kommandoer er ganske lidt at skrive. Hvis du tror, ​​de ikke er det, vil du skifte mening, når du begynder at bruge aliasser.

Skriv følgende i din shell-prompt:

$ alias gpom="git push origin master"

Nu når du skriver gpom, git push origin masterudføres! Du er gået fra 4 ord til 4 bogstaver ! ?

Men der er et problem. Luk din terminal, genstart den, og prøv gpomigen. Dit alias er væk! Dette skyldes, at aliaset er defineret for den aktuelle terminalsession.

Så hvordan kommer vi omkring dette og får vores aliasser til at holde fast?

Husker vi, at vi talte om en fil, hvis kommandoer udføres, når en terminal startes? Bingo!

Føj følgende linje til din .bash_profileeller .bashrcog gem den:

alias gpom="git push origin master"

Nu, når du starter en bash-terminal, oprettes ovenstående alias. Livet begynder allerede at blive fantastisk!

Bemærk: Du kan bruge nanoteksteditoren til at redigere dine tekstfiler. Når du er i hjemmekataloget, skal du skrive for nano .bash_profileat åbne filen ved hjælp af nano, foretage dine ændringer og gemme filen ved at trykke på Ctrl+Xog derefter, ynår du bliver bedt om det. Vimer en anden teksteditor, du kan bruge.

Da aliasser i det væsentlige erstatter den fulde kommando, kan du aliasser som en del af et fælles CLI-værktøj med flere kommandoer som git for at gøre alle dens kommandoer lettere. Bare tilføj dette til din .bash_profile:

alias g="git"

Og du kan skrive "g" i stedet for "git", hvor du vil bruge "git". Sød!

Her er et par almindelige aliasser, du måske vil bruge:

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"...

Funktioner

Aliaser kan komme langt i at forbedre vores arbejdsgang, men der er en ting, de ikke kan gøre: arbejde med argumenter.

Lad os sige, at du var træt af at udføre to kommandoer for at oprette en ny mappe og cdind i den:

$ mkdir new_folder$ cd new_folder

Og du ville lave et alias for dette. Men du kan ikke, da både mkdirog cdtake argumenter, og du kan ikke passere argumenter til aliaser.

So what now? Remember, there’s a super common programming construct that takes arguments? Yup, functions! Shell scripts can have functions that can take arguments. Awesome! If you’re a little rusty with functions in shell scripts, here’s a little reminder.

You can turn the above sequence into a shell function like this (this example was taken from the dotfiles of mathiasbynens, who has some of the most popular dotfiles around. Other people with excellent dotfiles to refer to are listed and linked to at the end of the article):

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

Again, you can put this in your .bash_profile and the function will be accessible during any terminal session.

Bemærk: Du bliver nødt til at genstarte din terminal for at ændringer i din .bash_profileskal træde i kraft. Hvis dette er en opgave, skal du køre for source .bash_profileat tilføje dine ændringer til den aktuelle terminalsession. Endnu bedre, i ånden af ​​dotfiles, lav et alias som alias reload="source .bash_profile"!

Dotfiles og deling

Hvorfor forpligter folk deres udviklingsmiljøer - deres dotfiles - til versionskontrol? Hvorfor sætter de det op på GitHub for alle at se? Samme grund som altid: at spore, hvordan dine dotfiles udvikler sig over tid, og vigtigst af alt at dele dine dotfiles og inspirere andre mennesker .

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 - Et dotfile-styringssystem, der gør det nemt at dele dine dotfiles, mens du holder dig i løkken. github.com

Opret også forbindelse til mig på GitHub og LinkedIn.

Held og lykke og glad kodning! :)