Un Primer in Bash per gli sviluppatori di WordPress
Di tanto in tanto, finisco per installare un software tramite Composer o che inserisce alcuni dei suoi binari in directory diverse dai soliti posti in cui macOS si aspetta di trovarli.
Cioè, se stai eseguendo un’app da Terminale o se un’applicazione con una GUI si aspetta di trovarsi in una determinata posizione sul disco, è probabile che la si aspetterà in una delle cinque posizioni:
- /usr/bin
- /bidone
- /usr/sbin
- /sbin
- /usr/locale/bin
Ma, come ho detto, col tempo finiamo per installare cose usando strumenti di terze parti, o finiamo per installare cose che mettono i binari al di fuori di una di queste directory.
Caso in questione: cosa succede se si desidera installare WP-CLI a livello globale? O cosa succede se si desidera utilizzare una versione di MySQL fornita con MAMP?
In questi casi, quei binari non verranno inclusi in nessuna delle directory summenzionate. Quando ciò accade, devi modificare il tuo profilo. Se non l’hai mai fatto, può essere scoraggiante. E può diventare disordinato se non lo fai metodicamente nel tempo.
Quindi ecco un’introduzione su Bash per gli sviluppatori di WordPress per sapere qual è il tuo bash_profile e come gestire software di terze parti con esso.
Bash per gli sviluppatori di WordPress
Prima di entrare nell’impostazione dei percorsi, per altri software e simili, è importante notare che potresti non avere un bash_profile. Cioè, se usi un terminale, puoi usare un diverso tipo di shell e, in tal caso, sei già molto più avanti di questo post.
Se d’altra parte, utilizzi la shell del terminale senza modifiche fornita con macOS. Ma prima, cos’è una shell?
In informatica, una shell è un’interfaccia utente per l’accesso ai servizi di un sistema operativo. In generale, le shell del sistema operativo utilizzano un’interfaccia della riga di comando (CLI) o un’interfaccia utente grafica (GUI), a seconda del ruolo del computer e dell’operazione particolare.
E se stai usando Terminal senza modifiche, probabilmente stai usando Bash.
Infine, tutte le impostazioni per ogni volta che avvii Terminale sono memorizzate nel file di profilo pertinente della shell. In questo caso, tutto è archiviato in .bash_profile.
Per impostare tutto esattamente come ci serve, allora dobbiamo apportare alcune modifiche (o addirittura inizializzarlo) per far funzionare le cose.
Nota che dopo ogni modifica apportata a .bash_profile potresti voler eseguire:
$ source ~/.bash_profile
Quindi tutte le nuove modifiche introdotte vengono caricate per la sessione del terminale corrente.
Il profilo iniziale
Ogni volta che configuro il mio profilo iniziale, sembra sempre lo stesso. Cioè, include le cinque directory che ho elencato sopra :
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$PATH"
export PATH
Noterai alla fine della variabile PATH, tuttavia, che c’è qualcosa che assomiglia a un’altra variabile. In particolare, sto parlando di $PATH. Ed è importante capirlo perché influisce sul modo in cui i programmi vengono trovati all’interno del terminale.
Cos’è $PATH?
Innanzitutto, pensa che fosse un modo per la shell o per il sistema operativo di cercare i binari. Quindi, se hai tutti e cinque i percorsi sopra definiti, il sistema operativo cercherà in quelle directory determinati binari.
Per provarlo, avvia il terminale e digita:
$ which clear
E questo ti mostrerà dove trova l’ eseguibile clear sul tuo sistema (dove clear cancella semplicemente lo schermo del terminale 🙂).
Successivamente, nota che $PATH è definito alla fine della stringa nell’esempio precedente. Quando modifichi il tuo profilo, ti piacerà lavorarci. In breve, definisce l’ordine di ricerca nelle directory.
Quindi, nel succo sopra, il Terminale cercherà un binario che corrisponda a ciò che stai cercando di eseguire iniziando in /usr/bin e finendo in /usr/local/bin.
Cosa significa "Esportazione"?
Se non stai usando Bash, non posso commentare l’equivalente, ma nel contesto di Bash, l’esportazione è un modo per assegnare esplicitamente il valore alla variabile PATH definita nel gist sopra.
Cioè, nella programmazione stiamo usando per creare una variabile e assegnarle un valore. Questo è simile a quello. Tuttavia, siamo un po’ più espliciti. In poche parole, stiamo impostando una variabile sul lato sinistro sul valore sul lato destro. E questo viene impostato utilizzando l’esportazione.
Quindi, se vuoi vedere cosa contiene $PATH, digita questo nel tuo terminale:
$ echo $PATH
Quindi vedresti il valore dei cinque percorsi definiti finora.
Nel tempo, però, vogliamo naturalmente aggiungere altro a questo.
Pacchetti compositore
Ho parlato dell’installazione di Composer e di come installare i pacchetti usandolo nei post precedenti a livello globale. Ma diciamo che per ragioni di discussione vogliamo installare WP-CLI e quindi aggiungerlo in modo tale che sia possibile accedervi tramite il terminale in qualsiasi punto del nostro sistema. E tutto questo può essere fatto utilizzando le informazioni del profilo sopra.
Supponendo che tu abbia installato il compositore e che il tuo composer.json assomigli a questo (insieme ad alcune altre cose, ma per ora ignorale):
{
"require": {
"squizlabs/php_codesniffer": "2.9.1",
"wp-cli/wp-cli": "~1.2.1",
"psy/psysh": "~0.8.6"
}
}
E hai corso:
$ composer update
Quindi WP-CLI è stato installato. Ma quando provi ad eseguirlo dal terminale al di fuori della sua directory di installazione, non funziona. Allora cosa dà?
Il percorso dei binari installati tramite composer non è impostato nel nostro .bash_profile. Per risolvere questo problema, aggiungi una nuova riga a .bash_profile ma assicurati di non ridefinire qualcosa che già esiste.
Cioè, poiché PATH esiste, possiamo semplicemente impostare $PATH alla fine della nostra nuova riga e anteporre la nostra directory Composer ad essa. In questo modo, non duplichiamo directory o valori nella variabile ogni volta che li esportiamo e impostiamo la priorità di quali directory vengono cercate.
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
PATH="$HOME/.composer/vendor/bin:$PATH"
export PATH
Quindi, quando tenti di eseguire wp da qualsiasi punto della riga di comando, dovrebbe funzionare e dovresti essere in grado di digitare:
$ which wp
E guarda che proviene dalla directory composer/vendor/bin. Oh – e nota che $HOME è una variabile che fa riferimento alla home directory dell’utente corrente. Questo può essere modificato, ma non rientra nell’ambito di questo post.
Software MAMP
A questo punto, la versione di PHP, MySQL o qualsiasi lingua e strumento tu scelga di utilizzare cambierà. Ho fornito alcuni post diversi su MAMP (1, 2, 3 ), quindi è quello che sto scegliendo di usare un esempio.
In particolare, voglio utilizzare la versione MAMP di PHP e MySQL, non quella fornita con il sistema. Ma, a questo punto, puoi eseguire:
$ which php
E:
$ which mysql
E guarda che provengono entrambi da directory di sistema. Questo deve essere modificato in modo che il nostro accesso alla riga di comando utilizzi la stessa versione del software utilizzata dalla nostra applicazione.
Per fare ciò, possiamo aggiungere le seguenti righe al nostro .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
C’è qualcosa da importare da notare qui, però: ho posizionato la directory binaria PHP di MAMP prima dei valori di $PATH. Questo perché voglio che il sistema guardi prima qui (non nelle directory di sistema).
C’è una seconda sfida, però. MAMP viene fornito con diverse versioni di PHP e le probabilità che vogliamo utilizzare la stessa versione ogni volta sono scarse. Quindi abbiamo bisogno di un modo per usare qualunque versione sia selezionata in MAMP, giusto?
Un modo per farlo è usare un alias.
E gli alias?
Puoi pensare agli alias come a una scorciatoia: è un modo rapido per eseguire un comando o un programma particolare senza dover digitare un nome completo per un programma.
Nel caso di MAMP e PHP, ci sono alcune versioni di PHP che potremmo utilizzare. Al momento in cui scrivo, ho:
- 5.4.45
- 5.5.38
- 5.6.28
- 7.0.13
- 7.1.0
Tutto disponibile sul mio sistema. È probabile che non voglia usarli tutti (né averli tutti nel mio $PATH ), ma potrebbe esserci una possibilità in cui voglio eseguire una versione precedente di PHP per testare qualcosa in particolare.
Allora come possiamo farlo? Possiamo usare alias. E se accedi a /Applications/MAMP/bin/php dovresti vedere tutte le versioni di PHP incluse con la tua versione di MAMP.
Ora imposteremo gli alias per ciascuno di questi:
## 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"
E possiamo eseguirli ciascuno indipendentemente dall’altro nel terminale eseguendo un comando come:
$ php54 -v
Questo dovrebbe mostrarti quale versione di PHP viene eseguita in base all’alias che hai definito in .bash_profile.
E infine, nota nel succo finale che vedrai una riga che è stata aggiunta a .bash_profile :
source ~/.profile
Questo viene fatto automaticamente dal sistema in particolare quando inizi a lavorare con una shell interattiva. Puoi eliminarlo, ma verrà aggiunto di nuovo nella parte superiore del file, quindi non preoccuparti.
E, per riferimento, la versione finale del mio .bash_profile è simile a questa :
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
Vedrai che ho anche aggiunto righe per MySQL e MySQLAdmin appena sopra la riga che definisce gli alias (anche se è probabile che la tua abbia un aspetto diverso).
Indipendentemente da ciò, questa è un’idea generale anche se è probabile che la tua abbia un aspetto diverso.
Bash più avanzato
Ci sono persone che sono molto più avanzate di me in Bash (e anche navigare in altri siti su ciò che alcune persone hanno fatto può essere impressionante).
Ma se sei uno sviluppatore WordPress con poca o nessuna conoscenza di Bash, strumenti da riga di comando, impostazione di percorsi e così via, allora questo è qualcosa che dovrebbe essere un riferimento funzionante e un punto di partenza decente.