commande qx ?

**donny** · 04/10/2006, 11h45

salut,

J'aurai aimé savoir le role de la fonction qx ?
Si on tape par exemple qx(/home/rep/file) elle va retourné `/home/rep/file` ?
Quel est l'interet ?

Merci

**Arioch** · 04/10/2006, 12h02

Envoyé par donny

salut,

J'aurai aimé savoir le role de la fonction qx ?
Si on tape par exemple qx(/home/rep/file) elle va retourné `/home/rep/file` ?
Quel est l'interet ?

Merci

L'intérêt est qu'en faisant qx(chaine), tu peux ensuite faire exécuter chaine.

Voici ce qu'en dit le perldoc :

qx/CHAINE/
‘CHAINE‘
Une chaîne qui est (éventuellement) interpolée puis exécutée comme une commande système par /bin/sh ou équivalent. Les jokers, tubes (pipes) et redirections sont pris en compte. L’ensemble de la sortie standard de la commande est renvoyé ; la sortie d’erreur n’est pas affectée. Dans un contexte scalaire, le résultat est retourné comme une seule chaîne (potentiellement multi-lignes). Dans un contexte de liste, le résultat est une liste de lignes (selon la définition des lignes donnée par $/ ou $INPUT_RECORD_SEPARATOR).
Puisque les apostrophes inverses (backticks) n’affectent pas la sortie d’erreur, il vous faut utiliser la (les) syntaxe(s) de redirection du shell (en supposant qu’elle(s) existe(nt)) afin de capter les erreurs. Pour récupérer les sorties STDOUT et STDERR d’une commande :
$output = ‘cmd 2>&1‘;

Pour récupérer STDOUT et faire disparaître STDERR:
$output = ‘cmd 2>/dev/null‘;

Pour récupérer STDERR et faire disparaître STDOUT (l’ordre est ici très important) :
$output = ‘cmd 2>&1 1>/dev/null‘;

Pour échanger STDOUT et STDERR afin de récupérer STDERR tout en laissant STDOUT s’afficher normalement :
$output = ‘cmd 3>&1 1>&2 2>&3 3>&-‘;

Pour récupérer STDOUT et STDERR séparément, il est plus simple et sain de les rediriger séparément vers des fichiers qui seront lus lorsque l’exécution de la commande sera terminée :
system("program args 1>/tmp/program.stdout 2>/tmp/program.stderr");

L’utilisation de l’apostrophe comme délimiteur protège la commande de l’interpolation normalement effectuée par Perl sur les chaînes entre guillemets. La chaîne est passée tel quelle au shell :
$perl_info = qx(ps $$); # Le $$ de Perl
$shell_info = qx’ps $$’; # Le $$ du nouveau shell

Remarquez que la manière dont la chaîne est évaluée est entièrement dépendante de l’interpréteur de commandes de votre système. Sur la plupart des plates-formes, vous aurez à protéger les méta-caractères du shell si vous voulez qu’ils soient traités littéralement. En pratique, c’est difficile à faire, surtout qu’il n’est pas toujours facile de savoir quels caractères doivent être protégés. Voir le manuel perlsec pour un exemple propre et sûre d’utilisation manuelle de fork() et exec() pour émuler proprement l’utilisation des backticks.

Sur certaines plates-formes (particulièrement celles style DOS) le shell peut ne pas être capable de gérer des commandes multi-lignes. Dans ce cas, l’usage de passages à la ligne dans la chaîne de commande ne donne pas ce que vous voulez. Vouspouvez évaluez plusieurs commandes sur une seule et même ligne et les séparant par le caractère de séparation de commandes si votre shell le supporte (e.g. ; pour la plupart des shells Unix; & sur le cmd shell de Windows NT).

Depuis la version v5.6.0, Perl tente de vider les tampons de tous les fichiers ouverts en écriture avant de lancer la commande mais cela n’est pas supporté sur toutes les plates-formes (voir le manuel perlport). Pour être plus sûr, vous devriez positionné la variable $| ($AUTOFLUSH en anglais) ou appelé la méthode autoflush() des objets IO::Handle pour chacun des descripteurs ouverts.
N’oubliez pas que certains shells ont quelques restrictions sur la longueur de la ligne de commande. Vous devez vous assurer que votre chaîne n’excède pas cette limite même après interpolation. Voir les notes spécifiques à votre plate-forme pour plus de détails sur votre environnement particulier.
L’utilisation de cet opérateur peut aboutir à des programmes difficiles à porter puisque les commandes shells appelées varient d’un système à l’autre et peuvent parfois ne pas exister du tout. À titre d’exemple, la commande type du shell POSIX est très différente de la commande type sous DOS. Cela ne signifie pas qu’il vous faut à tout prix éviter cet opérateur lorsque c’est le bon moyen de faire ce que vous voulez. Perl a été conçu pour être un "glue language"... La seule chose qui compte c’est que vous sachiez ce que vous faites.