Este comando deshabilitará el módulo PHP5 Xdebug para CLI (y por lo tanto composer) :

sudo php5dismod -s cli xdebug

Elimina el xdebug.ini enlace simbólico de /etc/php5/cli/conf.d/

Esto fue sugerido en http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli /

Tenga en cuenta que para Ubuntu 16.04 probablemente necesite ejecutarlo de esta manera:

sudo phpdismod -s cli xdebug

No creo que haya una opción para configurar PHP para que pueda cargar diferentes configuraciones de acuerdo con el script de destino. Al menos, no sin duplicar .archivos ini...

Sin embargo, puede agregar estas opciones al ejecutar composer con php:

php -n -d extension=needed_ext.so composer.phar

-n le dirá a PHP que ignore cualquier php.ini. Esto evitará que xdebug se cargue para este mismo comando.

-d opciones le permite agregar cualquier opción que desee (por ejemplo, activar needed_ext.so). Usted puede utilizar múltiples opciones -d. Por supuesto, esto es opcional, es posible que no lo necesite.

Luego puede crear un alias, para volverlo azucarado.

Una solución típica (porque composer necesita json):

php -n -d extension=json.so composer.phar

Greg0ire > mi solución, basada en eso:

#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \

    grep --invert-match xdebug| \

    # remove problematic extensions
    egrep --invert-match 'mysql|wddx|pgsql'| \

    sed --expression 's/\(.*\)/ --define extension=\1/'| \

    # join everything together back in one big line
    tr --delete '\n'
)

# build the final command line
php --no-php-ini $options ~/bin/composer $*

alias composer=/path/to/bash/script.sh

Se ve feo (lo intenté y no pude hacer eso con xargs), pero funciona though Tuve que desactivar algunas extensiones, de lo contrario recibo las siguientes advertencias:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0

Creando un alias suprimirás eso composer xdebug mensaje de error.

Simplemente agregue esta línea a su ~/.bash_aliases dentro de su sistema y debería funcionar sin problemas.

alias composer="php -n /usr/local/bin/composer"

Vuelva a cargar el shell para que el nuevo alias composer esté disponible.

source ~/.bash_profile

USO:

$ composer --version

NOTA:
No es necesario utilizar ningún otro parámetro.
Dependiendo de su sistema puede tener un .bashrc en lugar de .bash_profile.

ACTUALIZACIÓN:

As @ AlexanderKachkaev mencionar en los comentarios no vale la pena añadir el memory_limit de la siguiente manera para evitar estrellarse im algunas situaciones:

alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"

Se me ocurrió una respuesta que funciona bastante bien para OSX, y probablemente podría ser adaptada para cualquier versión de PHP que cargue sus extensiones usando individual .archivos ini en el "directorio ini adicional":

#!/bin/sh

function php-no-xdebug {
    local temporaryPath="$(mktemp -t php-no-debug)"

    find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
    php -n -c "$temporaryPath" "${@:2}"
    rm -f "$temporaryPath"
}

alias composer="php-no-xdebug php56 ~/bin/composer"

Normalmente creo un script de shell por proyecto, ya que cada proyecto tiene otra versión de PHP. Está en un directorio /bin/ junto a composer.phar y composer.json y lo corro como ./bin/composer en el directorio de mi proyecto.

Se ve así (para php56)

#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
    -d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
    -d xdebug.default_enable=0 $DIR/../composer.phar "$@"

Las opciones -d efectivamente deshabilitan xdebug. La parte COMPOSER_DISABLE_XDEBUG_WARN=1 desactiva los problemas del editor de advertencias.

Se prefiere deshabilitar la extensión xdebug (ver solución de problemas de composer ), pero personalmente me gusta el más simple script.

Algunos tiempos en mi máquina: 2 Ejecutar con xdebug y habilitado para ini: 1m33

Ejecutar con xdebug pero ini-desactivado: 0m19

Ejecutar sin xdebug: 0m10

Si usa PhpStorm, la última versión (2016.2) viene con una función para habilitar XDebug para scripts de CLI bajo demanda, lo que significa que simplemente puede desactivar XDebug globalmente en su máquina de desarrollo. El IDE lo habilitará sobre la marcha cuando sea necesario por el código dentro de sus proyectos.

Https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/

PhpStorm 2016.2 presenta el modo Xdebug On Demand donde puede deshabilite Xdebug para su instalación global de PHP, y PhpStorm solo lo habilitará cuando lo necesite, cuando esté depurando sus scripts o cuando necesite informes de cobertura de código.

Necesita editar sus preferencias de Intérpretes PHP para incluir la ruta a XDebug, como se describe en el artículo vinculado.

A mí esto me parece la solución perfecta, ya que normalmente solo quiero XDebug mientras estoy en el IDE.

Sin embargo, XDebug tiene otros usos potenciales cuando está " fuera de línea" por ejemplo, la pila extendida descarga en los registros de errores, que perdería al desactivarla globalmente. Por supuesto, no debería tener XDebug habilitado en producción, por lo que esto se limitaría a casos de uso como pruebas beta o scripts CLI de pruebas automatizadas en desarrollo.

