PHP 8.4.0 RC4 available for testing

Exécution de fichiers PHP

Il y a 3 façons différentes d'appeler le CLI SAPI avec du code PHP à exécuter :

  1. Indiquer à PHP d'exécuter un fichier donné :

    php mon_script.php
    
    php -f mon_script.php
    

    Les deux méthodes (en utilisant -f ou pas) exécutent le script contenu dans le fichier mon_script.php. Notez qu'il n'existe pas de restriction sur les fichiers pouvant être exécutés ; en particulier, il n'est pas nécessaire que l'extension du fichier soit .php.

  2. Donner du code PHP à exécuter directement en ligne de commande.

    php -r 'print_r(get_defined_constants());'
    

    Une attention particulière doit alors être apportée aux variables d'environnement, qui seront remplacées, et aux guillemets, qui ont des significations spéciales en ligne de commande.

    Note:

    Lisez l'exemple attentivement, il n'y a ni balise d'ouverture, ni balise de fermeture ! L'option -r rend caduque l'utilisation de celles-ci, et les ajouter conduirait alors à une erreur d'analyse syntaxique.

  3. Alimenter l'entrée standard en code PHP (stdin).

    Cela donne la possibilité de créer dynamiquement du code PHP, puis de le fournir à PHP, et enfin, de le traiter à nouveau en shell. Voici un exemple fictif :

    $ some_application | some_filter | php | sort -u > final_output.txt
    
Il n'est pas possible de combiner ces trois modes d'exécution.

Comme toute application shell, l'exécutable PHP accepte des arguments ; cependant, le script PHP peut aussi en recevoir. Le nombre d'arguments pouvant être passés à votre script n'est pas limité par PHP (le shell a une limite en termes de nombre de caractères qui peuvent être passés. Généralement, vous n'atteindrez pas cette limite). Les arguments passés au script seront transmis via la variable tableau $argv. Le premier index (zéro) contient toujours le nom du script appelé depuis la ligne de commande. Notez que, si le code est exécuté en ligne en utilisant l'option de ligne commande -r, la valeur de $argv[0] sera "Standard input code"; antérieur à PHP 7.2.0, c'était un tiret ("-") à la place. Cela est aussi vrai si le code est exécuté via un pipe depuis STDIN.

Une seconde variable globale, $argc, contient le nombre d'éléments du tableau $argv (et non pas le nombre d'arguments passés à votre script).

Tant que les arguments passés au script ne commencent pas par le caractère -, il n'y a rien de spécial à surveiller. Le fait de passer des arguments au script qui commencent par - pose des problèmes car PHP va penser qu'il doit les interpréter. Pour éviter cela, utilisez le séparateur --. Après cet argument, tous les arguments suivants seront passés au script sans être modifiés ou analysés par PHP.

# Cela ne va pas exécuter le code, mais afficher l'aide de PHP
$ php -r 'var_dump($argv);' -h
Usage: php [options] [-f] <file> [args...]
[...]

# Cela va passer l'argument '-h' au script, et éviter que PHP ne le traite
$ php -r 'var_dump($argv);' -- -h
array(2) {
  [0]=>
  string(1) "-"
  [1]=>
  string(2) "-h"
}

Cependant, il y a une autre méthode pour utiliser PHP en script shell ; la première ligne du script devra être #!/usr/bin/php (à remplacer par le chemin vers le binaire PHP CLI sur le système sous-jacent). Le reste du fichier doit contenir le code PHP normal, compris entre les balises ouvrantes/fermantes. Après avoir mis les droits d'exécution sur le script (chmod +x test), il peut être exécuté comme un script shell ou perl habituel :

Exemple #1 Exécute un script PHP en tant que script shell

#!/usr/bin/php
<?php
var_dump
($argv);
?>

En supposant que ce fichier s'appelle test, dans le dossier courant, il est alors possible de faire ceci :

$ chmod +x test
$ ./test -h -- foo
array(4) {
   [0]=>
   string(6) "./test"
   [1]=>
   string(2) "-h"
   [2]=>
   string(2) "--"
   [3]=>
   string(3) "foo"
}

Comme vous pouvez le voir, dans ce cas, vous n'avez pas besoin de faire attention lors du passage de paramètres qui commencent par - à votre script.

L'exécutable PHP peut être utilisé pour exécuter des scripts indépendants du serveur web. Si vous êtes sur un système Unix, il est recommandé d'ajouter la ligne spéciale en début de script, de le rendre exécutable de manière que le système sache quel programme doit exécuter le script. Sous Windows, vous pouvez associer l'exécutable php.exe avec le double-clic sur les fichiers d'extension .php, ou bien vous pouvez faire un fichier batch pour exécuter le script grâce à PHP. La première ligne utilisée dans le monde Unix ne perturbera pas l'exécution sous Windows, ce qui rend les scripts facilement portables. Un exemple complet est disponible ci-dessous :

Exemple #2 Script prévu pour être exécuté en ligne de commande (script.php)

#!/usr/bin/php
<?php

