Bevezetés a Dotfiles-ba: hogyan veheti át a fejlesztői környezet irányítását

Megjegyzés: Ez egy nagyon alapvető, bevezető cikk. Ha már ismeri a dotfile kezelés alapjait, akkor azt javasoljuk, olvassa el a második cikkemet.

Fejlesztőként arra törekszünk, hogy minimalizáljuk a felesleges dolgokra fordított időt, mint például a környezetünk beállítása, a kazán kódjának megírása, és alapvetően semmi olyasmi nem, ami a kódolás szórakoztató részét nem érinti - új dolgok felépítése.

Ebben az összefüggésben képzeljen el egy tökéletes világot, ahol az apró parancsok hihetetlenül összetett feladatokat hajtanak végre az Ön igényeinek megfelelően, ahol ma vásárolhatna egy új laptopot, és telepítheti az összes szükséges eszközt és csomagot, és csak néhány terminállal állíthatja be a fejlesztői környezetet. parancsokat, és ahol minden varázslat.

Ez a digitális tündérország egyszerűen és egyszerűen elkészíthető. És ennek a varázslatnak van neve: dotfiles.

Minden további nélkül feltárjuk a dotfile titkait!

Bevezetés

Megjegyzés: Ez a cikk feltételezi, hogy Unix-szerű operációs rendszerrel dolgozik, és nagymértékben támaszkodik a Unix terminálparancsokra és a shell parancsfájlokra. Ha még nem ismeri ezeket, javasoljuk, hogy tanulja meg az alapokat, és térjen vissza ide. Itt van egy alap a szkriptek héjához.

UNIX-szerű rendszerekben sok konfigurációs fájl és hasonlók előtt egy pont (.) Található. Ezeket a fájlokat az operációs rendszer alapértelmezés szerint elrejti, és még a lsparancs sem fedi fel a jelenlétüket (majd megismerjük, hogyan találjuk meg ezeket a fájlokat egy kicsit). Mivel ezeket a fájlokat pont megelőzi, pontfájloknak hívják őket. Duh.

Tehát hogyan találjuk meg ezeket a legendás fájlokat, ha alapértelmezés szerint el vannak rejtve? Nyissa meg a terminált, és tegye ezt:

Megjegyzés: A „$” jelet nem a terminálba kell beírni. Ez azt a tényt képviseli, hogy a szöveget azután állítólag egy terminálba kell beírni.
$ cd ~$ ls -a

Tehát mit csinál ez?

Az első parancs ( cd ~) a saját könyvtárba költözik (a „~” szimbólum a saját könyvtárat jelöli). A saját könyvtárban található a legtöbb konfigurációs fájl. Tehát előbb oda költözünk.

A második parancs felsorolja az aktuális könyvtár fájljait és mappáit. De van itt valami varázslat. A -aflag utasítja a parancsot, hogy rejtett fájlokat vegyen fel a listába.

Bingó! Most láthatjuk a dotfile-okat!

A .bash_profile módosítása

Általában az első fájl, amelyet a legtöbb ember módosít, amikor belép a dotfiles világába, a .bash_profilevagy a .bashrc. És jó okkal. Ez a fájl a terminál indításakor töltődik be, és parancsai a terminál indításakor hajtódnak végre.

Az egyik oka annak, miért érdemes módosítania .bash_profilea terminál megjelenésének testreszabását (konkrétan a terminál parancssorát). Ez önmagában művészet és tudomány, és valószínűleg egy egész könyvet kellene szentelni neki, ezért ebben a cikkben nem sokat foglalkozom ezzel a témával. A cikk testreszabásával megkezdheti a felszólítás testreszabását.

Ehelyett nézzünk meg két gyakori héjszerkezetet, amelyek talán a dotfiles legfontosabb és leghasznosabb részei: álnevek és függvények.

Álnevek

Az álnevek egyszerűen rövid nevek / betűszavak, amelyeket hosszabb parancssorozathoz rendelhetünk annak érdekében, hogy csökkentsük a gépelés időtartamát és ezáltal növeljük a sebességet. Például szinte minden fejlesztő használja a git-t. Bárki, aki használja a git CLI-t (és valljuk be, a git CLI-t kell használnia), valószínűleg ilyen hosszú parancsokat használt:

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

Ezeket a parancsokat elég sok gépelni. Ha úgy gondolja, hogy nem azok, akkor meggondolja magát, miután elkezdi használni az álneveket.

Írja be a következőket a shell parancssorába:

$ alias gpom="git push origin master"

Most, amikor gépel gpom, git push origin mastervégrehajtásra kerül! 4 szóból 4 betűvé vált ! ?

De van egy probléma. Zárja be a terminált, indítsa újra és próbálja gpomújra. Az álneved eltűnt! Ez azért van, mert az álnév meg van határozva az aktuális terminál munkamenethez.

Tehát hogyan lehet ezt megkerülni, és ragaszkodni az álneveinkhez?

Emlékszel, hogy beszéltünk egy fájlról, amelynek parancsai végrehajtásra kerülnek egy terminál indításakor? Bingó!

