Slik administrerer du .dot-filene dine med GNU Stow trinn for trinn

Hvis du bruker Linux, macOS eller Termux på Android Hver dag, før eller siden, ender du opp med å samle en haug med konfigurasjonsfiler spredt overalt på datamaskinen din. hjemmekatalog: .zshrc, .bashrc, .config, nvim, Hyprland, osv. Når du bare har én datamaskin kan du overleve, men så snart du jobber med flere datamaskiner eller servere, er det en helt annen historie å holde alt dette oppdatert.

I denne sammenhengen spiller følgende inn GNU Stow, en symbolsk lenkebehandler som har blitt en av de reneste, enkleste og mest reversible måtene å administrere dotfiler på. Det er ikke den eneste mulige tilnærmingen (det finnes alternativer som Git bare repositories, yadm, Chezmoi, Dotbot…), men den minimalistiske filosofien passer perfekt hvis du vil ha noe kraftig uten for mye styr bak det.

Hva er egentlig GNU Stow, og hvorfor er det nyttig for å administrere .dot-filer?

GNU Stow er opprinnelig en «symlink-farmadministrator»Et verktøy designet for å organisere flere fil"pakker" på ett sted og eksponere dem i en annen katalog ved hjelp av symbolske lenker. Selv om det ble unnfanget for å administrere lokale programvareinstallasjoner, tok fellesskapet det raskt i bruk for å håndtere punktfiler fordi det passer perfekt.

Grunnideen er veldig enkel: du lagrer alle innstillingene dine i én fil. sentralt arkiv (for eksempel ~/dotfiles)Disse filene er strukturert som om de skulle ligge i hjemmekatalogen din, og Stow tar seg av å opprette symlenker fra hjemmekatalogen din til disse filene. Dette lar deg versjonere dem med Git, klone dem på flere maskiner og reprodusere miljøet ditt med én eller noen få kommandoer.

Noe viktig: Stow er ikke et «dotfile-verktøy» i streng forstand.Den lagrer ikke sin egen tilstand, vedlikeholder ikke en database, bruker ikke maler eller bruker kryptering. Den oppretter og sletter ganske enkelt symbolske lenker etter en katalogstruktur. Det er nettopp derfor den er så enkel å forstå og tilbakestille.

Denne minimalistiske filosofien står i kontrast til mer komplekse løsninger som Chezmoi, som legger til maler, hemmelig administrasjon, integrasjon med passordbehandlere og en mer automatisert arbeidsflyt. Med Stow har du kontrollen: alt er i filsystemet og Git-repoet ditt., uten mellomlag.

Fordeler med å bruke Stow sammenlignet med andre måter å administrere dotfiler på

Før Stow ble populært, administrerte mange dotfilene sine ved hjelp av kommandoene "cp" og "mv".Konfigurasjoner ble kopiert manuelt mellom datamaskiner, eller det ble vedlikeholdt et arkiv som krevde konstant oppdatering. Det var lett å ende opp med flere versjoner av samme fil og ikke vite hvilken som faktisk var i bruk.

Med Stow ligger alle de «ekte» filene i dotfiles-katalogen din, og $HOME-katalogen din inneholder bare symbolske lenkerDette betyr at når du redigerer for eksempel ~/.zshrc, endrer du faktisk filen i depotet ditt. Det er ingen duplikater, ingen desynkronisering, og du trenger ikke å huske hva du skal kopiere og hvor.

En annen klar fordel er reversibilitet: Hvis du vil angre det Stow har gjort, kjører du bare «stow -D package». Fra dotfiles-mappen din, slett alle symbolske lenker som er opprettet for den pakken. Dette sletter ikke de faktiske konfigurasjonene dine (som forblir i depotet), det fjerner bare de symbolske lenkene til målpakken.