if ($argc != 2 || in_array($argv[1], array('--help', '-help', '-h', '-?'))) {
?>

C'est une ligne de commande à une option.

Utilisation :
<?php echo $argv[0]; ?> <option>

<option> peut être un mot que vous souhaitez afficher.
Avec les options --help, -help, -h,
et -?, vous obtiendrez cette aide.

<?php
} else {
echo
$argv[1];
}
?>

Le script ci-dessus inclut la première ligne spéciale indiquant que ce fichier doit être exécuté par PHP. Nous travaillons ici avec la version CLI, aussi, aucun en-tête HTTP ne sera affiché.

Le programme commence par vérifier que l'argument requis est spécifié (en plus du nom du script, qui est aussi compté). S'il n'est pas présent, ou si l'argument est --help, -help, -h ou -?, un message d'aide sera affiché, en utilisant $argv[0] pour afficher dynamiquement le nom du script tel qu'entré dans la ligne de commande. Sinon, l'argument est affiché tel qu'il a été entré dans le terminal.

Pour exécuter le script ci-dessus sous Unix, vous devez le rendre exécutable, puis l'appeler avec une commande comme : script.php echothis ou script.php -h. Sous Windows, vous pouvez faire un fichier batch pour cela :

Exemple #3 Fichier batch pour exécuter un script PHP en ligne de commande (script.bat)

@echo OFF
"C:\php\php.exe" script.php %*

En supposant que le programme ci-dessus est nommé script.php, et que l'exécutable CLI php.exe se trouve dans C:\php\php.exe, ce fichier batch l'exécutera avec les options que vous lui passez : script.bat echothis ou script.bat -h.

Voir aussi l'extension Readline, qui dispose de nombreuses fonctions pour améliorer la convivialité de des applications PHP en ligne de commande.

Sous Windows, PHP peut être configuré pour fonctionner sans avoir besoin de fournir les extensions C:\php\php.exe ou .php, tel que décrit dans la ligne de commande PHP sous Microsoft Windows.

Note:

Sous Windows, il est recommandé d'exécuter PHP sous un compte utilisateur. Lorsque PHP est exécuté sous un service réseau, certaines opérations peuvent échouer, car "Aucun lien entre les noms de compte et les identifiants de sécurité n'est réalisé".

add a note

User Contributed Notes 5 notes

up
59
php at richardneill dot org
11 years ago
On Linux, the shebang (#!) line is parsed by the kernel into at most two parts.
For example:

1: #!/usr/bin/php
2: #!/usr/bin/env php
3: #!/usr/bin/php -n
4: #!/usr/bin/php -ddisplay_errors=E_ALL
5: #!/usr/bin/php -n -ddisplay_errors=E_ALL

1. is the standard way to start a script. (compare "#!/bin/bash".)

2. uses "env" to find where PHP is installed: it might be elsewhere in the $PATH, such as /usr/local/bin.

3. if you don't need to use env, you can pass ONE parameter here. For example, to ignore the system's PHP.ini, and go with the defaults, use "-n". (See "man php".)

4. or, you can set exactly one configuration variable. I recommend this one, because display_errors actually takes effect if it is set here. Otherwise, the only place you can enable it is system-wide in php.ini. If you try to use ini_set() in your script itself, it's too late: if your script has a parse error, it will silently die.

5. This will not (as of 2013) work on Linux. It acts as if the whole string, "-n -ddisplay_errors=E_ALL" were a single argument. But in BSD, the shebang line can take more than 2 arguments, and so it may work as intended.

Summary: use (2) for maximum portability, and (4) for maximum debugging.
up
6
email at alexander-bombis dot de
3 years ago
For Windows:

After the years I also have the fact that I have to use double quotation marks after php -r on Windows shell.

But in the Powershell you can use single or double quotation!
up
4
gabriel at figdice dot org
7 years ago
Regarding shebang:

In both Linux and Windows, when you execute a script in CLI with:

php script.php

then PHP will ignore the very first line of your script if it starts with:

#!

So, this line is not only absorbed by the kernel when the script file is executable, but it is also ignored by the PHP engine itself.

However, the engine will NOT ignore the first #! line of any included files withing your "outer" script.php.
Any "shebang" line in an included script, will result in simply outputting the line to STDOUT, just as any other text residing outside a <?php ... ?> block.
up
3
david at frankieandshadow dot com
8 years ago
A gotcha when using #!/usr/bin/php at the start of the file as noted above:

if you originally edited the file on Windows and then attempt to use it on Unix, it won't work because the #! line requires a Unix line ending. Bash gives you the following error message if it has DOS line endings:
"bash: /usr/local/bin/wpreplace.php: /usr/bin/php^M: bad interpreter: No such file or directory"

(In Emacs I used "CTRL-X ENTER f" then type "unix" and ENTER to convert)
up
2
spencer at aninternetpresence dot net
13 years ago
If you are running the CLI on Windows and use the "-r" option, be sure to enclose your PHP code in double (not single) quotes. Otherwise, your code will not run.
To Top