3 måder at redigere din sti på kommandolinjen
Miljøvariablen PATH er en af de vigtigste dele af brugen af kommandolinjen på Linux. På et moderne system er det ofte en meget lang streng af mapper, der alle er adskilt med kolon. Hvis du vil ændre et element i din sti, kan det være irriterende at skulle skrive og redigere en masse forskellige mappenavne for at få det hele til at passe. Heldigvis er der et par måder at gøre det nemmere på. Det samme gælder for alle miljøvariabler, og de fleste af de værktøjer, jeg vil vise dig, vil fungere for alle dem.
Overblik
Som de fleste ting i Linux er der mange måder at komme til dit mål på. Selv om jeg sagde, at der var tre måder at gøre det på, er der sandsynligvis uendeligt mange måder, og her er en, som jeg ikke vil tælle som en del af de tre: Brug ekspansion.
Dette virker dog kun, hvis du vil tilføje noget til starten eller slutningen af en variabel. Lad os f.eks. sige, at du vil tilføje ~/foo til PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Det er nemt, men det hjælper ikke, hvis du vil slette eller ændre noget i variablen. Det hjælper heller ikke, hvis du vil ændre rækkefølgen af nogle eksisterende mapper.
Metode 1: Den sværeste måde
Såfremt du befinder dig i en GUI-terminal, har du sandsynligvis en måde at klippe og indsætte tekst på. Så det kan virke let at skrive:
echo $PATH
Så kan du samle teksten op og på en ny kommandolinje indtaste PATH=" og indsætte resten af teksten. Foretag dine ændringer, luk citationstegnet, og tryk Enter. Du tænker måske, at det ikke er nogen stor forbedring, hvis du har brug for at redigere den eksisterende tekst, men det viser sig, at hvis du trykker CONTROL+X, CONTROL+E i bash, får du et fint editorvindue, hvor du kan redigere din kommando. Dette virker med alle kommandoer og er meget nyttigt, når du trækker en lang kommandolinje ud af historikken, som du skal rette.
Hvordan ved bash, hvilken editor der skal bruges? Miljøvariablen EDITOR. Hvis du ikke kan lide den editor, som den bringer op som standard, kan du ændre din opstartsfil (f.eks. .bashrc), så variablen sættes:
EDITOR=nano
Det er godt, men vi kan gøre det bedre. Denne metode kræver trods alt, at du skal vise variablen, skrive noget manuelt og derefter lave en kopiering og indsættelse.
Metode 2: envedit/pathedit
På GitHub finder du scripts til envedit og pathedit. Det er enkle scripts, som du kan lægge på dit system et sted, hvor de kan findes (f.eks. /usr/local/bin). Hvis du vil have dem fundet på stien, skal du gøre dem eksekverbare (chmod 755).
Problemet er, at alle ændringer, som et script foretager i miljøet, ikke bevares, efter at scriptet afsluttes (se afsnittet Hvad er miljøet? nedenfor). Som følge heraf er du nødt til at kildekode disse filer for at få dem til at fungere. Pathedit-scriptet redigerer PATH i din foretrukne editor, mens envedit kræver et variablenavn og gør det samme arbejde:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Det er ret irriterende at skulle huske at kildekode dem hele tiden, så derfor har scriptsene en særlig funktion. Hvis du kilde dem en gang i din .bashrc og giver argumentet alias, vil scriptsene oprette et alias til sig selv, så det blot at skrive pathedit eller envedit vil få kilden til at ske:
. pathedit alias # now just typing pathedit will work
Som sædvanlig bruger scriptet $EDITOR til at vide hvilken editor der skal bruges. Hvis du ønsker en speciel editor kun til dette formål, skal du indstille $PATHEDIT_EDITOR eller $ENVEDIT_EDITOR, og det vil tilsidesætte de sædvanlige indstillinger. Hvis dette ikke er indstillet, leder scriptet efter $EDITOR og $VISUAL, før det som standard vælger vi.
Metode 3: envedit2/pathedit2
Den tredje metode er også på den samme GitHub-side. Operationen er nøjagtig den samme som metode 2. Det vil sige, at du stadig lægger filerne et sted og kalder dem med alias-argumentet for at opsætte dem. Disse scripts bruger dog ikke din teksteditor. I stedet indlæser de bash-kommandolinjebufferen med den korrekte streng, der skal redigeres. Dette ligner meget den første metode, bortset fra at trinene er automatiseret for dig.
Bemærk, at når du kører en af disse, opretter de et alias for envedit eller pathedit, så du bruger ikke de 2 til at bruge dem, bortset fra når du opretter dem. Det betyder også, at den sidste, du sætter op, “vinder”. Du kan ikke opsætte begge på samme tid, medmindre du foretager nogle scriptoperationer eller opstiller dine egne aliasser.
Når du kører et af disse scripts, kan du se et mærkeligt escape-tegn blive vist før din prompt. Det er den statusrapport, der udløser fyldning af bufferen. Det er harmløst, og hvis det generer dig, skal du blot trykke CONTROL+L for at tegne skærmen igen.
Der er dine tre
Hvis du kun ønsker at bruge disse scripts, er du færdig. Jeg håber, at du finder dem nyttige. Hvis du er ligeglad med hvordan og hvorfor alt dette virker, kan du stoppe her. Men hvis du vil vide mere om, hvorfor disse scripts er aliased, og hvordan miljøet fungerer, så læs videre.
Hvad er miljøet?
Du kan tænke på miljøet som en lille database, der overdrages til hvert program. For eksempel har du sikkert en miljøvariabel kaldet EDITOR, som normalt er indstillet til noget som vi, emacs eller nano. Når et program skal kalde en teksteditor, finder det ud af, hvilken editor du kan lide at bruge, ved at læse denne miljøvariabel.
Når et program A starter et andet program (B), får det underordnede program en kopi af miljøet, selv om program A kan foretage ændringer i det, før det starter B. Alle ændringer, som B foretager, gælder dog kun for B og alle programmer, som det starter.
Praktisk set betyder det, at intet af det, du gør i et startet program, vil påvirke andre programmer, der ikke er startet fra programmet. Dette er et reelt problem i shell-scripts. Lad os for eksempel antage, at du ville skrive et script, der tilføjede ~/foo til slutningen af PATH. Dette vil ikke fungere:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
Problemet er, at scriptet vil blive udført i sin egen kopi af bash. Det vil pligtskyldigt ændre PATH-variablen og derefter afslutte, hvilket får den nye kopi af PATH til at forsvinde. Ændringen ville naturligvis være gældende for enhver anden del af scriptet. For at få dette til at virke skal du source scriptet (og så har det ikke brug for #! linjen, selv om det ikke skader at lade den stå). Lad os antage, at navnet på ovenstående script var foopath. Du kunne sige:
source ./foopath
# or the same thing:
. ./foopath
Det er sådan nogle af de nævnte scripts fungerer, ved at sourcing ind i shell’en kan de ændre shell’ens aktuelle miljø.
Det er alt, virkelig… undtagen
Hvis du er nået så langt, tillykke. Jeg håber, at du finder disse værktøjer nyttige, og sørg for at rapportere fejl på GitHub.
Bonusrunde
Jeg sagde tidligere, at manuelt klippe og indsætte måske er den sværeste måde. Der er dog en anden måde at gøre dette på. Hvis du har /etc/inputrc eller ~/.inputrc sat korrekt op, kan du skrive (men ikke trykke på Enter):
PATH=$PATH
Tryk derefter på Alt+Control+E, og shell’en udvider variablen $PATH for dig. Hvis du derimod prøver:
PATH="$PATH"
Du vil se, at du mister dine anførselstegn ved at udvide den. Du er nødt til at gøre det besværlige:
PATH=\"$PATH\"
Derpå skal du trykke på Alt+Control+E. Udgangen fra bind -P kan fortælle dig, om funktionen shell-expand-line er bundet til noget.