Videre fungerer Stow veldig bra med Git: Du kan versjonere ~/dotfiles som et vanlig arkivDu kan lage commits, opprette grener, bruke GitHub eller GitLab som sikkerhetskopi, osv. Stow ignorerer automatisk .git-mappen når den genererer lenker, slik at du ikke risikerer å fylle $HOME-katalogen din med interne Git-filer.

Til slutt, i motsetning til andre tyngre verktøy, Stow er vanligvis tilgjengelig på alle Linux-distroer og til og med på macOS via Homebrew.Det er i bunn og grunn en script skrevet i Perl med svært få avhengigheter og fungerer i alle miljøer UNIX.

Vanlige alternativer: Git bare, yadm, Chezmoi, Dotbot…

Når du vurderer å administrere dotfiler på alvor, dukker vanligvis den samme listen over alternativer opp: Git-repositoriet «bare», yadm, Dotbot, Chezmoi, pluss StowHver tilnærming har sin egen stil og sitt eget publikum, så det er viktig å plassere Stow innenfor det økosystemet.

Metoden for bart Git-depot Dette innebærer å initialisere et repository uten et tilknyttet arbeidstre og bruke Git-aliaser slik at $HOME selv fungerer som arbeidskatalog. Fordeler: det er ingen symbolske lenker, Git fungerer direkte på de faktiske filene dine, og kommandoflyten er veldig enkel. Mange brukere kommenterer at de ble overrasket over hvor enkelt det var å følge en veiledning i "DT"-stil og få den til å fungere uten å berøre noen symbolske lenker.

Videre Chezmoi fokuserer utelukkende på avansert dotfile-håndteringFunksjoner inkluderer: maler for håndtering av forskjeller mellom maskiner, integrasjon med passordbehandlere, filkryptering med GPG eller AGE, kroker for å kjøre skript under installasjon, robust plattformuavhengig støtte og mer. Det er ideelt hvis du trenger administrere hemmeligheter, støtte mange forskjellige systemer eller automatisere komplekse installasjoner.

Stow er i motsatt ytterlighet: Han vet ingenting om hemmeligheter, maler eller manusDen lager rett og slett rene symbolske lenker. For mange brukere er det en dyd: mindre å lære, mindre "magisk" oppførsel og større gjennomsiktighet. Hvis du trenger tung betinget logikk, er Chezmoi sannsynligvis en bedre løsning. Hvis du bare vil holde konfigurasjonene dine organisert uten komplikasjoner, er Stow en veldig pålitelig klassiker.

Det er også verktøy som Yadm eller Dotbot, som automatiserer tonnevis av oppgaver (inkludert kjøring av skript etter installasjon, kloning av repositorier, installasjon av pakker osv.). Likevel foretrekker et godt antall utviklere fortsatt Stow fordi det er enkelt å revidere, integreres godt med eksisterende Git-arbeidsflyter og tilpasser seg sømløst til både minimalistiske oppsett og mer krevende skrivebordsmiljøer.

Organisatoriske tilnærminger: enhetlig arkiv vs. pakkebasert arkiv

Når du begynner å bruke Stow, er en av de første avgjørelsene du må ta Slik strukturerer du dotfiles-arkivet dittGenerelt sett finnes det to populære mønstre: den enhetlige tilnærmingen og den pakkebaserte tilnærmingen.

I den enhetlige modellen har dotfiles-depotet ditt tilnærmet samme form som $HOME-katalogen din: filer som .bashrc eller .zshrc i roten, og mapper som .config/nvim eller .config/lazygit inniNoe sånt som dette:

dotfiles-unified/
├── .bash_aliaser
├── .bash_fullføring/
│ └── alacritty.bash
├── .bashrc
└── .config/
├── lazygit/config.yml
└── nvim/…

Med dette designet går du inn i repository-mappen, du kjører stuv. og plutselig, Alle innstillingene dine er koblet til $HOME-katalogen din.Det er utrolig praktisk når du vil klone hele miljøet ditt til en ny maskin med én enkelt kommando og ikke trenger mye differensiering mellom systemene.

