En Primer i Bash för WordPress-utvecklare

Då och då slutar jag med att installera en mjukvara via Composer eller som placerar några av dess binärer i andra kataloger än de vanliga platser som macOS förväntar sig att hitta dem.

Det vill säga, om du kör en app inifrån Terminal eller om en applikation med ett grafiskt användargränssnitt förväntar sig att finnas på en viss plats på disken, kommer den troligen att förvänta sig det på en av fem platser:

1. /usr/bin
2. /bin
3. /usr/sbin
4. /sbin
5. /usr/local/bin

Men, som jag sa, med tiden kommer vi att installera saker med hjälp av tredjepartsverktyg, eller så kommer vi att installera saker som placerar binärfiler utanför en av dessa kataloger.

Exempel: Vad händer om du vill installera WP-CLI globalt? Eller vad händer om du vill använda en version av MySQL som levereras med MAMP?

I dessa fall kommer dessa binärer inte att inkluderas i någon av de ovan nämnda katalogerna. När det händer måste du ändra din profil. Om du aldrig har gjort det kan det vara skrämmande. Och det kan bli rörigt om du inte gör det metodiskt med tiden.

Så här är en primer om Bash för WordPress-utvecklare för vad din bash_profile är och hur man hanterar programvara från tredje part med den.

Bash för WordPress-utvecklare

Innan du börjar ställa in sökvägar, för annan programvara och liknande, är det viktigt att notera att du kanske inte har en bash_profile. Det vill säga, om du använder en terminal kan du använda en annan typ av skal, och om så är fallet är du redan långt före detta inlägg.

Om du å andra sidan använder terminalskalet utan ändringar som levereras med macOS. Men först, vad är ett skal?

Inom datorer är ett skal ett användargränssnitt för åtkomst till ett operativsystems tjänster. I allmänhet använder operativsystemskal antingen ett kommandoradsgränssnitt (CLI) eller ett grafiskt användargränssnitt (GUI), beroende på en dators roll och speciella funktion.

Och om du använder Terminal utan ändringar, så använder du troligen Bash.

Slutligen lagras alla inställningar för varje gång du startar Terminal i skalets relevanta profilfil. I det här fallet lagras allt i .bash_profile.

För att få allt inrättat precis som vi behöver det måste vi göra några ändringar (eller till och med initiera det) för att få saker att gå.

Observera  att efter varje ändring som görs i .bash_profile kanske du vill köra:

$ source ~/.bash_profile

Så alla nya ändringar som introduceras laddas för din nuvarande terminalsession.

Den ursprungliga profilen

När jag ställer in min första profil ser den alltid likadan ut. Det vill säga, det inkluderar de fem katalogerna som jag har listat ovan :

PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$PATH"
export PATH

Du kommer dock att märka i slutet av PATH -variabeln att det finns något som ser ut som en annan variabel. Specifikt pratar jag om $PATH. Och det är viktigt att förstå detta eftersom det påverkar hur program hittas i terminalen.

Vad är $PATH?

Tänk först på att det var ett sätt för skalet eller för operativsystemet att söka efter binärer. Så om du har alla fem av vägarna ovan definierade, kommer operativsystemet att leta i dessa kataloger efter vissa binärer.

För att prova det, starta terminal och skriv:

$ which clear

Och detta kommer att visa dig var den hittar den klara körbara filen på ditt system (där clear bara torkar terminalskärmen 🙂).

Lägg sedan märke till att $PATH  definieras i slutet av strängen i exemplet ovan. När du ändrar din profil kommer du att gilla att arbeta med den. Kort sagt definierar den i vilken ordning kataloger ska sökas.

Så i sammanfattningen ovan kommer terminalen att leta efter en binär som matchar det du vill köra med början i /usr/bin och slutar i /usr/local/bin.

Vad betyder "exportera"?

Om du inte använder Bash kan jag inte kommentera motsvarande, men inom ramen för Bash är export ett sätt att explicit tilldela värdet till PATH- variabeln som definieras i ovanstående sammanfattning.

Det vill säga, i programmering använder vi för att skapa en variabel och tilldela den ett värde. Detta liknar det. Men vi är lite mer tydliga. Enkelt uttryckt sätter vi en variabel på vänster sida till värdet på höger sida. Och detta ställs in med export.

Så om du vill se vad $PATH innehåller, skriv in detta i din terminal:

$ echo $PATH

Då skulle du se värdet av de fem vägar som har definierats hittills.

Men med tiden vill vi naturligtvis lägga till mer till detta.

Kompositörspaket

Jag har pratat om att installera Composer och hur man installerar paket med det i tidigare inlägg globalt. Men låt oss säga att vi för argumentets skull vill installera WP-CLI och sedan lägga till det så att det kan nås via terminalen var som helst på vårt system. Och allt detta kan göras med hjälp av profilinformationen ovan.

