Utiliser la même version de PHP en CGI et en CLI sous Mac OS X

Sous Mac OS X Snow Leopard, from the bundle, PHP, tout comme Apache, MySQL, SQLite, est installé.

Il y a peu, au cours d’un développement sur un projet Symfony, j’ai utilisé une task nettoyant partiellement un cache APC. Quelle ne fut pas ma surprise en voyant apparaitre un message d’erreur me disant que APC n’était pas installé ! Mais qu’osait me dire mon terminal ? ôO J’utilise pourtant APC en continue dans mon projet ?

Après quelques minutes de recherche, je me suis donc rendu compte que les versions CGI (Apache) et CLI (Command Line Interface) sont différentes.

Avec mes maigres connaissances d’administration système, j’avoue que je n’ai pas saisi l’utilité de cette configuration, et comme je personnalise régulièrement ma configuration PHP, je ne voulais pas passer mon temps à maintenir une double version de PHP.

Dans un 1er temps, j’ai simplement voulu faire en sorte que le php.ini chargé soit le même, mais il s’avère que la version CLI cherchait les extensions dans son répertoire d’installation, et il aurait donc fallu dupliquer les librairies entre les installations.

Après cette petite mise en place, venons en au fait

Utiliser une unique version de PHP pour les modes CGI et CLI

Pour commencer, par défaut, voici où se trouvent les différentes versions de PHP :

CGI : /ect/lib/php/

CLI : /opt/local/lib/php

La solution est très simple : supprimer la version CLI et la remplacer par un lien symbolique vers la version CGI

# Se rendre dans le répertoire du PHP CLI
$ cd /opt/local/lib/
# Sauvegarder l'ancienne version
$ sudo tar -czf php.tgz php/
# Créer le lien symbolique vers la version CGI
$ sudo ln -s /etc/lib/php/ php

Pour vérifier que tout fonctionne, il faut commencer par appeler la commande php depuis la console

$ php -v
# PHP 5.3.2 (cli) (built: Oct  5 2010 23:50:50)
# Copyright (c) 1997-2010 The PHP Group
# Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
#    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

A partir de maintenant, toute modification apportée au PHP CGI sera immédiatement reportée dans la version CGI

Comme je le disais plus haut, je suis loin de maitriser l’administration système, ma solution peut donc paraitre aberrante à un vrai administrateur système. Toutefois, comme je ne demande qu’à apprendre, je suis ouvert à toute critique, tant qu’elle est constructive ;)

  • Thierry

    Beaucoup de foin pour pas grand chose en somme ^^

    Sinon y’a l’option macports, que j’utilise et qui me permet de gérer simplement mes outils de développement de la même manière qu’un gestionnaire de paquet sur linux. :)

  • Mikael Randy

    Comme je le laisse plus que transparaitre dans l’article, mes connaissances d’administration système ne sont pas très avancées.
    Toutefois, pour une personne qui a le même soucis que moi, et c’est la raisonde l’introduction de l’article, cette solution permet de ne pas passer le double de temps à maintenir ses outils …

    Bref, pour moi, même avec macports, il faut bien gérer 2 php.ini sans ma solution, et ce n’était pas acceptable

  • Thierry

    Ben justement si, quand tu installes php avec macports tu n’as qu’un seul php.ini à gérer.

    Je te conseille d’y jeter un oeil, parce qu’il y a pleins d’outils du monde linux pour le développement qui ne sont pas par défaut sur osx, et mine de rien avoir un gestionnaire de paquets à la aptitude c’est bien pratique.

  • http://www.peiniau.com Thomas Peiniau

    Bonjour.

    La solution que tu proposes est déconseillée. Il est préférable de gérer les alias et les chemins dans leurs fichiers de configuration respectifs. Cela évite de se retrouver avec des liens symboliques dans tous les sens, ce qui peut vite devenir ingérable, et qui n’est pas pérenne lorsque tu change de système.

    Je te renvoie à ces articles si ça t’intéresse :

    http://forum.symfony-project.org/viewtopic.php?t=32941
    http://stackoverflow.com/questions/902946/about-bash-profile-bashrc-and-where-should-alias-be-written-in