$PATH er en af de tavse manipulatorer i baggrunden på din Linux-computer. Det påvirker stille og roligt din brugeroplevelse, men der er ikke noget lyssky ved det. Vi forklarer, hvad det gør, og hvordan du kan justere det.
Indholdsfortegnelse
Hvad er $PATH på Linux, og hvordan virker det?
Når du skriver en kommando i et terminalvindue og trykker på Enter, starter du en hel del aktivitet, før din kommando overhovedet bliver udført.
Bash er standardskallen på de fleste Linux-distributioner. Den fortolker den tekstlinje, du har indtastet, og identificerer kommandonavnene blandet med parametrene, rør, omdirigeringer, og hvad der ellers er der. Den lokaliserer derefter de eksekverbare binære filer for disse kommandoer og starter dem med de parametre, du har angivet.
Det første skridt, som skallen tager for at finde den eksekverbare, er at identificere, om en binær er involveret. Hvis kommandoen du bruger er i selve skallen (a “skal indbygget”) ingen yderligere søgning er påkrævet.
Indbyggede skal er de nemmeste at finde, fordi de er integreret i skallen. Det er som at have dem i et værktøjsbælte – de er altid med dig.
Hvis du har brug for et af dine andre værktøjer, skal du dog gå og rode i værkstedet for at finde det. Er det på dit arbejdsbord eller en vægophæng? Det er, hvad miljøvariablen $PATH gør. Den indeholder en liste over steder, som skallen søger, og den rækkefølge, de vil blive søgt i.
Hvis du vil se, om en kommando er en indbygget skal, et alias, en funktion eller en selvstændig binær mv /work/unfile, kan du bruge type-kommandoen som vist nedenfor:
type clear
type cd
Dette fortæller os, at clear er en binær fil, og den første, der findes i stien, er placeret på /usr/bin. Du har muligvis mere end én version af clear installeret på din computer, men det er denne, som shellen vil forsøge at bruge.
Ikke overraskende er cd en indbygget skal.
Viser din $PATH
Det er nemt at se, hvad der er på din vej. Bare skriv følgende for at bruge echo-kommandoen og udskriv værdien holdt i $PATH-variablen:
echo $PATH
Outputtet er en liste med kolon (:) separerede filsystemplaceringer. Skallen søger fra venstre mod højre gennem stien og tjekker hver filsystemplacering for en matchende eksekverbar til at udføre din kommando.
Vi kan vælge os gennem listen for at se filsystemplaceringerne, der vil blive søgt efter, og den rækkefølge, de vil blive søgt i:
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/beholder
/usr/spil
/usr/local/spil
/snap/bin
Noget, der måske ikke umiddelbart er indlysende, er, at søgningen ikke starter i den aktuelle arbejdsmappe. Den arbejder sig snarere gennem de listede mapper og kun de listede mapper.
Hvis den aktuelle arbejdsmappe ikke er i din sti, vil den ikke blive søgt. Desuden, hvis du har kommandoer gemt i mapper, der ikke er i stien, finder skallen dem ikke.
For at demonstrere dette lavede vi et lille program kaldet rf. Når den udføres, udskriver rf navnet på den mappe, hvorfra den blev startet i terminalvinduet. Det er placeret i /usr/local/bin. Vi har også en nyere version i mappen /dave/work.
Vi skriver følgende hvilken kommando for at vise os, hvilken version af vores program skallen vil finde og bruge:
which rf
Skallen rapporterer, at den version, den fandt, er den i mappen, der er i stien.
Vi skriver følgende for at tænde for det:
rf
Version 1.0 af rf kører og bekræfter, at vores forventninger var korrekte. Den version, der blev fundet og udført, er placeret i /usr/local/bin.
For at køre en anden version af rf på denne computer, skal vi bruge stien til den eksekverbare på kommandolinjen, som vist nedenfor:
./work/rf
Nu hvor vi har fortalt skallen, hvor den skal finde den version af rf, vi vil køre, bruger den version 1.1. Hvis vi foretrækker denne version, kan vi kopiere den ind i mappen /usr/local/bin og overskrive den gamle.
Lad os sige, at vi er ved at udvikle en ny version af rf. Vi bliver nødt til at køre det ofte, mens vi udvikler og tester det, men vi ønsker ikke at kopiere en uudgivet udviklingsindbygning ind i live-miljøet.
Eller måske har vi downloadet en ny version af rf og ønsker at udføre nogle verifikationstest på den, før vi gør den offentlig tilgængelig.
Hvis vi tilføjer vores arbejdsmappe til stien, får vi shellen til at finde vores version. Og denne ændring vil kun påvirke os – andre vil stadig bruge versionen af rf i /usr/local/bin .
Tilføjelse af en mappe til din $PATH
Du kan bruge eksportkommandoen til tilføje en mappe til $PATH. Biblioteket er derefter inkluderet i listen over filsystemplaceringer, som shellen søger. Når shellen finder en matchende eksekverbar, stopper den med at søge, så du vil sikre dig, at den søger i din mappe først, før /usr/local/bin.
Dette er nemt at gøre. For vores eksempel skriver vi følgende for at tilføje vores bibliotek til starten af stien, så det er den første placering, der søges efter:
export PATH=/home/dave/work:$PATH
Denne kommando indstiller $PATH til at være lig med den mappe, vi tilføjer, /home/dave/work, og derefter hele den aktuelle sti.
Den første PATH har intet dollartegn ($). Vi indstiller værdien for PATH. Den endelige $PATH har et dollartegn, fordi vi refererer til indholdet, der er gemt i PATH-variablen. Bemærk også kolonet (:) mellem den nye mappe og $PATH-variabelnavnet.
Lad os se, hvordan stien ser ud nu:
echo $PATH
Vores /home/dave/work-mappe tilføjes til starten af stien. Det kolon, vi gav, adskiller det resten af stien.
Vi skriver følgende for at bekræfte, at vores version af rf er den første, der blev fundet:
which rf
Beviset i buddingen kører rf, som vist nedenfor:
rf
Skallen finder version 1.1 og udfører den fra /home/dave/work.
For at tilføje vores mappe til slutningen af stien, flytter vi den bare til slutningen af kommandoen, sådan:
export PATH=$PATH:/home/dave/work
Gør ændringerne permanente
Som Beth Brooke-Marciniak sagde: “Succes er fint, men succes er flygtigt.” I det øjeblik du lukker terminalvinduet, er alle ændringer, du har foretaget i $PATH, væk. For at gøre dem permanente skal du lægge din eksportkommando i en konfigurationsfil.
Når du sætter eksportkommandoen i din .bashrc-fil, sætter den stien hver gang du åbner et terminalvindue. I modsætning til SSH sessioner, som du skal logge på, kaldes disse “interaktive” sessioner.
Tidligere ville du sætte eksportkommandoen i din .profile-fil for at indstille stien til log-in-terminalsessioner.
Men vi fandt ud af, at hvis vi satte eksportkommandoen i enten .bashrc- eller .profile-filerne, satte den stien korrekt til både interaktive og login-terminalsessioner. Din oplevelse kan være anderledes. For at håndtere alle eventualiteter viser vi dig, hvordan du gør det i begge filer.
Brug følgende kommando i din /home-mappe til at redigere .bashrc-filen:
gedit .bashrc
Gedit-editoren åbner med .bashrc-filen indlæst.
Rul til bunden af filen, og tilføj derefter følgende eksportkommando, vi brugte tidligere:
export PATH=/home/dave/work:$PATH
Gem filen. Dernæst skal du enten lukke og genåbne terminalvinduet eller bruge dot-kommandoen til at læse .bashrc-filen som følger:
. .bashrc
Indtast derefter følgende ekkokommando for at kontrollere stien:
echo $PATH
Dette tilføjer mappen /home/dave/work til starten af stien.
Processen for at tilføje kommandoen til .profile-filen er den samme. Skriv følgende kommando:
gedit .profile
Gedit-editoren starter med .profile-filen indlæst.
Tilføj eksportkommandoen til bunden af filen, og gem den derefter. Lukning og åbning af et nyt terminalvindue er utilstrækkeligt til at tvinge .profile-filen til at blive genlæst. For at de nye indstillinger træder i kraft, skal du logge ud og ind igen eller bruge dot-kommandoen som vist nedenfor:
. .profile
Sætter vejen for alle
For at indstille stien til alle, der bruger systemet, kan du redigere filen /etc/profile.
Du skal bruge sudo, som følger:
sudo gedit /etc/profile
Når gedit-editoren starter, skal du tilføje eksportkommandoen til bunden af filen.
Gem og luk filen. Ændringerne træder i kraft for andre, næste gang de logger på.
En note om sikkerhed
Sørg for, at du ikke ved et uheld tilføjer et indledende kolon “:” til stien, som vist nedenfor.
Hvis du gør det, vil dette søge i den aktuelle mappe først, hvilket introducerer en sikkerhedsrisiko. Lad os sige, at du har downloadet en arkivfil og pakket den ud i en mappe. Du ser på filerne og ser en anden zippet fil. Du kalder unzip igen for at udtrække det arkiv.
Hvis det første arkiv indeholdt en eksekverbar fil kaldet unzip, som var en ondsindet eksekverbar fil, ville du ved et uheld starte denne i stedet for den rigtige unzip eksekverbare. Dette ville ske, fordi skallen ville se i den aktuelle mappe først.
Så vær altid forsigtig, når du skriver dine eksportkommandoer. Brug echo $PATH til at gennemgå dem og sikre dig, at de er, som du vil have dem.