Se me ocurrió una solución para el instalador de Composer basado en Windows: debería funcionar para cualquier instalación de Composer, básicamente hace una copia del archivo INI cargado y comenta la extensión xdebug zend, luego carga ese archivo de configuración cuando ejecuta composer.

He abierto un problema para ver si les gustaría integrar este cambio:

Https://github.com/composer/windows-setup/issues/58

Puedes encontrar mis instrucciones y código allí.

Como se indica en la respuesta de Joyce, este problema ya no existe en la última versión de Composer.

La documentación de Composer se ha actualizado a tenga en cuenta esto. Detalla cómo puede habilitar xdebug con Composer (si es necesario).

Puede actualizar su versión de Composer utilizando self-update.

En mi Mac tuve que hacer: sudo php /opt/local/bin/composer self-update

Más detalles sobre esto en el contexto de una instalación de PHP de Homebrew se pueden encontrar en esto issue .

Manipulación directa de la configuración de PHP

Aquí está mi contribución basada en una Homebrew - instalación PHP instalada en Mac OS X.

Es un envoltorio shell-script, diseñado para ser guardado como un archivo ejecutable en /usr/local/bin/composer, con el binario Composer en /usr/local/bin/composer.phar:

#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$@"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini

Teoría de la Operación

El script de envoltura:

• usa sed para modificar temporalmente el archivo de configuración, deshabilitando Xdebug (línea 2)
• ejecuta Composer, pasando a través de args al comando (línea 3)
• usa sed para restaurar el archivo de configuración, volviendo a habilitar Xdebug (línea 4)

El script está acoplado a una instalación de OS X/Homebrew de PHP 5.5. Las rutas deben ser ajustadas para trabajar con otras versiones de PHP y otros sistemas operativos y diseños de directorios de gestores de paquetes. Tenga en cuenta también que algunas versiones de sed no necesitan el argumento empty-string después de la opción -i.

Advertencia Utilitor

El script es sencillo, ya que funciona directamente en los archivos de configuración principales de PHP, sin embargo esto también es un inconveniente: Xdebug también se deshabilitará para cualquier script que se ejecute simultáneamente con este script.

En mi entorno de desarrollo, esta es una compensación aceptable, dado que Composer se ejecuta manualmente y solo ocasionalmente; sin embargo, es posible que no desee usar esta técnica si ejecuta Composer como parte de un proceso de implementación automatizado.

En la mayoría de los casos no necesita xdebug en modo CLI. Si esto es aceptable para usted, puede configurar cli y cgi de manera diferente.

Así que si haces php-cli.ini y conf-cli.d cerca de salir de php.archivo ini que puede configurar cli y cgi de manera diferente (para cgi sería php.ini y conf.d ). Simplemente no poner xdebug.ini en conf-cli.d.

En lugar de confundirse con habilitar o deshabilitar temporalmente el módulo PHP, cuando puede tener procesos concurrentes usando PHP (por ejemplo, como parte de una canalización de CI), puede decirle a PHP que apunte a un directorio de carga de módulo diferente.

Si bien esto es similar a algunas de las soluciones mencionadas anteriormente, esto resuelve algunos casos de borde, lo que es muy útil cuando se utiliza por Jenkins u otro corredor de CI que ejecuta pruebas en la misma máquina al mismo tiempo.

La forma más fácil de hacer esto es para usar la variable de entorno PHP_INI_SCAN_DIR

Usar esto en un script o tarea de compilación es fácil:

export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install

Por supuesto que querrías preparar /etc/php.d. noxdebug primero, haciendo algo como:

mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini

Esto significa que tiene un entorno similar al antiguo entorno php, con solo un módulo que falta. Lo que significa que no necesita preocuparse por la necesidad de cargar los módulos phar/json como lo haría con la solución php-n.

Si instala composer usando brew en OS X Puedes usar este alias:

alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"

Mi solución rápida para una instalación de macports, con múltiples versiones de PHP fue escribir este simple shell wrapper para Composer:

/user/local/bin/composer-nodebug.sh

#!/bin/bash

sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini

Luego ejecute cualquier comando composer de la siguiente manera:

sudo composer-nodebug.sh update

Inconvenientes:

• requiere sudo (a menos que modifiques los archivos INI)
• si lo matas a mitad de camino, los archivos INI se modifican
• requerirá futuras versiones de PHP añadidas.
• mientras se ejecuta otros procesos PHP se ven afectados

No elegante, pero simple.

Aquí está mi solución rápida para deshacerse de la advertencia Xdebug en la versión PHP5-cli. He eliminado el soporte de Xdebug para PHP5-cli en Ubuntu 14.04.

Cd / etc / php5 / cli / conf.d /

Sudo rm 20-xdebug.ini

Ahora no más advertencias de Xdebug en PHP5-cli.