Liste de fichiers avec grep

Geoffrey — Sun, 13 Aug 2006 17:57:00 +0200

Quand on cherche à récupérer une liste de fichiers contenant un motif particulier sous UNIX, on peut, quand on est une grosse brute comme moi, utiliser un mix des commandes grep, cut et uniq:

grep -r motif /emplacement/des/fichiers/ | cut -d : -f 1 | uniq

Le truc, c'est qu'il existe une option de grep qui remplace avantageusement l'appel a cut:

grep -rl motif /emplacement/des/fichiers | uniq

Je ne sais pas si l'option -l traite les doublons, a vérifier.

Entry has unexpectedly changed special status

Geoffrey — Tue, 25 Jul 2006 10:40:00 +0200

Aussi connue sous le nom de L'entrée a changé de statut spécial de façon inattendue si vous avez le malheur d'avoir une machine en fr_FR, cette erreur subversion est pour le moins windowsesque, puisqu'elle n'explicite en rien (a première vue du moins) le problème rencontré. Je suppose qu'il peut intervenir dans plusieurs cas, mais dans le mien, j'avais tout simplement changé le status d'un fichier symlink en vrai fichier :-) Manip simple pour réparer (disons que le fichier s'appelle index.php et qu'il était un lien vers blog.php):

$ mv index.php index.php.new
$ ln -s blog.php index.php
$ svn rm index.php
$ mv index.php.new index.php
$ svn add index.php

Et voilà, vous pouvez maintenant commettre (oh oh oh) votre working copy.

php_sapi_name, pour des includes dynamiques ?

Geoffrey — Mon, 29 May 2006 12:58:44 +0000

Tout a l'heure je me suis dis que j'aurai bien voulu faire un include en fonction du SAPI dans lequel un script s'execute. Comme PHP est (presque) bien fait, il existe la fonction php_sapi_name qui retourne le nom du SAPI courant. Ce qui nous permet de faire quelque chose comme:

$sapi_include = dirname(__FILE__) . '/sapi/'.php_sapi_name().'.php';
$sapi_default = dirname(__FILE__) . '/sapi/default.php';
 
if (file_exists($sapi_include)) {
	require_once $sapi_include;
} else if (file_exists($sapi_default)) {
	require_once $sapi_default;
}

C'est pas très joli, mais ça fonctionne. Le gros avantage, c'est qu'on a des includes spécifiques au SAPI, et donc on aura par exemple, dans sapi/apache2handler.php:

header('Content-Type: text/html; charset=ISO-8859-15');
require_once 'libraries/Template.php';
session_start();

et dans sapi/cli.php:

Var_Dump::displayInit(array('display_mode' => 'text'));

Le problème, résolu par l'utilisation de sapi/default.php, était que faire un fichier par SAPI possible serait fastidieux (il faut connaitre le nom de tous les SAPI disponibles (bon ok c'est disponible ici mais cette liste n'a rien d'officiel) puis faire un fichier pour chaque.

Maintenant la question que je me (et vous) pose, c'est: y'a-t'il des effets secondaires que je n'aurai pas encore remarqué ?

Faire du CLI en PHP

Geoffrey — Sat, 05 Mar 2005 13:02:47 +0000

Souvent les gens ne voient PHP que comme un langage de script orienté web. Même si il est vrai que c'est son but premier, ce n'est pas la seule chose que PHP peut faire. Penchons nous un peu sur l'utilisation de PHP en CLI, qui permet d'utiliser PHP comme un langage de script classique. Nous utiliserons pour se faire un système linux (ubuntu pour être précis) avec un binaire php-cli déjà installé.

Au commencement...

Au commencement est le shebang. Qu'est-ce que c'est donc que ça ? C'est simplement la première ligne d'un script shell, celle qui indique au shell quel interpréteur utiliser pour executer le script. Elle début obligatoirement par les caractères #! (qu'on appelle shebang), suivis du chemin absolu de l'interpréteur. Dans la plupart des cas, l'intérpréteur PHP se situe dans /usr/bin et s'appelle php, tout simplement. Ce qui nous donne donc:

#!/usr/bin/php

Bien sur, il est possible que votre interpréteur se situe ailleurs, /usr/local/bin/php par exemple. Pour le trouve, vous pouvez utiliser la commande which:

ash@sushi:~$ which php
/usr/bin/php

Si cette commande ne retourne rien, c'est que php-cli n'est pas installé, et là ça dépasse le cadre de cet article :)

