Od czasu do czasu instaluję oprogramowanie przez Composer lub umieszczam niektóre z jego plików binarnych w katalogach innych niż zwykłe miejsca, w których macOS spodziewa się je znaleźć.
Oznacza to, że jeśli uruchamiasz aplikację z poziomu Terminala lub aplikacja z graficznym interfejsem użytkownika spodziewa się, że znajduje się w określonej lokalizacji na dysku, prawdopodobnie będzie się tego spodziewać w jednym z pięciu miejsc:
- /usr/bin
- /kosz
- /usr/sbin
- /sbin
- /usr/local/bin
Ale, jak powiedziałem, z czasem instalujemy rzeczy za pomocą narzędzi innych firm lub instalujemy rzeczy, które umieszczają pliki binarne poza jednym z tych katalogów.
Przykład: co się stanie, jeśli chcesz zainstalować WP-CLI globalnie? A co, jeśli chcesz użyć wersji MySQL, która jest dostarczana z MAMP?
W takich przypadkach te pliki binarne nie będą zawarte w żadnym z wyżej wymienionych katalogów. Kiedy tak się stanie, musisz zmodyfikować swój profil. Jeśli nigdy tego nie robiłeś, może to być trudne. I może być bałagan, jeśli nie robisz tego metodycznie z biegiem czasu.
Oto elementarz Bash dla programistów WordPress na temat tego, czym jest Twój profil bash i jak nim zarządzać oprogramowaniem innych firm.
Bash dla programistów WordPress
Zanim zaczniesz ustawiać ścieżki dla innego oprogramowania i tym podobnych, ważne jest, aby pamiętać, że możesz nie mieć bash_profile. Oznacza to, że jeśli używasz terminala, możesz użyć innego typu powłoki, a jeśli tak jest, jesteś już daleko przed tym postem.
Jeśli z drugiej strony używasz powłoki terminala bez zmian, która jest dostarczana z macOS. Ale najpierw, czym jest muszla?
W informatyce powłoka jest interfejsem użytkownika umożliwiającym dostęp do usług systemu operacyjnego. Ogólnie powłoki systemu operacyjnego używają interfejsu wiersza polecenia (CLI) lub graficznego interfejsu użytkownika (GUI), w zależności od roli komputera i konkretnej operacji.
A jeśli używasz Terminala bez modyfikacji, prawdopodobnie używasz Bash.
Wreszcie, wszystkie ustawienia dla każdego uruchomienia Terminala są przechowywane w odpowiednim pliku profilu powłoki. W takim przypadku wszystko jest przechowywane w .bash_profile.
Aby wszystko było skonfigurowane dokładnie tak, jak tego potrzebujemy, musimy wprowadzić pewne zmiany (lub nawet je zainicjować), aby wszystko działało.
Zauważ , że po każdej zmianie dokonanej w .bash_profile możesz chcieć uruchomić:
$ source ~/.bash_profileTak więc wszystkie nowe zmiany, które zostały wprowadzone, są ładowane dla bieżącej sesji terminala.
Profil początkowy
Za każdym razem, gdy konfiguruję swój początkowy profil, zawsze wygląda tak samo. Oznacza to, że zawiera pięć katalogów, które wymieniłem powyżej :
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$PATH"
export PATHZauważysz jednak na końcu zmiennej PATH, że jest coś, co wygląda jak inna zmienna. W szczególności mówię o $PATH. I ważne jest, aby to zrozumieć, ponieważ wpływa to na sposób znajdowania programów w terminalu.
Co to jest $PATH?
Po pierwsze, pomyśl, że był to sposób na wyszukiwanie plików binarnych przez powłokę lub system operacyjny. Więc jeśli masz wszystkie pięć powyższych ścieżek, system operacyjny będzie szukał w tych katalogach określonych plików binarnych.
Aby to wypróbować, uruchom terminal i wpisz:
$ which clearA to pokaże ci, gdzie znajduje się czysty plik wykonywalny w twoim systemie (gdzie clear po prostu czyści ekran terminala 🙂).
Następnie zauważ, że $PATH jest zdefiniowana na końcu ciągu w powyższym przykładzie. Gdy zmodyfikujesz swój profil, będziesz chciał z nim pracować. W skrócie określa kolejność przeszukiwania katalogów.
Tak więc w powyższym skrócie Terminal będzie szukał pliku binarnego pasującego do tego, co chcesz wykonać, zaczynając od /usr/bin i kończąc na /usr/local/bin.
Co oznacza „eksport"?
Jeśli nie używasz Basha, nie mogę komentować odpowiednika, ale w kontekście Basha export to sposób na jawne przypisanie wartości do zmiennej PATH zdefiniowanej w powyższym opisie.
Oznacza to, że w programowaniu używamy do tworzenia zmiennej i przypisywania jej wartości. To jest podobne do tego. Jednak jesteśmy nieco bardziej jednoznaczni. Mówiąc najprościej, ustawiamy zmienną po lewej stronie na wartość po prawej stronie. A to ustawia się za pomocą eksportu.
Więc jeśli chcesz zobaczyć, co zawiera $PATH, wpisz to do swojego terminala:
$ echo $PATHWtedy zobaczysz wartość pięciu dotychczas zdefiniowanych ścieżek.
Jednak z biegiem czasu naturalnie chcemy dodać do tego więcej.
Pakiety kompozytorskie
Mówiłem o instalacji Composera i jak instalować pakiety za jego pomocą w poprzednich wpisach globalnie. Załóżmy jednak, że ze względu na argument, chcemy zainstalować WP-CLI, a następnie dodać go tak, aby można było uzyskać do niego dostęp za pośrednictwem terminala w dowolnym miejscu naszego systemu. A wszystko to można zrobić, korzystając z powyższych informacji profilowych.
Zakładając, że masz zainstalowanego kompozytora, a twój composer.json wygląda tak (wraz z kilkoma innymi rzeczami, ale na razie je zignoruj):
{
"require": {
"squizlabs/php_codesniffer": "2.9.1",
"wp-cli/wp-cli": "~1.2.1",
"psy/psysh": "~0.8.6"
}
}
A ty biegałeś:
$ composer updateNastępnie zainstalowano WP-CLI. Ale kiedy próbujesz wykonać go z terminala poza jego katalogiem instalacyjnym, nie działa. Więc co daje?
Ścieżka do plików binarnych zainstalowanych przez composer nie jest ustawiona w naszym .bash_profile. Aby to naprawić, dodaj nową linię do .bash_profile, ale upewnij się, że nie przedefiniujesz czegoś, co już istnieje.
To znaczy, ponieważ PATH istnieje, możemy po prostu ustawić $PATH na końcu naszej nowej linii i dołączyć do niej nasz katalog Composer. W ten sposób nie powielamy katalogów ani wartości w zmiennej za każdym razem, gdy je eksportujemy i ustalamy priorytet, które katalogi są przeszukiwane.
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
PATH="$HOME/.composer/vendor/bin:$PATH"
export PATHNastępnie, gdy spróbujesz uruchomić wp z dowolnego miejsca w wierszu poleceń, powinno działać i powinieneś być w stanie wpisać:
$ which wpI zobacz, że pochodzi z katalogu composer/vendor/bin. Aha – i zauważ, że $HOME to zmienna, która odwołuje się do katalogu domowego bieżącego użytkownika. Można to zmienić, ale wykracza to poza zakres tego postu.
Oprogramowanie MAMP
W tym momencie zmieni się wersja PHP, MySQL lub innych języków i narzędzi, z których zdecydujesz się korzystać. Dodałem kilka różnych postów dotyczących MAMP (1, 2, 3 ), więc to właśnie wybieram jako przykład.
W szczególności chcę używać PHP i MySQL w wersji MAMP – a nie tego, co jest dostarczane z systemem. Ale w tym momencie możesz uruchomić:
$ which phpI:
$ which mysqlI zobacz, że oba pochodzą z katalogów systemowych. Należy to zmienić, aby nasz dostęp z wiersza poleceń korzystał z tej samej wersji oprogramowania, z której korzysta nasza aplikacja.
Aby to zrobić, możemy dodać następujące wiersze do naszego .bash_profile :
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
PATH="$PATH:$HOME/.composer/vendor/bin"
PATH="/Applications/MAMP/bin/php/php7.1.0/bin:$PATH"
export PATHJest tu jednak coś do zaimportowania: umieściłem katalog binarny PHP MAMP przed wartościami $PATH. Dzieje się tak, ponieważ chcę, aby system najpierw szukał tutaj (nie w katalogach systemowych).
Jest jednak drugie wyzwanie. MAMP jest dostarczany z kilkoma różnymi wersjami PHP i szanse na to, że za każdym razem będziemy używać tej samej wersji są niewielkie. Potrzebujemy więc sposobu na użycie dowolnej wersji wybranej w MAMP, prawda?
Jednym ze sposobów na to jest użycie aliasu.
A co z aliasami?
Możesz myśleć o aliasach jako o skrócie — to szybki sposób na wykonanie określonego polecenia lub programu bez konieczności wpisywania w pełni kwalifikowanej nazwy do programu.
W przypadku MAMP i PHP istnieje kilka wersji PHP, których możemy używać. W chwili pisania tego tekstu mam:
- 5.4.45
- 5.5.38
- 5.6.28
- 7.0.13
- 7.1.0
Wszystko dostępne w moim systemie. Prawdopodobnie nie będę chciał ich wszystkich używać (ani mieć ich wszystkich w mojej $PATH ), ale może być szansa, że zechcę wykonać poprzednią wersję PHP, aby coś przetestować.
Jak więc możemy to zrobić? Możemy używać aliasów. A jeśli przejdziesz do /Applications/MAMP/bin/php , powinieneś zobaczyć wszystkie wersje PHP, które są dołączone do Twojej wersji MAMP.
Teraz skonfigurujemy aliasy dla każdego z nich:
## Aliases to old versions of PHP.
alias php54="/Applications/MAMP/bin/php/php5.4.45/bin/php"
alias php55="/Applications/MAMP/bin/php/php5.5.38/bin/php"
alias php56="/Applications/MAMP/bin/php/php5.6.28/bin/php"
alias php70="/Applications/MAMP/bin/php/php7.0.13/bin/php"I możemy uruchomić każdy z nich niezależnie od drugiego w terminalu, uruchamiając polecenie takie jak:
$ php54 -vPowinno to pokazać, która wersja PHP jest wykonywana na podstawie aliasu zdefiniowanego w .bash_profile.
I na koniec zauważ, że w końcowym skrócie zobaczysz linię, która została dodana do .bash_profile :
source ~/.profileOdbywa się to automatycznie przez system, zwłaszcza gdy zaczynasz pracę z interaktywną powłoką. Możesz go usunąć, ale zostanie ponownie dodany na górze pliku, więc nie przejmuj się.
I dla porównania ostateczna wersja mojego .bash_profile wygląda tak :
source ~/.profile
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin" # The standard system binaries
PATH="$HOME/.composer/vendor/bin:$PATH" # Composer binaries
PATH="/Applications/MAMP/bin/php/php7.1.0/bin:$PATH" # MAMP's PHP7 loaded first
PATH="/Applications/MAMP/Library/bin:$PATH" # MAMP's MySQL loaded first
## Aliases to old versions of PHP.
alias php54="/Applications/MAMP/bin/php/php5.4.45/bin/php"
alias php55="/Applications/MAMP/bin/php/php5.5.38/bin/php"
alias php56="/Applications/MAMP/bin/php/php5.6.28/bin/php"
alias php70="/Applications/MAMP/bin/php/php7.0.13/bin/php"
export PATHZobaczysz, że dodałem również wiersze dla MySQL i MySQLAdmin tuż nad wierszem definiującym aliasy (chociaż Twój prawdopodobnie będzie wyglądał inaczej).
Niezależnie od tego, jest to ogólny pomysł, chociaż Twój prawdopodobnie będzie wyglądał inaczej.
Bardziej zaawansowany bash
Są ludzie, którzy są znacznie bardziej zaawansowani w Bash niż ja (i nawet przeglądanie innych witryn wokół tego, co niektórzy zrobili, może być imponujące).
Ale jeśli jesteś programistą WordPress z niewielką lub żadną wiedzą o Bash, narzędziach wiersza poleceń, ustawianiu ścieżek itp., To jest coś, co powinno być roboczym punktem odniesienia i przyzwoitym punktem wyjścia.