| perlwin32faq5 - Problèmes d'implémentation |
chmod() sur les plates-formes Win32 ?
perlwin32faq5 - Problèmes d'implémentation
Sujets spécifiques au portage Win32 de Perl.
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 :
alarm(), getpgrp(), getppid(), getpriority(),
setpgrp(), setpriority()
endgrent(), endpwent(), getgrent(), getgrgid(),
getgrnam(), getpwent(), getpwnam(), getpwuid(),
setgrent(), setpwent()
msgctl(), msgget(), msgrcv(), msgsnd(), semctl(),
semget(), semop(), shmctl(), shmget(), shmread(),
shmwrite()
link(), symlink(), chroot()
syscall()
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.
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).
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.
Il devrait y avoir peu de différences entre les deux systèmes. Vous pouvez cependant surveiller les points suivants :
flock().
Finalement, beaucoup de programmes utiles disponibles sous Windows NT
ne le sont pas sous Windows 95. hostname, par exemple n'est pas
disponible sous Windows 95.
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 ?.
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.
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.
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 :
system() ou backtick (``) à des outils systèmes indisponibles pour
ActivePerl.
Lecture et écriture de fichiers qui peuvent être binaires.
Voir Lire où écrire sur des fichiers échoue mystérieusement. Que se passe-t-il ?.
Noms de chemins ou découpes de noms de chemins dépendants du système de fichiers.
Cherchez les chemins UNIX comme /usr/lib codés en dur.
Le module ou script requiert peut-être une version spécifique de Perl ou un autre
module. Cherchez les choses comme require 5.003; ou require Sockets 1.03;.
Vérifiez pour voir si le script ou module nécessite vraiment la nouvelle version.
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.
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 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.
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.
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.
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.
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/ .
Fabien Martinet <ho.fmartinet@cma-cgm.com>
Jean-Louis Morel <jl_morel@bribes.org> (mise à jour perl 5.8.0)
| perlwin32faq5 - Problèmes d'implémentation |