Den pakkebaserte tilnærmingen fungerer annerledes: Du oppretter en underkatalog per «modul» eller applikasjonFor eksempel, én for bash, en annen for nvim, en annen for lazygit, en annen for zsh, en annen for Hyprland, osv. Hver katalog inneholder filene med den fullstendige stien de ville hatt i $HOME-katalogen din. Noe sånt som:

dotfiles-pakker/
├── bash/
│ ├── .bash_aliaser
│ ├── .bash_completion/alacritty.bash
│ └── .bashrc
├── lazygit/.config/lazygit/config.yml
└── nvim/.config/nvim/…

Med denne ordningen kan du bestemme hvilke pakker som skal "aktiveres" på hver maskin: På én maskin kjører du «stow bash nvim lazygit», på en annen kanskje «stow zsh nvim».Dette er veldig nyttig når du jobber med flere distribusjoner (for eksempel Arch på én PC og Fedora på en annen) eller med forskjellige skall (fish på én maskin, bash på en annen) og du vil beholde alt i ett enkelt repository, men velge hva som skal brukes i hvert miljø.

Fangsten? Det er litt mer komplisert: «Stow» er ikke lenger nok. Og det er alt; du trenger bare å huske hvilke pakker du trenger.Alternativt kan du opprette et lite skript per maskin som kaller Stow med riktig kombinasjon. Likevel foretrekker mange brukere denne finjusterte kontrollen, spesielt hvis de har svært spesifikk programvare på hver maskin.

Hvordan Stow fungerer internt: konseptet med katalog-"speiling"

Nøkkelen til å forstå Stow er systemet med speiling av katalogstrukturerStow gjetter ikke stier; den ser bare på hvordan filene er organisert i "pakken" og plasserer de tilsvarende symbolske lenkene i målkatalogen.

Hvis for eksempel et program forventer konfigurasjonen sin i:

~/.config/ghostty/

Modulen din i ~/dotfiles skal ha akkurat den relative stien:

~/dotfiles/ghostty/.config/ghostty/

Alt du plasserer inni (for eksempel en fil kalt config) vil bli lenket av Stow til riktig plassering. På denne måten vil Ghostty fortsette å lese konfigurasjonen sin fra ~/.config/ghostty/config, men den filen vil faktisk peke til den som er lagret i depotet ditt.

Dette mønsteret gjentas for alle verktøy: Waybar ville ha noe sånt som ~/dotfiles/waybar/.config/waybar/, Neovim ~/dotfiles/nvim/.config/nvim/og så videre. Prosessen er ekstremt ensartet, noe som gjør skalering til flere programmer nærmest mekanisk.

For punktfiler som ligger direkte i $HOME (som ~/.gitconfig eller ~/.zshrc) er logikken identisk: Inne i git-pakken vil du ha en .gitconfig-fil i rotkatalogen.Stow vil deretter opprette lenken i hjemmekatalogen din når du kjører «stow git».

Steg for steg: oppsett av et dotfiles-arkiv med Stow

Den typiske arbeidsflyten med Stow er enkel og kan oppsummeres i noen få veldefinerte trinn, både på Linux og macOS. Det viktigste er å venne seg til at de «ekte» filene alltid er inne i repoet. og ikke spredt over hele $HJEMMEET ditt.

For å begynne, opprett mappen der punktfilene dine skal ligge. Mange bruker ~/.dotfiler eller ~/dotfilerNavnet er det minst viktige:

mkdir -p ~/.dotfiles
cd ~/.dotfiles

da Flytt dine nåværende konfigurasjonsfiler til depotetHvis du for eksempel har en .bashrc-fil i hjemmekatalogen din og vil administrere den med Stow, kan du gjøre følgende:

mv ~/.bashrc ~/.dotfiles/.bashrc

Hvis du foretrekker den pakkebaserte tilnærmingen, i stedet for å la filen ligge i roten av repoet, ville du legge den i en "bash"-mappe og beholde hele stien:

mkdir -p ~/.dotfiles/bash
mv ~/.bashrc ~/.dotfiles/bash/.bashrc

Fremgangsmåten med konfigurasjoner som er inni .config er analog: Du replikerer katalogstrukturen i repoetFor eksempel, for Neovim kan du ha:

mkdir -p ~/.dotfiles/nvim/.config/nvim
mv ~/.config/nvim/* ~/.dotfiles/nvim/.config/nvim/

Når filene er i depotet ditt, er det lurt å slette eller gi nytt navn til originalene i $HOME for å unngå konflikter. Senere vil Stow gjenskape de symbolske lenkene i stiene der applikasjoner forventer å finne konfigurasjonene sine.

Installer GNU Stow på forskjellige plattformer

Installasjonen av Stow varierer litt avhengig av plattformen, men totalt sett er det ekstremt enkelt. På macOS er det vanlig å bruke Homebrew., den mest utbredte pakkebehandleren på dette systemet:

brew install stow

I Linux-distribusjoner som Debian eller Ubuntu er vanlig praksis å bruke apt:

sudo apt install stow

En Arch Linux og derivater, finner du den i de offisielle repositoriene og den er installert med pacman uten mye mystikk:

sudo pacman -S stow

Når den er installert, har du «stow»-kommandoen i PATH-banen din. Det finnes ingen daemoner eller bakgrunnstjenester, bare en binærfil som kjører når du trenger den.Du kan sjekke at alt fungerer som det skal med kommandoen «stow --version», og så er du ferdig.

På systemer der du allerede bruker verktøy som Oh My Zsh, passer Stow veldig bra inn: du kan beholde både .zshrc-filen og konfigurasjonen av plugins og temaer i ditt sentrale repo og bruke alt med et par kommandoer. Mange brukere med flere Mac Eller, ved å bruke en blanding av Linux og macOS, sier de at de på denne måten klarer å ha det samme skallet og den samme ledeteksten overalt..

Ignorer uønskede filer med .stow-local-ignore

En av de fine detaljene ved Stow er ignoreringssystemet. Som standard ignorerer Stow allerede visse typiske versjonskontrollfiler. som for eksempel .git, .gitignore, .gitmodules, CVS-kataloger, RCS, osv. Det finnes imidlertid situasjoner der du trenger mer spesifikk kontroll, for eksempel på macOS med den beryktede .DS_Store.

Stow lar deg opprette en fil som heter .stow-local-ignore i katalogen du kjører kommandoen fra. Den filen definerer hvilke mønstre som skal ignoreres lokalt. Når du har opprettet den, slutter du å bruke standard ignoreringsliste, så du må legge dem til selv og inkludere eventuelle tillegg.

Et typisk eksempel på .stow-local-ignore-innhold ville inkludere kommentarer og mønstre for CVS-konflikter, Emacs-sikkerhetskopier, versjonskontrollfiler og på slutten .DS_Store slik at Stow ikke klager eller prøver å lenke til filene som genereres av Finder:

# Comentarios y líneas en blanco permitidas
RCS
.+,v
CVS
\.#.+
\.cvsignore
\.svn
_darcs
\.hg
\.git
\.gitignore
\.gitmodules
.+~
\#.*\#
^/README.*
^/LICENSE.*
^/COPYING
.DS_Store

Takket være dette hindrer du Stow i å prøve å lage fullstendig irrelevante fillenker og Du unngår irriterende feil ved oppbevaring eller utpakking av pakkerDette er spesielt nyttig hvis du ofte bruker grafiske grensesnitt som genererer hjelpefiler i depotet ditt.

Husk at Stows ignore er uavhengig av .gitignore-filen du bruker i depotet ditt: Den første kontrollerer hva som er lenket, den andre hva som er versjonert.Mellom de to kan du finjustere oppførselen til både Stow og Git.

Grunnleggende bruk av Stow: kobling og oppheving av konfigurasjonspakker

Med alt forberedt, er Stows daglige drift svært konsis. Du bør alltid kjøre Stow fra dotfiles-repokatalogen din., ikke fra din $HOME eller fra vilkårlige ruter, slik at de relative rutene den genererer gir mening.

Tenk deg at du allerede har en modul kalt «ghostty» i ~/dotfiles/ghostty/.config/ghostty med konfigurasjonsfilen din. Når den er i depotet, kan du lagre den med:

cd ~/dotfiles
stow ghostty

Denne kommandoen fører til at symbolske lenker vises på systemet ditt fra ~/.config/ghostty til filene som ligger i ~/dotfiles/ghostty/.config/ghostty. Hvis du gjør en «ls -l ~/.config/ghostty», vil du se sopp (->) som indikerer målet for hver symlenke.bekrefter at alt er riktig koblet.

Hvis du velger en enhetlig tilnærming og ønsker å koble sammen alt samtidig, Du kan kjøre «stow» fra roten av repoetStow vil tolke hver underkatalog som en pakke, eller jobbe direkte med strukturen hvis du har en flat en, og lage symlenker for alt som passer.

For å tilbakestille en spesifikk pakke, kall ganske enkelt Stow med -D-alternativet (for "slett" i verktøyets terminologi). For eksempel:

cd ~/dotfiles
stow -D ghostty

Det fjerner symbolske lenker jeg hadde opprettet for den modulen uten å berøre de originale filene som fortsatt er i depotet. Det er en veldig ren måte å "avinstallere" konfigurasjoner fra en bestemt maskin. uten å miste dem helt.

Det er viktig å unngå en veldig vanlig feil: Ikke kjør Stow fra $HOME eller fra andre mapper utenfor depotetHvis du gjør dette, risikerer du å lage lenker på uventede steder og ende opp med at hjemmekatalogen din er full av ting som ikke hører hjemme. Alltid: `cd` til depotet, deretter `stow`.

Integrer Git og GitHub i dotfile-arbeidsflyten din med Stow

Det fine med hele dette oppsettet er å kombinere Stow med Git slik at din dotfiles er versjonerte, sikkerhetskopieres eksternt og kan enkelt replikeres på andre maskinerProsessen er veldig enkel og ikke ulik andre prosjekter du administrerer med Git.

Fra dotfiles-mappen din, initialiser et nytt repository hvis du ikke allerede har gjort det:

cd ~/dotfiles
git init

Derfra kan du legge til filene dine, gjøre commits og jobbe med grener som vanlig. En ev. boot kunne vært:

git add .
git commit -m "Primer commit de mis dotfiles"

Det neste trinnet er vanligvis å opprette et repository på GitHub, GitLab eller en annen tjeneste og legge det til som en ekstern tjeneste. Noe sånt som dette:

git remote add origin git@github.com:tuusuario/dotfiles.git
git push -u origin main

Husk at selv om noen publiserer punktfilene sine i offentlige arkiver, Det mest fornuftige tiltaket er å bruke private databaser hvis du håndterer sensitive data. eller ruter som kan avsløre for mye personlig informasjon. Uansett kan du supplere dette med ekstern kryptering for hemmeligheter om nødvendig.

For å finjustere hva som blir versjonert, er det også lurt å ha en .gitignore-fil i depotet der du legger til for eksempel .DS_Store eller andre filer du ikke vil laste opp. Stow ignorerer allerede .git av seg selv, men Git vet ingenting om .stow-local-ignoreDerfor tjener de to filene forskjellige formål og utfyller hverandre godt.

Den daglige rutinen er veldig tydelig: Du kloner dotfiles-repositoriet ditt til en ny maskin, installerer Stow, kjører «stow» eller «stow pakke1 pakke2…», og du har det replikerte miljøet ditt.Hvis du senere endrer Neovim-konfigurasjonen eller .zshrc-filen din, commit og pusher du, og på de andre maskinene er en enkel git pull etterfulgt av stow nok til å oppdatere lenker hvis du har lagt til nye filer eller pakker.