Une introduction à Bash pour les développeurs WordPress

De temps en temps, je finis par installer un logiciel via Composer ou qui place certains de ses fichiers binaires dans des répertoires autres que les endroits habituels où macOS s’attend à les trouver.

Autrement dit, si vous exécutez une application depuis Terminal ou qu’une application avec une interface graphique s’attend à se trouver à un certain emplacement sur le disque, elle s’attendra probablement à ce qu’elle se trouve à l’un des cinq endroits suivants :

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

Mais, comme je l’ai dit, avec le temps, nous finissons par installer des choses à l’aide d’outils tiers, ou nous finissons par installer des choses qui placent des fichiers binaires en dehors de l’un de ces répertoires.

Exemple : que se passe-t-il si vous souhaitez installer WP-CLI globalement ? Ou que se passe-t-il si vous souhaitez utiliser une version de MySQL livrée avec MAMP?

Dans ces cas, ces fichiers binaires ne seront inclus dans aucun des répertoires susmentionnés. Lorsque cela se produit, vous devez modifier votre profil. Si vous ne l’avez jamais fait, cela peut être intimidant. Et cela peut devenir désordonné si vous ne le faites pas méthodiquement au fil du temps.

Voici donc une introduction sur Bash pour les développeurs WordPress pour savoir ce qu’est votre bash_profile et comment gérer les logiciels tiers avec.

Bash pour les développeurs WordPress

Avant d’entrer dans la définition des chemins, pour d’autres logiciels et autres, il est important de noter que vous n’avez peut-être pas de bash_profile. Autrement dit, si vous utilisez un terminal, vous pouvez utiliser un type de shell différent, et si tel est le cas, vous êtes déjà bien en avance sur ce message.

Si, d’autre part, vous utilisez le shell du terminal sans modification fourni avec macOS. Mais d’abord, qu’est-ce qu’une coquille?

En informatique, un shell est une interface utilisateur permettant d’accéder aux services d’un système d’exploitation. En général, les shells du système d’exploitation utilisent une interface de ligne de commande (CLI) ou une interface utilisateur graphique (GUI), selon le rôle d’un ordinateur et une opération particulière.

Et si vous utilisez Terminal sans modifications, vous utilisez probablement Bash.

Enfin, tous les paramètres à chaque fois que vous lancez Terminal sont stockés dans le fichier de profil approprié du shell. Dans ce cas, tout est stocké dans .bash_profile.

Pour que tout soit configuré exactement comme nous en avons besoin, nous devons apporter quelques modifications (ou même l’initialiser) pour faire avancer les choses.

Notez  qu’après chaque modification apportée à .bash_profile, vous voudrez peut-être exécuter :

$ source ~/.bash_profile

Ainsi, toutes les nouvelles modifications introduites sont chargées pour votre session de terminal actuelle.

Le profil initial

Chaque fois que je configure mon profil initial, il a toujours le même aspect. C’est-à-dire qu’il comprend les cinq répertoires que j’ai énumérés ci-dessus :

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

Vous remarquerez cependant à la fin de la  variable PATH qu’il y a quelque chose qui ressemble à une autre variable. Plus précisément, je parle de $PATH. Et il est important de comprendre cela car cela a un impact sur la façon dont les programmes sont trouvés dans le terminal.

Qu’est-ce que $PATH ?

Tout d’abord, pensez que c’était un moyen pour le shell ou pour le système d’exploitation de rechercher des binaires. Donc, si vous avez défini les cinq chemins ci-dessus, le système d’exploitation va rechercher dans ces répertoires certains fichiers binaires.

Pour l’essayer, lancez le terminal et tapez :

$ which clear

Et cela vous montrera où il trouve l’  exécutable clear sur votre système (où clear efface simplement l’écran du terminal 🙂).

Ensuite, notez que $PATH  est défini à la fin de la chaîne dans l’exemple ci-dessus. Au fur et à mesure que vous modifiez votre profil, vous aimerez travailler avec lui. En bref, il définit l’ordre dans lequel les répertoires doivent être recherchés.

Donc, dans l’essentiel ci-dessus, le terminal va rechercher un binaire correspondant à ce que vous cherchez à exécuter en commençant par /usr/bin et en terminant par /usr/local/bin.

Que signifie "exporter" ?

Si vous n’utilisez pas Bash, je ne peux pas commenter l’équivalent, mais dans le contexte de Bash, l’exportation est un moyen d’attribuer explicitement la valeur à la variable PATH définie dans l’essentiel ci-dessus.

Autrement dit, en programmation, nous avons l’habitude de créer une variable et de lui attribuer une valeur. Ceci est similaire à cela. Cependant, nous sommes un peu plus explicites. En termes simples, nous définissons une variable sur le côté gauche à la valeur sur le côté droit. Et ceci est défini à l’aide de l’exportation.

Donc, si vous voulez voir ce  que contient $PATH, tapez ceci dans votre terminal :

$ echo $PATH

Ensuite, vous verriez la valeur des cinq chemins définis jusqu’à présent.

Au fil du temps, cependant, nous voulons naturellement ajouter plus à cela.

Forfaits Compositeur

J’ai parlé de l’installation de Composer et de la façon d’installer des packages en l’utilisant dans les publications précédentes à l’échelle mondiale. Mais disons que pour les besoins de la discussion, nous voulons installer WP-CLI, puis l’ajouter de manière à ce qu’il soit accessible via le terminal n’importe où sur notre système. Et tout cela peut être fait en utilisant les informations de profil ci-dessus.

