web-dev-qa-db-fra.com

PHP le script cli ne génère rien

J'ai donc un script php que j'exécute en utilisant la commande suivante:

php -f my_script.php myArguments

Le script est sous contrôle de version via svn. Je viens de le mettre à jour, de coller la commande pour l'exécuter dans un terminal et de l'exécuter. Cependant, il n'y a pas de sortie. Pas un message d’échec, pas d’impression, rien. On dirait que ça ne commence jamais. Un peu comme ce qui suit:

me:/srv/scripts# php -f my_script.php myArguments
me:/srv/scripts#

Les autres scripts fonctionneront très bien. 

Il m'est difficile de créer une SSCCE, car je ne peux pas vraiment partager le code qui est à l'origine de cette situation et je n'ai pas été en mesure de reproduire ce comportement intentionnellement. J'ai cependant vu cela deux fois maintenant. Si je sauvegarde mes modifications, que je rétablis le fichier et que je les colle à nouveau, il y a de fortes chances qu'il fonctionne correctement.

Cependant, je suis préoccupé par le fait de ne pas savoir ce qui cause cet étrange comportement. Existe-t-il un caractère d'espacement ou quelque chose qui indique à PHP de ne pas démarrer ou de générer quoi que ce soit?

Voici ce que j'ai essayé après avoir constaté ce comportement:

  • Modification du script pour qu'il s'agisse d'un simple echo 'hello'

  • Mettre un non-sens au début du script, c'est donc imparable.

  • Coller dans le code d'un script de travail

  • Frapper ma tête sur un mur de frustration

  • Essayer dans une autre connexion terminal/PuTTY ssh.

Voici où cela devient intéressant: En fait, fonctionne dans un autre terminal. Il fait tout comme prévu. 

Alors, est-ce que quelqu'un a des idées sur ce qui pourrait être la cause de ceci, ou sur des choses que je devrais essayer afin de déterminer le problème?

MODIFIER:

Le "terminal différent" est toujours l'application de terminal, mais une nouvelle.

J'ai les autorisations suffisantes pour exécuter le fichier, mais même si je ne le faisais pas, il devrait cracher un message disant que je ne le fais pas.

J'ai intentionnellement introduit des erreurs de syntaxe dans l'espoir d'obtenir que PHP génère une erreur d'analyse. Il n'y avait toujours pas de sortie.

phpoutputcommand-line-interface
16
MirroredFate

display_errors peut être désactivé avant l'exécution. Vous pouvez l'activer manuellement avec le commutateur -d :

php -d display_errors=1 -f my_script.php myArguments
20
Mike B

Je suis tombé sur le même problème et aucune contrainte de PHP à display_errors ou de vérification de la syntaxe avec -l n'a aidé.

J'ai finalement résolu notre problème et peut-être pouvez-vous trouver de l'aide pour cette solution

Testez votre script sans utiliser votre php.ini:

php -n test_script.php

Cela vous aidera à mieux cerner la cause réelle: la configuration de PHP, le script de quelqu'un d'autre ou votre script.

Dans mon cas, c'était un problème avec le script de quelqu'un d'autre qui était ajouté via la directive auto_prepend_file dans le fichier php.ini. (Ou plus précisément, plusieurs fichiers et fonctions plus tard au fur et à mesure que j'explorais tout le code en ajoutant le débogage au fur et à mesure que je progressais; en passant, vous constaterez peut-être que l'utilisation de fwrite(STDOUT, "debug text\n"); est inestimable lorsque vous essayez de déboguer ce type de problème)

Quelqu'un avait ajouté une fonction qui était exécutée dans le fichier de pré-ajout, mais avait utilisé le symbole @ pour supprimer les erreurs lors d'un appel de fonction particulier. (Vous pourriez avoir un problème similaire mais pas spécifiquement lié au fichier php.ini si vous en avez inclus dans votre script de test en introduisant un autre code)

La fonction échouait et causait la mort silencieuse de PHP, rien à voir avec mon script de test

Vous trouverez toutes sortes d'avertissements sur le fait que l'utilisation du symbole @ est à l'origine du problème exact que j'ai rencontré et que vous rencontrez peut-être aussi http://php.net/manual/fr/language.operators.errorcontrol.php .

Reproduction de symptômes similaires:

Prenez un environnement PHP entièrement fonctionnel et coupez la sortie de votre interface de ligne de commande en l'ajoutant en haut de votre script @xxx_not_a_real_function_name_xxx();

Donc, vous pouvez simplement avoir un problème avec le fichier php.ini, ou vous (ou quelqu'un d'autre) avez peut-être utilisé @ sans vous rendre compte des conséquences graves (et frustrantes et qui prennent du temps) qu'il entraîne lors du débogage

9
Tim

PHP La CLI échouait silencieusement sur un bon script en raison d'un problème de limite de mémoire. Essayez avec:

php -d memory_limit=512M script.php
0
Marco Marsala