Adja hozzá a következő sort a .bash_profilevagy a .bashrcmappához, és mentse el:

alias gpom="git push origin master"

Most, amikor elindít egy bash terminált, létrejön a fenti álnév. Az élet már kezd félelmetes lenni!

Megjegyzés: A nanoszövegszerkesztővel szerkesztheti a szöveges fájlokat. Ha a saját könyvtárban van, írja be, nano .bash_profilehogy megnyitja a fájlt a nano használatával, végezze el a módosításokat, és mentse el a fájlt ütéssel Ctrl+X, majd a rendszer ykéri. Vimegy másik szövegszerkesztő, amelyet használhat.

Mivel az álnevek lényegében a teljes parancsot helyettesítik, álneveket használhat egy közös több parancsos CLI eszköz részeként, például a git, hogy minden parancsát megkönnyítse. Csak adja hozzá ezt a következőhöz .bash_profile:

alias g="git"

A „git” helyett pedig „g” betűket írhat be, bárhová is szeretné használni a „git” szót. Édes!

Íme néhány gyakori álnév, amelyet érdemes használni:

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

Funkciók

Az álnevek nagyban hozzájárulhatnak a munkafolyamatunk javításához, de egy dolgot nem tudnak megtenni: érvekkel dolgozni.

Tegyük fel, hogy belefáradt két parancs végrehajtásába egy új könyvtár létrehozásához és cdabba:

$ mkdir new_folder$ cd new_folder

És erre álnevet akartál készíteni. De nem lehet, mivel mind mkdirés cdtake érveket, és nem tudja átadni érveket álnevek.

És most mi lesz? Ne feledje, hogy van egy szuper közös programozási konstrukció, amely argumentumokat vesz fel? Igen, funkciók! A Shell szkriptek tartalmazhatnak olyan funkciókat, amelyek argumentumokat vehetnek fel. Fantasztikus! Ha kissé rozsdás vagy a shell parancsfájlokban található funkciókkal, íme egy kis emlékeztető.

A fenti szekvenciát ilyen héjfüggvénnyé alakíthatja (ez a példa a mathiasbynens dotfile-jéből származik, aki a legnépszerűbb dotfile-ok körül van. Másokat, akiknek kiváló dotfile-okra hivatkozhatunk, a a cikk):

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

Ismét beteheti ezt a könyvtárába, .bash_profileés a funkció bármely terminál munkamenet során elérhető lesz.

Megjegyzés: A terminál bármilyen változásának .bash_profileéletbe léptetéséhez újra kell indítania a terminált . Ha ez nehéz feladat, futtassa source .bash_profilea módosítások hozzáadásához az aktuális terminál munkamenethez. Még jobb, hogy a dotfile-ok szellemében készítsen hasonló nevet alias reload="source .bash_profile"!

Dotfiles és megosztás

Miért kötelezik az emberek fejlesztői környezetüket - a dotfájljaikat - a verziókontrollra? Miért teszik fel a GitHubra, hogy mindenki láthassa? Ugyanaz az ok, mint mindig: annak nyomon követése, hogy a dotfájlok hogyan fejlődnek az idő múlásával, és ami a legfontosabb, hogy megosszák a dotfileikat és inspiráljanak más embereket .

Ha megnéz egy kiforrott dotfile repót, rájön, hogy mindig vannak kivonatok más dotfiles repókból és hasonlókból. Még több közreműködőjük és fenntartójuk is lehet. Dotfájlokat osztunk meg, hogy együttesen segítsük egymást a jobb környezetek és munkafolyamatok felépítésében.

Ez lehetővé teszi az emberek számára a verzióvezérlés funkcióinak használatát, hogy jobbá tegyék egymás dotfile-jait. Ennek egyik példája a GitHub Issue Tracker használata a problémák és a fejlesztések megvitatására.

A pradyunsg dotfile-i inspiráltak a dotfileimre, akiknek saját lenyűgöző dotfiles repo-ja van.

Saját dotfileim jelenleg meglehetősen egyszerűek és nagyon éretlenek, és idővel jobbak lesznek. De ez azt is jelenti, hogy a kezdők a dotfiles világában kevésbé lesznek megfélemlítve, amikor megnézik a repót.

Sok más emberhez hasonlóan én is támogattam a dotfileim testreszabását, ezért jó ötlet lehet azoknak az embereknek, akik még nem ismerik a dotfile-eket, ha elvarázsolják a repót, és megpróbálják saját magukká tenni. További részletek a tárban. Nézze meg őket, és adjon visszajelzést!

Íme egy lista azokról az emberekről, akiknek a dotfájljai sokkal kiterjedtebbek és inspirálhatnak:

  • pradyunsg
  • mathiasbynens
  • paulmillr
  • holman

Következtetés

Ezek a fejlesztési környezet dotfiles használatával történő létrehozásának alapjai. Ennek azonban még sok minden van, amelyet a sorozat következő cikkében folytatunk.

Néhány téma, amelyet a sorozat következő cikkében megvizsgálunk:

  • Környezet létrehozása a dotfile-ok szervezéséhez, nyomon követéséhez és a fájdalommentes munkavégzéshez
  • 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! :)