En supposant que vous ayez installé composer et que votre composer.json ressemble à ceci (avec quelques autres choses, mais ignorez-les pour l’instant):

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

Et vous avez exécuté :

$ composer update

Ensuite, WP-CLI a été installé. Mais lorsque vous essayez de l’exécuter depuis le terminal en dehors de son répertoire d’installation, cela ne fonctionne pas. Alors qu’est-ce qui donne ?

Le chemin vers les fichiers binaires installés via composer n’est pas défini dans notre .bash_profile. Pour résoudre ce problème, ajoutez une nouvelle ligne à .bash_profile mais assurez-vous de ne pas redéfinir quelque chose qui existe déjà.

C’est-à-dire que PATH existe, alors nous pouvons simplement définir $PATH à la fin de notre nouvelle ligne et y ajouter notre répertoire Composer. De cette façon, nous ne dupliquons pas les répertoires ou les valeurs dans la variable chaque fois que nous les exportons et nous définissons la priorité des répertoires recherchés.

Par exemple :

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

export PATH

Ensuite, lorsque vous essayez d’exécuter wp depuis n’importe où dans la ligne de commande, cela devrait fonctionner et vous devriez pouvoir taper :

$ which wp

Et voyez qu’il vient du répertoire composer/vendor/bin. Oh – et notez que $HOME est une variable qui fait référence au répertoire personnel de l’utilisateur actuel. Cela peut être modifié, mais cela sort du cadre de cet article.

Logiciel MAMP

À ce stade, la version de PHP, MySQL ou des langages et outils que vous choisissez d’utiliser vont changer. J’ai fourni différents articles autour de MAMP (1, 2, 3 ), c’est pourquoi je choisis d’utiliser un exemple.

Plus précisément, je souhaite utiliser la version MAMP de PHP et MySQL – et non celle fournie avec le système. Mais, à ce stade, vous pouvez exécuter :

$ which php

Et:

$ which mysql

Et voyez qu’ils proviennent tous les deux des répertoires système. Cela doit être modifié afin que notre accès en ligne de commande utilise la même version du logiciel que notre application utilise.

Pour ce faire, nous pouvons ajouter les lignes suivantes à notre .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

Il y a cependant quelque chose à importer ici: j’ai placé le répertoire binaire PHP de MAMP avant les valeurs de $PATH. C’est parce que je veux que le système regarde d’abord ici (pas dans les répertoires système).

Il y a un deuxième défi, cependant. MAMP est livré avec plusieurs versions différentes de PHP et les chances que nous voulions utiliser la même version à chaque fois sont minces. Nous avons donc besoin d’un moyen d’utiliser la version sélectionnée dans MAMP, n’est-ce pas ?

Une façon de faire est d’utiliser un alias.

Qu’en est-il des alias ?

Vous pouvez considérer les alias comme un raccourci – c’est un moyen rapide d’exécuter une commande ou un programme particulier sans avoir à saisir un nom complet pour un programme.

Dans le cas de MAMP et PHP, il existe certaines versions de PHP que nous pourrions utiliser. Au moment d’écrire ces lignes, j’ai :

• 5.4.45
• 5.5.38
• 5.6.28
• 7.0.13
• 7.1.0

Tous disponibles sur mon système. Il est peu probable que je veuille tous les utiliser (ni les avoir tous dans mon $PATH ), mais il se peut que je veuille exécuter une version précédente de PHP pour tester quelque chose en particulier.

Alors, comment pouvons-nous faire cela? Nous pouvons utiliser des alias. Et si vous accédez à /Applications/MAMP/bin/php , vous devriez voir toutes les versions de PHP incluses avec votre version de MAMP.

Nous allons maintenant configurer des alias pour chacun d’entre eux :

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

Et nous pouvons exécuter chacun d’eux indépendamment de l’autre dans le terminal en exécutant une commande comme :

$ php54 -v

Cela devrait vous montrer quelle version de PHP est exécutée en fonction de l’alias que vous avez défini dans .bash_profile.

Et enfin, notez dans l’essentiel final que vous verrez une ligne qui a été ajoutée à .bash_profile :

source ~/.profile

Ceci est fait automatiquement par le système spécifiquement lorsque vous commencez à travailler avec un shell interactif. Vous pouvez le supprimer, mais il sera à nouveau ajouté en haut du fichier, alors ne vous inquiétez pas.

Et, pour référence, la version finale de mon .bash_profile ressemble à ceci :

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

Vous verrez que j’ai également ajouté des lignes pour MySQL et MySQLAdmin juste au-dessus de la ligne définissant les alias (bien que la vôtre soit probablement différente).

Quoi qu’il en soit, il s’agit d’une idée générale, bien que la vôtre soit susceptible d’être différente.

Bash plus avancé

Il y a des gens qui sont beaucoup plus avancés en Bash que moi (et même parcourir d’autres sites autour de ce que certaines personnes ont fait peut être impressionnant).

Mais si vous êtes un développeur WordPress avec peu ou pas de connaissance de Bash, des outils de ligne de commande, de la définition de chemins, etc., alors c’est quelque chose qui devrait être une référence de travail et un bon point de départ.