3 moduri de a vă edita calea în linia de comandă
Variabila de mediu PATH este una dintre cele mai importante părți ale utilizării liniei de comandă pe Linux. Pe un sistem modern, aceasta este adesea un șir foarte lung de directoare, toate separate prin două puncte de suspensie. Dacă doriți să schimbați un element din calea dvs. de acces, poate fi enervant să trebuiască să tastați și să editați o mulțime de nume de directoare diferite și să le obțineți pe toate corect. Din fericire, există câteva modalități de a face acest lucru mai ușor. Același lucru este valabil pentru orice variabilă de mediu și majoritatea instrumentelor pe care vi le voi arăta vor funcționa pentru oricare dintre ele.
Vizualizare generală
Ca majoritatea lucrurilor în Linux, există mai multe moduri de a vă atinge obiectivul. Chiar dacă am spus că sunt trei moduri de a face acest lucru, există probabil un număr infinit de moduri, iar aici este unul pe care nu îl voi număra ca făcând parte din cele trei: Folosiți expansiunea.
Cu toate acestea, acest lucru funcționează numai dacă doriți să adăugați ceva la începutul sau la sfârșitul unei variabile. De exemplu, să spunem că vreți să adăugați ~/foo la PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Este ușor, dar nu vă ajută dacă vreți să ștergeți sau să modificați ceva din variabilă. De asemenea, nu vă ajută dacă doriți să schimbați ordinea unor directoare existente.
Metoda 1: Cea mai grea metodă
Să presupunem că vă aflați în interiorul unui terminal GUI, probabil că aveți o modalitate de a tăia și lipi text. Astfel, ar putea părea ușor să scrieți:
echo $PATH
Apoi puteți prelua textul și, pe o nouă linie de comandă, să introduceți PATH=" și să lipiți restul textului. Efectuați modificările, închideți citatul și apăsați Enter. S-ar putea să credeți că nu este o îmbunătățire prea mare dacă aveți nevoie să editați textul existent, dar se pare că dacă apăsați CONTROL+X, CONTROL+E în bash, veți obține o fereastră frumoasă de editor în care puteți edita comanda. Acest lucru va funcționa cu orice comandă și este foarte util atunci când scoateți din istoric o linie de comandă lungă pe care trebuie să o reparați.
Cum știe bash ce editor să folosească? Variabila de mediu EDITOR. Dacă nu vă place editorul pe care îl aduce în mod implicit, modificați fișierul de pornire (de exemplu, .bashrc) pentru a seta variabila:
EDITOR=nano
Este bine, dar putem face mai bine. La urma urmei, această metodă vă cere să afișați variabila, să tastați manual și apoi să faceți un copy and paste.
Metoda 2: envedit/pathedit
Pe GitHub, veți găsi scripturi pentru envedit și pathedit. Acestea sunt scripturi simple pe care le puteți pune pe sistemul dvs. undeva unde pot fi găsite (de exemplu, /usr/local/bin). Dacă doriți ca ele să fie găsite pe calea de acces, ar trebui să le faceți executabile (chmod 755).
Problema este că orice modificare pe care un script o face în mediu nu se păstrează după ce scriptul respectiv iese (a se vedea secțiunea Ce este mediul?, de mai jos). Ca urmare, trebuie să creați sursa acestor fișiere pentru a le face să funcționeze. Scriptul pathedit va edita PATH în editorul dumneavoastră preferat, în timp ce envedit necesită un nume de variabilă și va face aceeași treabă:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Un fel de enervant să trebuiască să vă amintiți să le originați tot timpul, așa că scripturile au o caracteristică specială. Dacă le dați sursa o singură dată în .bashrc și treceți argumentul alias, scripturile își vor crea un alias pentru ele însele, astfel încât doar tastând pathedit sau envedit se va întâmpla sursa:
. pathedit alias # now just typing pathedit will work
Ca de obicei, scriptul folosește $EDITOR pentru a ști ce editor să folosească. Dacă doriți un editor special doar pentru acest scop, setați $PATHEDIT_EDITOR sau $ENVEDIT_EDITOR și acesta va anula setările obișnuite. Dacă acestea nu sunt setate, scriptul caută $EDITOR și $VISUAL înainte de a folosi implicit vi.
Metoda 3: envedit2/pathedit2
Cea de-a treia metodă se află, de asemenea, pe aceeași pagină GitHub. Operațiunea este la fel ca și metoda 2. Adică, puneți în continuare fișierele undeva și le apelați cu argumentul alias pentru a le configura. Cu toate acestea, aceste scripturi nu folosesc editorul de text. În schimb, ele încarcă bufferul liniei de comandă bash cu șirul corect de editat. Aceasta este foarte asemănătoare cu prima metodă, cu excepția faptului că pașii sunt automatizați pentru dumneavoastră.
Rețineți că atunci când rulați oricare dintre acestea, ele stabilesc un alias pentru envedit sau pathedit, astfel încât nu veți folosi cele 2 pentru a le utiliza decât atunci când le configurați. Asta înseamnă, de asemenea, că ultimul pe care l-ați configurat „câștigă”. Nu le puteți configura pe amândouă în același timp decât dacă faceți o operație cu scripturi sau vă configurați propriile aliasuri.
Când rulați oricare dintre aceste scripturi, este posibil să vedeți un caracter de scăpare ciudat care apare înaintea promptului. Acesta este raportul de stare care declanșează umplerea bufferului. Este inofensiv și, dacă vă deranjează, apăsați CONTROL+L pentru a redesena ecranul.
Aici sunt cele trei
Dacă doriți să folosiți doar aceste scripturi, ați terminat. Sper că le găsiți utile. Dacă nu vă interesează cum și de ce funcționează toate acestea, vă puteți opri aici. Dar dacă doriți să aflați mai multe despre motivul pentru care aceste scripturi sunt aliasate și despre cum funcționează mediul, citiți mai departe.
Ce este mediul?
Vă puteți gândi la mediu ca la o mică bază de date care este transmisă fiecărui program. De exemplu, probabil că aveți o variabilă de mediu numită EDITOR care este de obicei setată la ceva de genul vi, emacs sau nano. Când un program trebuie să apeleze la un editor de text, va afla ce editor vă place să folosiți citind acea variabilă de mediu.
Când un program A pornește un alt program (B), programul copil primește o copie a mediului, deși programul A ar putea face modificări la acesta înainte de a-l lansa pe B. Cu toate acestea, orice modificări pe care le face B sunt în vigoare doar pentru B și pentru orice program pe care îl pornește.
Practic, acest lucru înseamnă că nimic din ceea ce faceți într-un program lansat nu va avea impact asupra oricărui alt program care nu a pornit din acel program. Aceasta este o problemă reală în scripturile shell. De exemplu, să presupunem că doriți să scrieți un script care să adauge ~/foo la sfârșitul lui PATH. Acest lucru nu va funcționa:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
Problema este că scriptul se va executa în propria sa copie de bash. Acesta va modifica conștiincios variabila PATH și apoi va ieși, ceea ce va face ca noua copie a lui PATH să dispară. Bineînțeles, modificarea ar fi în vigoare pentru orice altă parte a scriptului. Pentru ca acest lucru să funcționeze, ar trebui să source scriptul (și atunci nu mai are nevoie de linia #!, deși nu strică să o lăsați). Să presupunem că numele scriptului de mai sus era foopath. Ați putea spune:
source ./foopath
# or the same thing:
. ./foopath
Aceasta este modul în care funcționează unele dintre scripturile menționate, prin accesarea sursei în shell, ele pot schimba mediul curent al shell-ului.
Asta e tot, serios… Cu excepția
Dacă ați ajuns până aici, felicitări. Sper că veți găsi aceste instrumente utile și nu uitați să raportați bug-uri pe GitHub.
Bonus Round
Am spus mai devreme, că tăierea și lipirea manuală ar putea fi cea mai grea cale. Cu toate acestea, există o altă modalitate de a face acest lucru. Dacă aveți /etc/inputrc sau ~/.inputrc configurate corect, puteți tasta (dar nu apăsați Enter):
PATH=$PATH
Apoi apăsați Alt+Control+E și shell-ul va extinde variabila $PATH pentru dumneavoastră. Cu toate acestea, dacă încercați:
PATH="$PATH"
Veți vedea că extinderea va pierde ghilimelele. Trebuie să procedați în mod ciudat:
PATH=\"$PATH\"
Apoi apăsați Alt+Control+E. Ieșirea din bind -P vă poate spune dacă funcția shell-expand-line este legată de ceva.
.