Un petit détour par la doc

A ce stade, il est bon d'aller voir ce que la doc a a nous dire sur l'utilisation de PHP en ligne de commande. On y apprend toutes sortes de choses, a commencer par la compilation de PHP en CLI. On y apprend également que certaines valeurs du php.ini sont différentes de celles de PHP utilisé avec un server web, et nottement:

html_errors, pour ne pas afficher de HTML dans les erreurs
max_execution_time, pour autoriser un temps d'execution infini
register_argc_argv, pour peupler les variables $argc et $argv, sur lesquelles nous reviendrons plus tard

On y apprend aussi que php-cli enregistre automatiquement de nouvelles constantes telles que:

STDIN
STDOUT
STDERR

Qui représentent respectivement l'entrée standard, la sortie standard, et la sortie d'erreur standard. Nous reviendronts sur ces constantes et leur utilisation plus tard.

La dernière chose que nous retiendrons de cette page est que php-cli ne modifie pas le repertoire courant a l'execution d'un script. C'est à dire que si vous vous trouvez dans le répertoire /tmp, et que vous executez php /home/ash/foo.php, la fonction getcwd (GET Current Working Directory) retournera /tmp, et pas /home/ash.

Notre premier script en CLI

Il est grand temps d'entrer dans le vif du sujet et de faire notre premier script. Soyons originaux, créons un hello_world.php, avec le code suivant:

#!/usr/bin/php
<?php print "hello world !"; ?>

Une fois le fichier créé, nous avons deux possibilités pour l'executer. Soit lancer directement l'interpréteur PHP en lui précisant le script a executer:

$ /usr/bin/php ./hello_world.php

Soit rendre le script executable et l'executer directement:

$ chmod +x ./hello_world.php
$ ./hello_world.php

Dans tous les cas, le résultat est le même:

hello world !

Facile non ? Notez bien que si vous décidez de rendre le script executable, vous n'aurez a executer la commande chmod qu'une seule fois.

Vous remarquerez surement que votre prompt s'affiche directement après le !, c'est normal, nous n'avons pas inclus de caractère de nouvelle ligne () dans notre print. Vous pouvez donc modifier le script ainsi:

#!/usr/bin/php
<?php print "hello world !
"; ?>

Et le tour est joué.

Utilisation de $argc et $argv

Tout ça c'est bien beau, mais un script c'est quand même mieux quand on peut lui passer des arguments. Et non, executer ./hello_world.php?arg=value ne fonctionne pas :-) Comment faire alors ? Les variables $argc et $argv sont là pour ça.

Pour passer des paramètres à un shell script, on utilise usuellement la syntaxe suivante:

$ ./script [arg [arg...]]

C'est comme cela que nous procéderons en PHP-CLI. La variable $argc (ARGuments Count) contient le nombre de paramètres passés au script, tandis que la variable $argv (ARGuments Values) est un array contient les valeurs de ces arguments. Modifions donc notre script de tout à l'heure:

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

Et executons le en lui passant quelques paramètres:

$ ./hello_world.php foo bar

Voyons le résultat:

ash@sushi:~$ ./hello_world.php foo bar
int(3)
Array
(
    [0] => ./hello_world.php
    [1] => foo
    [2] => bar
)

On remarque que le nom du script compte comme un argument.

Utilisation de STDIN

Ces constantes dont nous avons parlé plus tôt sont très importantes. Elles définissent les flux standards à votre disposition, mais nous ne nous interresserons qu'a STDIN dans cet article.

STDIN (STanDard INput) est l'entrée standard. C'est elle que vous devez utiliser que vous voulez interragir avec l'utilisateur. Par exemple pour lui faire entrer des données. Modifions encore une fois notre hello_world.php:

#!/usr/bin/php
<?php
$name = trim(fgets(STDIN));
print "hello $name !
";
?>

Et executons le:

ash@sushi:~$ ./hello_world.php 
geoffrey
hello geoffrey !

Le script a donc attendu que je tape quelque chose en terminant par un CRLF (Cariage Return Line Feed, la touche Entrée quoi ;). J'ai donc tapé geoffrey, et voilà. Notons l'utilisation de trim pour supprimer le CRLF en question.

Le mot de la fin

Voilà, avec ça, vous devriez avoir les bases nécessaire pour commencer a faire du PHP-CLI. Cela dit, cet article n'explore pas toutes les subtilités du CLI, et une bonne lecture de documentation est fortement conseillée :)

Mirmo Dynamics - Tag - cli