perlwin32faq5 - Problèmes d'implémentation


NOM

perlwin32faq5 - Problèmes d'implémentation

Retour en haut de la page


DESCRIPTION

Sujets spécifiques au portage Win32 de Perl.

Certaines fonctions semblent ne pas fonctionner avec ActivePerl.

Il y a plusieurs fonctions qui ne sont pas implémentées dans le système ActivePerl. Voici une liste complète des fonctions non implémentées :

Fonctions pour les processus et les groupes de processus
alarm(), getpgrp(), getppid(), getpriority(), setpgrp(), setpriority()

Informations sur les groupes et utilisateurs
endgrent(), endpwent(), getgrent(), getgrgid(), getgrnam(), getpwent(), getpwnam(), getpwuid(), setgrent(), setpwent()

Fonctions de communication interprocessus sur Système V
msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(), semop(), shmctl(), shmget(), shmread(), shmwrite()

Fonctions des gestionnaires de fichiers, de fichiers et de répertoires
link(), symlink(), chroot()

Fonctions d'entrées/sorties
syscall()

Informations réseau
getnetbyname(), getnetbyaddr(), getnetent(), getprotoent(), getservent(), sethostent(), setnetent(), setprotoent(), setservent(), endhostent(), endnetent(), endprotoent(), endservent(), socketpair()

Voir les pages de documentation perlport et perlwin32 pour plus d'information sur la portabilité des fonctions intégrées à ActivePerl.

La fonction exec semble ne pas fonctionner avec Perl pour ISAPI ou PerlScript. Pourquoi ?

Perl pour ISAPI, Perl pour WebSite, et PerlScript partage un espace de processus avec le serveur web et toutes les autres extensions. Donc la fonction exec() n'est pas implémentée, parce que cela amènerait le serveur web à s'arrêter (la fonction exec() exécute une commande système et ne revient jamais).

Quelle est l'histoire d'ActivePerl sur Windows ?

Fut un temps, Perl pour plates-formes Win32 existait en deux versions, le portage Gurusamy Sarathy, et le portage ActiveState. Le portage ActiveState incluait des outils comme Perl pour ISAPI et PerlScript, au prix d'une gestion interne de Perl légèrement différente du Perl standard. Le portage de Sarathy était très compatible avec le Perl standard, ce qui permettait aux utilisateurs du portage Sarathy d'utiliser beaucoup de modules qui n'étaient pas compatibles avec le Perl d'ActiveState.

L'effort «un seul perl» rassembla les deux portages, et ActivePerl est le standard pour la distribution de Perl sur les systèmes Win32. Tous les modules qui pouvaient être utilisés sur Win32 peuvent être utilisés avec ce portage. Vous n'avez plus à vous soucier de savoir pour quel perl est un module. Téléchargez-le, compilez-le (si besoin), et utilisez-le.

Quelle différence quand on utilise ActivePerl sous Windows NT ou sous Windows 95?

Il devrait y avoir peu de différences entre les deux systèmes. Vous pouvez cependant surveiller les points suivants :

Si vous êtes inquiet d'utiliser une capacité spécifique à l'un ou l'autre, consulter le résultat de la fonction Win32::IsWinNT() pour savoir quel système d'exploitation vous utilisez. Voir Quels modules accompagnent la distribution Win32 de Perl ?.

Pourquoi les exemples du Camel ne marchent-ils pas ?