Förutsatt att du har installerat composer och din composer.json ser ut så här (tillsammans med några andra saker, men ignorera dem för tillfället):

{
    "require": {
        "squizlabs/php_codesniffer": "2.9.1",
        "wp-cli/wp-cli": "~1.2.1",
        "psy/psysh": "~0.8.6"
    }
}

Och du har sprungit:

$ composer update

Sedan har WP-CLI installerats. Men när du försöker köra det från terminalen utanför dess installationskatalog, fungerar det inte. Så vad ger?

Sökvägen till binärfilerna installerade via composer är inte inställda i vår .bash_profile. För att fixa detta, lägg till en ny rad i .bash_profile men se till att du inte omdefinierar något som redan finns.

Det är eftersom PATH finns, då kan vi bara ställa in $PATH i slutet av vår nya rad och lägga vår Composer-katalog till den. På så sätt duplicerar vi inte kataloger eller värden i variabeln när vi exporterar dem och vi ställer in prioritet för vilka kataloger som ska sökas i.

Till exempel :

PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
PATH="$HOME/.composer/vendor/bin:$PATH"

export PATH

Sedan, när du försöker köra wp från var som helst på kommandoraden, bör det fungera, och du bör kunna skriva:

$ which wp

Och se att det kommer från katalogen composer/vendor/bin. Åh – och notera att $HOME är en variabel som refererar till den aktuella användarens hemkatalog. Detta kan ändras, men det ligger utanför ramen för detta inlägg.

MAMP programvara

Vid det här laget kommer versionen av PHP, MySQL eller vilka språk och verktyg du väljer att använda att ändras. Jag har tillhandahållit några olika inlägg kring MAMP (1, 2, 3 ), så det är vad jag väljer att använda ett exempel.

Specifikt vill jag använda MAMPs version av PHP och MySQL – inte vad som medföljer systemet. Men vid det här laget kan du köra:

$ which php

Och:

$ which mysql

Och se att de båda kommer från systemkataloger. Detta måste ändras så att vår kommandoradsåtkomst använder samma version av programvaran som vår applikation använder.

För att göra detta kan vi lägga till följande rader i vår .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 PATH

Det finns dock något att importera att notera här: Jag har placerat MAMPs binära PHP-katalog före värdena för $PATH. Det beror på att jag vill att systemet ska titta här först (inte i systemkatalogerna).

Men det finns en andra utmaning. MAMP levereras med flera olika versioner av PHP och oddsen att vi vill använda samma version varje gång är små. Så vi behöver ett sätt att använda vilken version som är vald i MAMP, eller hur?

Ett sätt att göra detta är att använda ett alias.

Hur är det med alias?

Du kan tänka på alias som en genväg – det är ett snabbt sätt att utföra ett visst kommando eller program utan att behöva skriva ett fullständigt kvalificerat namn på ett program.

När det gäller MAMP och PHP finns det några versioner av PHP som vi kan använda. När jag skriver detta har jag:

• 5.4.45
• 5.5.38
• 5.6.28
• 7.0.13
• 7.1.0

Allt tillgängligt på mitt system. Jag kommer sannolikt inte att vilja använda dem alla (inte heller alla i min $PATH ), men det kan finnas en chans att jag vill köra en tidigare version av PHP för att testa något speciellt.

Så hur kan vi göra det? Vi kan använda alias. Och om du navigerar till /Applications/MAMP/bin/php  bör du se alla versioner av PHP som ingår i din version av MAMP.

Nu ska vi ställa in alias för var och en av dessa:

## 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"

Och vi kan köra var och en av dem oberoende av den andra i terminalen genom att köra ett kommando som:

$ php54 -v

Detta bör visa dig vilken version av PHP som körs baserat på det alias du definierade i .bash_profile.

Och slutligen, notera i den sista sammanfattningen att du ser en rad som har lagts till i .bash_profile :

source ~/.profile

Detta görs automatiskt av systemet, speciellt när du börjar arbeta med ett interaktivt skal. Du kan ta bort den, men den kommer att läggas till högst upp i filen igen så svettas inte.

Och som referens, den slutliga versionen av min .bash_profile ser ut så här :

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 PATH

Du kommer att se att jag också har lagt till rader för MySQL och MySQLAdmin precis ovanför raden som definierar aliasen (även om dina sannolikt kommer att se annorlunda ut).

Oavsett vilket är detta en allmän idé även om din sannolikt kommer att se annorlunda ut.

Mer avancerad bash

Det finns människor som är mycket mer avancerade i Bash än jag är (och att till och med surfa på andra sidor runt vad vissa människor har gjort kan vara imponerande).

Men om du är en WordPress-utvecklare med liten eller ingen fungerande kunskap om Bash, kommandoradsverktyg, inställningsvägar och så vidare, så är detta något som borde vara en fungerande referens och en anständig utgångspunkt.