Je suis en train de répondre à une demande d'adjudication sur un contrat nécessitant une quantité décente de traitement de texte. Le principal problème est que le client souhaite pouvoir exécuter cela sur n'importe quel Unix (HPUX, Solaris, AIX, FreeBSD) ou Linux (SLES, RHEL) plate-forme, qui peut contraindre ce que j'utilise pour le faire. Ils ne veulent pas faire l'installation d'outils supplémentaires une condition préalable.
Je suis déchiré entre Perl et Awk. Je sais que Perl est un outil idéal pour le traitement de texte (et je suis raisonnablement habile à cela) mais, avant de mettre dans la réponse de RFT que Perl sera nécessaire, j'aimerais savoir si quelqu'un est exécuté sur une plate-forme où Perl n'est pas installé par défaut.
Il serait utile de répertorier ces plates-formes dans le RFT et de donner au client l'option de quelle manière ils veulent aller. J'ai un souvenir vague que ce n'est pas sur FreeBSD dans l'installation par défaut et peut également être que les plates-formes non linux ne l'ont pas non plus.
Tous les autres outils peuvent être suggérés mais, étant donné ma familiarité avec Perl et Awk, ils seront probablement les seuls à la liste restreinte.
6 Réponses :
Presque tous les * Nix (sauf certains pour un espace disque très limité) a Perl installé. Afaik, même Freebsd. Juste au cas où il ne serait pas, vous pouvez transformer le programme PERL en une exécutable qui n'aura pas besoin de Perl avec Par :: Packer .
@Sinan, je suppose que "même BSD" puisque j'avais une pensée vague, ils ne l'avaient pas expédiés en standard, mais à travers les ports.
@Pax duh! Sa réponse a du sens alors. J'ai utilisé FreeBSD depuis la version 5 et toutes les personnes avaient été installées par défaut. Le système Perl avait tendance à être plus ancien que les ports Perl, mais il existe un script shell qui permet à la racine de sélectionner laquelle Perl sera par défaut.
Bon, c'est probablement ce que j'étais (mal) en me souvenant. La plupart du code seront jolies par Perl (je ne fais même pas d'objets), alors devrait courir, même sur Perl 4, si nécessaire.
Même si Perl peut être installé sur presque toutes les plateformes * Nix, ils pourraient ne pas être la même version, alors en soyez conscient. Avec l'exigence qu'il faut fonctionner sur la plupart des informations * Nix, vous pouvez simplement coder avec Shell + Utilities. Pour analyser les fichiers, AWK + Shell peut également faire le travail. Il vous suffit de l'écrire dans un format "portable". Vérifiez Ce out Pour plus d'informations
L'un des objectifs de Perl (contrairement à de nombreuses autres langues) est d'être très compatible entre les versions. Il est donc nécessaire d'écrire pour une version minimale.
Je suppose que ce serait Perl 5.6.
Il y a quelques plates-formes (très étrange) qui n'ont pas de bons ports Perl au-delà de 5,004, mais généralement 5.6 est une bonne cible - elle a été utilisée depuis 2000.
Si le client n'a pas de Perl sur leurs machines, vous pouvez toujours utiliser PAR :: PACKER pour créer un exécutable pour cette plate-forme. Cela signifie également que vous n'avez pas à vous soucier de l'utilisation de modules, car ils seront également inclus dans l'exécutable.
Soyez averti si le module utilise spécifiquement une licence non autoristive comme AGPL ou quelque chose. Vous devrez réellement distribuer le code source des modules que vous utilisez. Pas difficile, mais cela peut être une douleur.
HMM, je dirais celui-ci, vous pouvez récupérer la source de l'exécutable et, tant que vous ne le modifiez pas, CPAN doit compter comme la source disponible.
@Weegee, par :: Packer zips simplement les fichiers, il est donc trivial d'extraire n'importe quel code. LGPL peut exiger que vous permettions à l'utilisateur de construire de nouveaux exécutables avec leur code modifié, ce qui pourrait être un problème. Le moyen le plus simple de faire face à cela est d'inclure toutes les bibliothèques concernées dans un fichier par séparé. Votre fichier principal peut alors charger le fichier secondaire.
Bien que je suppose que toutes les versions actuelles des systèmes d'exploitation que vous mentionnez Installez Perl, il y aura bien sûr des versions plus anciennes autour de cela et non. Vous devez également savoir que même des outils tels que AWK n'étaient pas régulièrement installés sur des versions très anciennes ONU * X, car elle et d'autres outils de programmation étaient des extras facultatifs (à des frais supplémentaires). Je me souviens des systèmes Altos où même la pile TCP / IP était un élément de coût supplémentaire, mais vous n'allez probablement pas aller aussi loin: -)
Bottom Line: Si votre application a besoin vraiment de Perl, vous devez vérifier qu'il est installé (via un script de shell de Bourne - si vous ne fonctionne pas, vous êtes vraiment vissé) et si vous ne fournissez pas une certaine manière l'installer.
Vous pouvez obtenir une version de Perl compilée pour n'importe quelle variante UNIX. Perl n'a pas besoin d'être "installé", mais peut exécuter à l'intérieur du répertoire de votre application. Je voudrais regrouper Perl avec ma distribution. Vous pouvez donc vous assurer que vous exécutez la même version.
Il est très difficile d'écrire un script de shell de plate-forme complètement croisé, sans tester sur le système d'exploitation cible. Si vous développez un script AWK, vous allez probablement développer à l'aide de la variante GNU sur Linux, qui est un superset du posix awk . Je configure souvent la source d'ouverture Packages sur Solaris , et je trouve constamment Problèmes où les gens assument votre version de la version moderne d'un outil. Par exemple, sur Solaris Bash n'est pas la coque de Bourne standard (/ bin / sh) et ECHO ne prend aucun paramètre. Si vous essayez de coder avec POSIX AWK, vous vous trouverez peut-être limité par la bibliothèque Regex ou sur les conventions datées.
Les licences artistiques de Perl e vous permettent de l'emballer avec Votre programme, aussi longtemps que vous suivez quelques éléments simples comme garder le droit d'auteur en tact.
En fait, c'est une bonne idée (regrouper dans un sous-répertoire) car cela me permet de contrôler la version bien que je doive expédier plusieurs packages (ou un paquet avec de nombreux sous-répertoires PERL sélectionnés au moment de l'exécution, une par plate-forme). Je vais vérifier la licence. +1.
Tous n'ont pas Perl :)
mmd-sparc% cat /etc/motd Sun Microsystems Inc. SunOS 5.6 Generic August 1997 mmd-sparc% which perl no perl in /usr/bin . mmd-sparc% mmd-sparc% uname -a SunOS mmd-sparc 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5 mmd-sparc% date Mon Jun 3 10:11:22 EDT 2019
Les unités commerciales ont tendance à être groupées avec de très anciennes versions de Perl.