Le Camel Book (alias Programming Perl (3rd edition), Wall et.al., O'Reilly & Associates 2000) a été écrit par des utilisateurs UNIX pour, en général, des utilisateurs UNIX.

Certains des exemples du Camel fonctionneront, d'autres non. S'ils échouent, c'est soit parce que les fonctions utilisées ne sont pas disponibles, soit les outils externes utilisés ne sont pas disponibles, soit les modules utilisés ne sont pas disponibles. Habituellement, pour de petits scripts, il n'est pas difficile de les bidouiller pour les faire fonctionner (voir Comment faire fonctionner un script prévu pour Unix ?).

Le Camel et le Lama sont de bons livres d'apprentissage. Cependant, une des choses que vous apprenez en tant que codeur ActivePerl, c'est comment porter un script ou module UNIX vers ActivePerl .

Pour de meilleurs exemples d'utilisation de Perl pour Win32, vous pouvez regarder le Gecko, «Learning Perl on Win32 Systems» publié par O'Reilly.

Pourquoi certains modules standard ne fonctionnent-ils pas ?

Presque tous les modules fonctionneront avec ActivePerl tant qu'ils peuvent être construits pour fonctionner sous Win32. Les problèmes liés aux versions 3xx de Perl pour Win32 n'existent plus : les modules fonctionnent sous Win32, pas seulement pour tel ou tel portage.

Si un module ne fonctionne pas, cela peut être parce que les fonctions qu'il utilise sont spécifiques à UNIX et ne marchent pas sous Win32, ou sont spécifiques à NT/2000 et ne marchent pas sous Windows 95 ou Windows 98.

Comment faire fonctionner un script prévu pour Unix ?

Premièrement, vérifier extrêmement soigneusement que vous utilisez bien le script ou le module comme prévu. Beaucoup d'entre nous sont rapides pour blâmer le module, le système d'exploitation, ou l'interpréteur quand, en réalité, c'est notre propre code qui ne tourne pas.

Si vous êtes sûr que ce n'est pas un problème dans votre code, le meilleur moyen de faire fonctionner un script prévu pour UNIX et de le vérifier avant de l'exécuter. Regardez les points suivants :

Bien sûr, il va sans dire que pour tout ce que vous supprimez, vous devez trouver un moyen de le contourner.

Une fois les modifications faites sur les dépendances UNIX, essayez de lancer le script en mode débuggeur pour voir si les changements faits vous aident. Si le script ou le module est livré avec un fichier test .t, essayez de l'utiliser pour tester votre nouvelle version.

Si vous faites des changements sur un script orienté UNIX, faites le savoir à l'auteur. Bien souvent l'auteur sera suffisamment sympathique pour faire les changements qui rendront le programme compatible Win32. Si l'auteur ne change pas le programme, demandez-lui si vous pouvez diffuser votre version.

Comment fonctionne la fonction chmod() sur les plates-formes Win32 ?

chmod() est supporté par ActivePerl. Cependant, elle ne peut être utilisée que pour fixer les accès lecture/écriture du «propriétaire». (Les bits «groupe» et «others» sont ignorés.)

La sécurité style UNIX pour les fichiers n'est pas applicable aux fichiers sur les systèmes Win32. Les systèmes Win32 héritent du DOS quatre attributs possible pour les fichiers : archivé (A), lecture seule (R), caché (H), et système (S). Ils peuvent être testé et modifiés avec Win32::File::Get/SetAttributes().

Les systèmes Windows NT/2000 utilisant NTFS peuvent aussi avoir des permissions plus spécifiques attribuées individuellement aux fichiers et relatives aux utilisateurs et groupes. Pour les versions 300 et suivantes, et le Kit de Ressources Perl pour Win32, vous pouvez utiliser le module Win32::FileSecurity pour gérer les permissions de fichiers.

4DOS ne reconnaît pas \« sur la ligne de commande.

4DOS ne reconnaît pas le caractère d'échappement quote sur la ligne de commande, parce que tous les caractères double-quote sont vus comme des délimiteurs de paramètres. C'est un des rares points (pas le seul) où 4DOS ne correspond pas à COMMAND.COM.

Pour contourner le problème, vous pouvez saisir

    perl -e "print \"Hello, World\n\""

comme

    perl -e "print qq(Hello, World\n)"

en utilisant le mécanisme Perl de quote alternatif. Les quotes alternatifs sont qq() pour le double-quote, q() pour le simple quote, qx() pour l'anti-quote, et qw() pour le quote de liste. Les parenthèses peuvent être substituées par presque tout (comme + ou | ou {} ou <> ou #), mais cela donne une impression étrange.

STDIN et STDOUT, et les redirections Pipe ne fonctionnent pas toujours sous NT.

Vous pouvez avoir des résultats inattendus quand vous essayez de rediriger les sorties de fichiers qui utilisent la fonctionnalité d'association de Windows NT. Vous pouvez utiliser pl2exe ou pl2bat pour convertir un script en fichier exécutable ou batch. Cela devrait résoudre les problèmes que vous rencontrez avec les redirections.

Pourquoi la gestion des signaux ne marche-t-elle pas sur Windows ?

Les signaux ne sont pas supportés par l'API Win32. Le Runtime C fournit un support brut pour les signaux, mais il y a des limitations sérieuses, telle que l'incapacité à utiliser die() ou exit() dans un gestionnaire de signal. Perl lui-même ne garantit pas que les gestionnaires de signaux n'interrompront pas des opérations critiques telle qu'une allocation de mémoire, ce qui veut dire que l'invocation d'un signal peut mettre le désordre dans les structures internes de perl. Pour ces raisons, les signaux ne sont pas supportés actuellement.

Retour en haut de la page


AUTEUR ET COPYRIGHT

Cette FAQ a été à l'origine assemblée et maintenue par Evangelo Prodromou. Elle a été révisée et mise à jour par Brian Jepson de O'Reilly and Associates, et David Grove et David Dmytryshyn d'ActiveState.

Cette FAQ est dans le domaine public. Si vous l'utilisez, cependant, vérifiez, s'il vous plaît, que vous donniez le crédit aux auteurs originaux.

Retour en haut de la page


VERSION FRANÇAISE

Cette traduction française correspond à la version anglaise distribuée avec perl 5.8.0. Pour en savoir plus concernant ces traductions, consultez http://www.enstimac.fr/Perl/ .

Retour en haut de la page


TRADUCTION EN FRANÇAIS

Fabien Martinet <ho.fmartinet@cma-cgm.com>

Jean-Louis Morel <jl_morel@bribes.org> (mise à jour perl 5.8.0)

Retour en haut de la page

 perlwin32faq5 - Problèmes d'implémentation