3 sposoby na edycję ścieżki w wierszu poleceń
Zmienna środowiskowa PATH jest jedną z najważniejszych części korzystania z wiersza poleceń w Linuksie. W nowoczesnym systemie jest to często bardzo długi ciąg katalogów oddzielonych dwukropkami. Jeśli chcesz zmienić jakiś element na swojej ścieżce, może być irytujące wpisywanie i edytowanie wielu różnych nazw katalogów, aby wszystko było dobrze. Na szczęście istnieje kilka sposobów, aby to ułatwić. To samo odnosi się do każdej zmiennej środowiskowej i większość narzędzi, które ci pokażę, będzie działać dla każdej z nich.
Przegląd
Jak większość rzeczy w Linuksie, istnieje wiele sposobów, aby osiągnąć swój cel. Nawet jeśli powiedziałem, że są trzy sposoby, aby to zrobić, istnieje prawdopodobnie nieskończona liczba sposobów, a oto jeden, którego nie zaliczę do tych trzech: Użyj rozszerzenia.
Jednakże działa to tylko wtedy, gdy chcesz dodać coś do początku lub końca zmiennej. Na przykład, powiedzmy, że chcesz dodać ~/foo do PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
To proste, ale nie pomaga, jeśli chcesz usunąć lub zmienić coś w zmiennej. Nie pomoże też, jeśli chcesz zmienić kolejność istniejących katalogów.
Metoda 1: Najtrudniejszy sposób
Zakładając, że znajdujesz się w terminalu GUI, prawdopodobnie masz sposób na wycinanie i wklejanie tekstu. Może się więc wydawać, że łatwo jest napisać:
echo $PATH
Wtedy możesz podnieść ten tekst i w nowym wierszu poleceń wpisać PATH=" i wkleić resztę tekstu. Wprowadź swoje zmiany, zamknij cytat i naciśnij Enter. Możesz myśleć, że to nie jest zbyt wiele ulepszeń, jeśli potrzebujesz edytować istniejący tekst, ale okazuje się, że jeśli naciśniesz CONTROL+X, CONTROL+E w bashu, otrzymasz ładne okno edytora, gdzie możesz edytować swoje polecenie. Będzie to działać z każdym poleceniem i jest bardzo przydatne, gdy wyciągasz z historii długi wiersz poleceń, który musisz poprawić.
Skąd bash wie, jakiego edytora użyć? Zmienna środowiskowa EDITOR. Jeśli nie podoba Ci się edytor, który jest domyślnie przywoływany, zmień swój plik startowy (np. .bashrc), aby ustawić tę zmienną:
EDITOR=nano
To jest dobre, ale możemy zrobić to lepiej. W końcu ta metoda wymaga wyświetlenia zmiennej, ręcznego wpisania, a następnie skopiowania i wklejenia.
Metoda 2: envedit/pathedit
Na GitHubie znajdziesz skrypty dla envedit i pathedit. Są to proste skrypty, które możesz umieścić w swoim systemie w miejscu, w którym można je znaleźć (na przykład, /usr/local/bin). Jeśli chcesz, aby były znalezione na ścieżce, powinieneś uczynić je wykonywalnymi (chmod 755).
Problem polega na tym, że wszelkie zmiany dokonane przez skrypt w środowisku nie są zachowywane po jego zakończeniu (zobacz sekcję Czym jest środowisko?, poniżej). W rezultacie, aby te pliki działały, musisz je uźródłowić. Skrypt pathedit wyedytuje PATH w twoim ulubionym edytorze, podczas gdy envedit wymaga zmiennej nazwy i wykona to samo zadanie:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Trochę irytujące jest pamiętanie o podawaniu źródła przez cały czas, więc skrypty mają specjalną cechę. Jeśli użyjesz ich raz w swoim .bashrc i podasz argument alias, skrypty ustawią alias do siebie tak, że po prostu wpisanie pathedit lub envedit spowoduje, że źródło się pojawi:
. pathedit alias # now just typing pathedit will work
Jak zwykle, skrypt używa $EDITOR aby wiedzieć jakiego edytora użyć. Jeśli chcesz mieć specjalny edytor tylko do tego celu, ustaw $PATHEDIT_EDITOR lub $ENVEDIT_EDITOR i zastąpi on zwykłe ustawienia. Jeśli to nie jest ustawione, skrypt szuka $EDITOR i $VISUAL przed domyślnym ustawieniem na vi.
Metoda 3: envedit2/pathedit2
Trzecia metoda jest również na tej samej stronie GitHub. Działanie jest dokładnie takie samo jak w metodzie 2. To znaczy, nadal umieszczasz pliki gdzieś i wywołujesz je z argumentem alias, aby je skonfigurować. Jednak te skrypty nie używają twojego edytora tekstu. Zamiast tego, ładują one bufor wiersza poleceń bash z odpowiednim łańcuchem do edycji. Jest to bardzo podobne do pierwszej metody, z wyjątkiem tego, że kroki są zautomatyzowane za ciebie.
Zauważ, że kiedy uruchamiasz którykolwiek z nich, ustawiają one alias dla envedit lub pathedit, więc nie będziesz używał 2 do ich użycia, z wyjątkiem sytuacji, gdy je ustawisz. Oznacza to również, że ostatni, który ustawisz „wygrywa”. Nie możesz ustawić obu naraz, chyba że wykonasz jakieś operacje na skryptach lub ustawisz własne aliasy.
Gdy uruchomisz któryś z tych skryptów, możesz zobaczyć dziwny znak ucieczki pojawiający się przed znakiem zachęty. To jest raport stanu, który wyzwala napełnianie bufora. Jest on nieszkodliwy i jeśli ci przeszkadza, po prostu naciśnij CONTROL+L, aby przerysować ekran.
There’s Your Three
Jeśli chcesz używać tylko tych skryptów, skończyłeś. Mam nadzieję, że uznasz je za przydatne. Jeśli nie interesuje cię, jak i dlaczego to wszystko działa, możesz przestać tutaj. Ale jeśli chcesz wiedzieć więcej o tym, dlaczego te skrypty są aliasowane i jak działa środowisko, czytaj dalej.
Co to jest środowisko?
Możesz myśleć o środowisku jako o małej bazie danych, która jest przekazywana do każdego programu. Na przykład, prawdopodobnie masz zmienną środowiskową o nazwie EDITOR, która jest zwykle ustawiona na coś takiego jak vi, emacs lub nano. Gdy program musi wywołać edytor tekstu, dowie się, którego edytora lubisz używać, czytając tę zmienną środowiskową.
Gdy program A uruchamia inny program (B), program potomny dostaje kopię środowiska, chociaż program A może dokonać w nim zmian przed uruchomieniem B. Jednak wszelkie zmiany dokonane przez B obowiązują tylko dla B i wszystkich programów, które uruchamia.
Praktycznie oznacza to, że nic, co zrobisz w uruchomionym programie, nie będzie miało wpływu na żaden inny program, który nie został uruchomiony z tego programu. Jest to prawdziwy problem w skryptach powłoki. Na przykład, załóżmy, że chciałeś napisać skrypt, który dodał ~/foo na koniec PATH. To nie zadziała:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
Problem polega na tym, że skrypt będzie wykonywał się we własnej kopii basha. Porządnie zmieni zmienną PATH, a następnie zakończy pracę, powodując zniknięcie nowej kopii PATH. Oczywiście, zmiana ta obowiązywałaby dla każdej innej części skryptu. Aby to zadziałało, musiałbyś source skryptu (i wtedy nie potrzebuje on linii #!, choć nie zaszkodzi ją zostawić). Załóżmy, że nazwa powyższego skryptu to foopath. Mógłbyś powiedzieć:
source ./foopath
# or the same thing:
. ./foopath
Tak właśnie działają niektóre z wymienionych skryptów, przez pozyskiwanie źródeł do powłoki mogą one zmienić bieżące środowisko powłoki.
To wszystko, naprawdę… z wyjątkiem
Jeśli dotarłeś tak daleko, gratuluję. Mam nadzieję, że znajdziesz te narzędzia przydatne i pamiętaj, aby zgłaszać błędy na GitHub.
Runda bonusowa
Wcześniej powiedziałem, że ręczne wycinanie i wklejanie może być najtrudniejszym sposobem. Jednakże, jest jeszcze jeden sposób, aby to zrobić. Jeśli masz /etc/inputrc lub ~/.inputrc skonfigurowane poprawnie, możesz wpisać (ale nie naciskaj Enter):
PATH=$PATH
Następnie naciśnij Alt+Control+E, a powłoka rozszerzy zmienną $PATH za ciebie. Jednakże, jeśli spróbujesz:
PATH="$PATH"
zobaczysz, że rozszerzenie jej spowoduje utratę cudzysłowów. Musisz więc zrobić to, co niezręczne:
PATH=\"$PATH\"
, a następnie nacisnąć Alt+Control+E. Dane wyjściowe z bind -P mogą ci powiedzieć, czy funkcja shell-expand-line jest związana z czymkolwiek.