3 sätt att redigera din sökväg på kommandoraden
Miljövariabeln PATH är en av de viktigaste delarna när du använder kommandoraden i Linux. På ett modernt system är det ofta en mycket lång sträng av kataloger som alla är separerade med kolon. Om du vill ändra ett objekt i din sökväg kan det vara irriterande att behöva skriva och redigera en massa olika katalognamn för att få allt rätt. Som tur är finns det några sätt att göra det enklare. Samma sak gäller för alla miljövariabler och de flesta av verktygen som jag kommer att visa dig kommer att fungera för alla dessa.
Översikt
Som de flesta saker i Linux finns det många sätt att nå ditt mål. Även om jag sa att det fanns tre sätt att göra det på finns det förmodligen ett oändligt antal sätt, och här är ett som jag inte kommer att räkna som en del av de tre: Använd expansion.
Detta fungerar dock bara om du vill lägga till något i början eller slutet av en variabel. Säg till exempel att du vill lägga till ~/foo till PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Det är enkelt, men det hjälper inte om du vill ta bort eller ändra något i variabeln. Det hjälper inte heller om du vill ändra ordningen på några befintliga kataloger.
Metod 1: Det svåraste sättet
Antagen att du befinner dig i en GUI-terminal har du förmodligen ett sätt att klippa och klistra in text. Så det kan verka enkelt att skriva:
echo $PATH
Därefter kan du plocka upp texten och på en ny kommandorad skriva PATH=" och klistra in resten av texten. Gör dina ändringar, stäng citatet och tryck Enter. Du kanske tycker att det inte är någon större förbättring om du behöver redigera den befintliga texten, men det visar sig att om du trycker CONTROL+X, CONTROL+E i bash får du ett trevligt redigeringsfönster där du kan redigera ditt kommando. Detta fungerar med alla kommandon och är mycket användbart när du tar fram en lång kommandorad från historiken som du behöver rätta till.
Hur vet bash vilken editor som ska användas? Miljövariabeln EDITOR. Om du inte gillar redigeraren som visas som standard kan du ändra din startfil (t.ex. .bashrc) för att ställa in variabeln:
EDITOR=nano
Det här är bra, men vi kan göra det bättre. Den här metoden kräver trots allt att du visar variabeln, skriver manuellt och sedan kopierar och klistrar in.
Metod 2: envedit/pathedit
På GitHub hittar du skript för envedit och pathedit. Det är enkla skript som du kan lägga in på ditt system någonstans där de kan hittas (till exempel /usr/local/bin). Om du vill att de ska hittas på sökvägen bör du göra dem körbara (chmod 755).
Problemet är att alla ändringar som ett skript gör i miljön inte behålls när skriptet avslutas (se avsnittet Vad är miljön?, nedan). Som ett resultat av detta måste du källsortera dessa filer för att få dem att fungera. Skriptet pathedit redigerar PATH i din favoritredigerare medan envedit kräver ett variabelnamn och gör samma jobb:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Det är ganska irriterande att behöva komma ihåg att källsortera dem hela tiden, så skriptet har en speciell funktion. Om du källsorterar dem en gång i din .bashrc och lämnar argumentet alias kommer skriptet att skapa ett alias till sig självt så att det räcker att skriva pathedit eller envedit för att källsorteringen ska ske:
. pathedit alias # now just typing pathedit will work
Som vanligt använder skriptet $EDITOR för att veta vilken editor som ska användas. Om du vill ha en speciell editor endast för det här ändamålet kan du ställa in $PATHEDIT_EDITOR eller $ENVEDIT_EDITOR och det kommer att åsidosätta de vanliga inställningarna. Om detta inte är inställt letar skriptet efter $EDITOR och $VISUAL innan det väljer vi som standard.
Metod 3: envedit2/pathedit2
Den tredje metoden finns också på samma GitHub-sida. Operationen är precis densamma som för metod 2. Det vill säga att du fortfarande lägger filerna någonstans och anropar dem med argumentet alias för att ställa in dem. Dessa skript använder dock inte din textredigerare. Istället laddar de bash-kommandoradsbufferten med rätt sträng att redigera. Detta är mycket likt den första metoden förutom att stegen är automatiserade åt dig.
Bemärk att när du kör någon av dessa ställer de in ett alias för envedit eller pathedit, så du kommer inte att använda de 2 för att använda dem förutom när du ställer in dem. Det betyder också att den sista som du ställer in ”vinner”. Du kan inte sätta upp båda samtidigt om du inte gör någon skriptkirurgi eller sätter upp egna alias.
När du kör något av dessa skript kan du se ett konstigt escape-tecken före din prompt. Det är statusrapporten som utlöser fyllning av bufferten. Det är ofarligt och om det stör dig är det bara att trycka CONTROL+L för att rita om skärmen.
Det är dina tre
Om du bara vill använda dessa skript är du klar. Jag hoppas att du finner dem användbara. Om du inte bryr dig om hur och varför allt detta fungerar kan du sluta här. Men om du vill veta mer om varför dessa skript är aliaserade och hur miljön fungerar, läs vidare.
Vad är miljön?
Du kan tänka på miljön som en liten databas som skickas till varje program. Till exempel har du förmodligen en miljövariabel som heter EDITOR som vanligtvis är inställd på något som vi, emacs eller nano. När ett program behöver anropa en textredigerare får det reda på vilken redaktör du gillar att använda genom att läsa den miljövariabeln.
När ett program A startar ett annat program (B) får det underordnade programmet en kopia av miljön, även om program A skulle kunna göra ändringar i den innan det startar B. Alla ändringar som B gör gäller dock bara för B och alla program som det startar.
Praktiskt sett innebär det här att inget du gör i ett startat program påverkar något annat program som inte startades från programmet. Detta är ett verkligt problem i skalskript. Anta till exempel att du vill skriva ett skript som lägger till ~/foo i slutet av PATH. Detta kommer inte att fungera:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
Problemet är att skriptet kommer att köras i en egen kopia av bash. Det kommer pliktskyldigt att ändra variabeln PATH och sedan avsluta, vilket gör att den nya kopian av PATH försvinner. Naturligtvis skulle ändringen gälla för alla andra delar av skriptet. För att få detta att fungera måste du source skriptet (och då behöver det inte #! raden, även om det inte skadar att låta den vara kvar). Anta att namnet på ovanstående skript var foopath. Du skulle kunna säga:
source ./foopath
# or the same thing:
. ./foopath
Det är så här vissa av de nämnda skripten fungerar, genom att söka i skalet kan de ändra skalets aktuella miljö.
Det är allt, egentligen… utom
Om du kom så här långt, grattis. Jag hoppas att du finner verktygen användbara och se till att rapportera buggar på GitHub.
Bonusrunda
Jag sa tidigare att manuellt klippa och klistra in kan vara det svåraste sättet. Det finns dock ett annat sätt att göra detta på. Om du har /etc/inputrc eller ~/.inputrc korrekt inställt kan du skriva (men inte trycka på Enter):
PATH=$PATH
Därefter trycker du på Alt+Control+E så expanderar skalet variabeln $PATH åt dig. Om du däremot försöker:
PATH="$PATH"
Du kommer att se att om du expanderar den kommer du att förlora dina citationstecken. Du måste göra det besvärliga:
PATH=\"$PATH\"
Därefter trycker du på Alt+Control+E. Utdata från bind -P kan tala om för dig om funktionen shell-expand-line är bunden till något.