3 manieren om uw pad op de opdrachtregel te bewerken
De PATH omgevingsvariabele is een van de belangrijkste onderdelen van het gebruik van de opdrachtregel onder Linux. Op een modern systeem is het vaak een lange reeks van mappen, gescheiden door dubbele punten. Als je een item op je pad wilt veranderen, kan het vervelend zijn om een heleboel verschillende mapnamen te moeten typen en bewerken om het allemaal goed te krijgen. Gelukkig zijn er een paar manieren om het makkelijker te maken. Hetzelfde geldt voor elke omgevingsvariabele en de meeste hulpmiddelen die ik je zal laten zien, werken voor elk van hen.
Overzicht
Zoals de meeste dingen in Linux, zijn er vele manieren om je doel te bereiken. Hoewel ik zei dat er drie manieren waren om het te doen, zijn er waarschijnlijk een oneindig aantal manieren, en hier is er een die ik niet tot de drie zal rekenen: Gebruik uitbreiding.
Dit werkt echter alleen als je iets wilt toevoegen aan het begin of einde van een variabele. Stel bijvoorbeeld dat u ~/foo wilt toevoegen aan PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Dat is gemakkelijk, maar het helpt niet als u iets in de variabele wilt verwijderen of veranderen. Het helpt ook niet als je de volgorde van een aantal bestaande mappen wilt veranderen.
Methode 1: De moeilijkste manier
Aannemend dat je in een GUI terminal zit, heb je waarschijnlijk een manier om tekst te knippen en plakken. Dus het lijkt misschien makkelijk om te schrijven:
echo $PATH
Dan kunt u de tekst oppakken en, op een nieuwe commandoregel, PATH=" intikken en de rest van de tekst plakken. Maak uw wijzigingen, sluit het citaat, en druk op Enter. Je zou kunnen denken dat dat niet veel verbetering is als je de bestaande tekst moet bewerken, maar het blijkt dat als je op CONTROL+X, CONTROL+E drukt in bash, je een mooi editor venster krijgt waar je je commando kunt bewerken. Dit werkt met elk commando, en is erg handig als je een lange commandoregel uit de geschiedenis haalt die je moet aanpassen.
Hoe weet bash welke editor te gebruiken? De EDITOR omgevingsvariabele. Als je de editor die standaard verschijnt niet leuk vindt, verander dan je opstart bestand (b.v. .bashrc) om de variabele in te stellen:
EDITOR=nano
Dit is goed, maar we kunnen beter doen. Immers, deze methode vereist dat je de variabele weergeeft, wat handmatig typt, en dan kopieert en plakt.
Methode 2: envedit/pathedit
Op GitHub, zul je scripts vinden voor envedit en pathedit. Dit zijn eenvoudige scripts die je ergens op je systeem kunt zetten waar ze gevonden kunnen worden (bijvoorbeeld, /usr/local/bin). Als u wilt dat ze op het pad gevonden worden, moet u ze uitvoerbaar maken (chmod 755).
Het probleem is dat alle veranderingen die een script aanbrengt in de omgeving niet bewaard blijven nadat het script is afgesloten (zie de paragraaf Wat is de omgeving?, hieronder). Het resultaat is dat je deze bestanden moet source-en om ze te laten werken. Het pathedit script zal de PATH in uw favoriete editor bewerken, terwijl envedit een variabele naam nodig heeft en hetzelfde zal doen:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Het is vervelend om steeds te moeten onthouden om ze te sourceen, dus hebben de scripts een speciale eigenschap. Als je ze een keer source in je .bashrc en het argument alias doorgeeft, zullen de scripts een alias voor zichzelf opzetten zodat gewoon het typen van pathedit of envedit de source zal laten gebeuren:
. pathedit alias # now just typing pathedit will work
Zoals gebruikelijk gebruikt het script $EDITOR om te weten welke editor het moet gebruiken. Als u een speciale editor alleen voor dit doel wilt, stel dan $PATHEDIT_EDITOR of $ENVEDIT_EDITOR in en het zal de gebruikelijke instellingen opheffen. Als dit niet is ingesteld, zoekt het script naar $EDITOR en $VISUAL voordat het standaard naar vi gaat.
Methode 3: envedit2/pathedit2
De derde methode staat ook op dezelfde GitHub pagina. De werking is net hetzelfde als methode 2. Dat wil zeggen, je zet nog steeds de bestanden ergens neer en roept ze aan met het alias argument om ze in te stellen. Deze scripts gebruiken echter niet je teksteditor. In plaats daarvan laden ze de bash commandoregel buffer met de juiste string om te bewerken. Dit lijkt erg op de eerste methode, behalve dat de stappen voor jou geautomatiseerd zijn.
Merk op dat wanneer je een van deze scripts uitvoert, ze een alias opzetten voor envedit of pathedit, dus je zult de 2 niet gebruiken om ze te gebruiken, behalve wanneer je ze instelt. Dat betekent ook dat de laatste die je instelt “wint”. U kunt ze niet allebei tegelijk instellen, tenzij u script-chirurgie uitvoert of uw eigen aliassen instelt.
Wanneer u een van deze scripts uitvoert, kunt u een vreemd escape karakter voor uw prompt zien verschijnen. Dat is de statusmelding die het vullen van de buffer triggert. Het is onschuldig en als het je stoort, druk dan op CONTROL+L om het scherm opnieuw te tekenen.
Daar zijn je drie
Als je alleen deze scripts wilt gebruiken, ben je klaar. Ik hoop dat je ze nuttig vindt. Als je niet wilt weten hoe en waarom dit allemaal werkt, kun je hier stoppen. Maar als je meer wilt weten over waarom deze scripts aliased zijn en hoe de omgeving werkt, lees dan verder.
Wat is de omgeving?
Je kunt de omgeving zien als een kleine database die aan elk programma wordt doorgegeven. U hebt bijvoorbeeld waarschijnlijk een omgevingsvariabele genaamd EDITOR die meestal is ingesteld op iets als vi, emacs, of nano. Wanneer een programma een teksteditor moet oproepen, zal het uitvinden welke editor je wilt gebruiken door die omgevingsvariabele te lezen.
Wanneer een programma A een ander programma (B) start, krijgt het kind-programma een kopie van de omgeving, hoewel programma A er wijzigingen in kan aanbrengen voordat het B start. Alle wijzigingen die B aanbrengt zijn echter alleen van kracht voor B en alle programma’s die het start.
Praktisch betekent dit dat niets wat je doet in een gestart programma invloed zal hebben op elk ander programma dat niet vanuit het programma is gestart. Dit is een echt probleem in shell scripts. Stel bijvoorbeeld dat u een script wilt schrijven dat ~/foo toevoegt aan het eind van PATH. Dit zal niet werken:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
Het probleem is dat het script zal worden uitgevoerd in zijn eigen kopie van bash. Het zal plichtsgetrouw de variabele PATH veranderen en dan afsluiten, waardoor de nieuwe kopie van PATH verdwijnt. Natuurlijk zou de verandering van kracht blijven voor elk ander deel van het script. Om dit te laten werken, zou je het script moeten source (en dan heeft het de #! regel niet nodig, hoewel het geen kwaad kan om die te laten staan). Stel dat de naam van het bovenstaande script foopath was. Je zou kunnen zeggen:
source ./foopath
# or the same thing:
. ./foopath
Dit is hoe sommige van de genoemde scripts werken, door in de shell te sourcen kunnen ze de huidige omgeving van de shell veranderen.
Dat is alles, echt… behalve
Als je zover bent gekomen, gefeliciteerd. Ik hoop dat u deze hulpmiddelen nuttig vindt en vergeet niet om bugs op GitHub te melden.
Bonus Ronde
Ik zei al eerder, dat handmatig knippen en plakken misschien wel de moeilijkste manier is. Er is echter nog een andere manier om dit te doen. Als u /etc/inputrc of ~/.inputrc correct hebt ingesteld, kunt u typen (maar niet op Enter drukken):
PATH=$PATH
Daarna drukt u op Alt+Control+E en de shell zal de $PATH variabele voor u uitbreiden. Als je echter probeert:
PATH="$PATH"
, zul je zien dat bij het uitbreiden je aanhalingstekens verloren gaan. Je moet het lastige doen:
PATH=\"$PATH\"
Druk dan op Alt+Control+E. De uitvoer van bind -P kan u vertellen of de functie shell-expand-line aan iets gebonden is.