Les scripts Perl ne devraient-ils vraiment pas avoir d'extension?


12

Je viens de commencer à lire Learning Perl d' O'Reilly , 6e édition et j'ai été surpris lorsque j'ai découvert cet extrait.

#!/usr/bin/perl
print "Hello, world!\n";

Imaginons que vous l'ayez tapé dans votre éditeur de texte. (Ne vous inquiétez pas encore de la signification des pièces et de leur fonctionnement. Vous les verrez dans un instant.) Vous pouvez généralement enregistrer ce programme sous le nom de votre choix. Perl ne nécessite aucun type spécial de nom de fichier ou d'extension, et il vaut mieux ne pas utiliser d'extension du tout.

Pourquoi est-il préférable de ne pas avoir d'extension? Imaginez que vous avez écrit un programme pour calculer les scores de bowling et que vous avez dit à tous vos amis qu'il s'appelait bowling.plx. Un jour, vous décidez de le réécrire en C. Vous l'appelez toujours du même nom, ce qui implique qu'il est toujours écrit en Perl? Ou dites-vous à tout le monde qu'il a un nouveau nom? (Et ne l'appelez pas bowling.c, s'il vous plaît!) La réponse est que ce n'est pas leur affaire dans quelle langue il est écrit, s'ils l'utilisent simplement. Donc, cela aurait dû simplement être appelé bowling en premier lieu.

C'est la seule source que j'ai vue avec cette vue, tout le reste que j'ai lu a pris en charge l'extension .pl. Je ne suis pas encore programmeur Perl, et je voulais savoir quel était le point de vue de la communauté à ce sujet avant de prendre l'habitude.


Comme l'expliquent les réponses, l'extension n'est pas importante. Pour les scripts (y compris Perl), l'important est la ligne shebang .

1
Non monsieur, je ne suis pas d'accord. Sans extension de fichier, comment les éditeurs d'IDE et de programmeurs décident-ils de la coloration syntaxique?
GrandmasterB

3
@GrandmasterB en regardant la ligne de shebang, ou en lisant des modelines. Je n'utiliserais jamais une .plextension pour les programmes que je voudrais distribuer (cette information est du bruit, pas du signal), mais c'est un rappel utile pour les scripts locaux. Quoi qu'il en soit, cette discussion n'est pas pertinente pour> 90% du code Perl car il s'agit soit d'un module ( .pmextension requise) ou d'un test ( .textension habituelle).
amon

1
@GrandmasterB Je développe sous Linux, et Vim et Kate identifient correctement un fichier commençant par la ligne #!/usr/bin/env perlcomme un script Perl si le fichier n'a pas d'extension conflictuelle (comme .cpp). Le fileprogramme (utilisé pour déduire un type MIME pour une entrée donnée) déduit correctement text/x-perlquelle que soit l'extension.
amon

3
Quelque part là - bas je pensais que nous avons constaté que la .pl prolongation était de p ERL l ibraries, et en quelque sorte transformé en ce que les gens utilisés pour les programmes.
brian d foy

Réponses:


14

Les conseils contenus dans le livre sont parfaitement valables - du moins pour les systèmes de type UNIX. L'exécution du script est contrôlée par la #!ligne et non par la partie extension du nom de fichier. L'utilisation d'une extension spéciale pour les scripts Perl expose des informations qui ne devraient pas être importantes pour quiconque exécute le script.

Windows est une autre affaire. Windows ne prend pas en charge le #!mécanisme; à la place, la méthode utilisée pour ouvrir un fichier dépend de l'extension. Par exemple, le shell Windows peut être configuré de sorte que double-cliquer sur un .plfichier (ou l'exécuter à partir d'une invite) le transmettra comme argument à l'interpréteur Perl. L'installation d'un système Perl le configurera probablement pour vous automatiquement.

Pour les scripts Perl destinés à être portables, le .plsuffixe requis par Windows peut "fuir" sur des systèmes de type UNIX. Il est probablement préférable d'avoir une méthode d'installation spécifique au système qui choisisse un nom approprié pour le script lors de son installation.

Sous UNIX comme les systèmes, une .plextension est la plupart du temps inoffensifs, et si vous le trouvez utile comme un rappel de ce que le langage est utilisé par un script particulier (peut - être vous avez une collection de .pl, .py, .shet .rbscripts), vous pouvez le faire. Mais il y a des inconvénients à cette approche, comme décrit dans le livre: si vous réimplémentez un script dans une langue différente, vous devrez changer le nom et mettre à jour tout ce qui l'appelle.

(Les modules Perl doivent avoir une .pmextension pour que Perl puisse les trouver. Par exemple, ceci:

use Foo::Bar;

entraînera l'interpréteur à rechercher un fichier nommé Bar.pmdans un répertoire nommé Foosous l'un des répertoires répertoriés dans le @INCtableau. Mais les .pmfichiers ne sont pas destinés à être exécutés directement.)

C'est la seule source que j'ai vue avec cette vue, tout le reste que j'ai lu a pris en charge l' .plextension.

Je trouve cela surprenant. La plupart des conseils que j'ai vus disent de ne pas utiliser l' .plextension pour les scripts exécutables.


1

Peu importe

#!/usr/bin/perl

indique au système le programme à utiliser pour exécuter le code.

si vous avez changé cela en

#!/usr/bin/bash

ou

#!/usr/bin/python

vous utiliseriez un interprète différent.

Avoir l'extension est totalement facultatif, et le point que l'utilisateur n'a pas besoin de connaître la langue est correct à 100% dans la plupart des cas.

courir add 2 3et revenir 5 est tout ce qui m'importe (en tant qu'utilisateur).

La seule fois où j'ajoute une extension aux scripts, c'est si j'ai besoin que l'utilisateur final (parfois moi-même) connaisse la langue pour une raison quelconque.

example.sh ou example.pl pour montrer différentes façons d'accomplir la même tâche.

Cela dit, il est plus courant de ne pas avoir d'extension, mais tout est du goût.


1

L'extrait fait en effet un conseil parfaitement valable.

J'ajouterais également que pour un système plus petit, il est assez trivial de revoir et de renommer quelques fichiers et / ou chaînes ici et là en cas de changement d'avis sur la mise en œuvre.

D'un autre côté, une tendance moderne dans le développement de gros systèmes implique d'avoir le fichier exécutable principal sans extension tandis que tous les modules dont il dépend ont toujours l'extension spécifique à la langue.

En fait, Python l' exige par conception, et généralement le script Python principal (celui sans extension dans le nom) n'est que quelques lignes amorçant l'application entière.


0

Tout ce que le livre vous dit, c'est que sous Unix, l'extension de fichier n'est rien d'autre qu'une convention. En réalité, de nombreux types de fichiers entrent dans cette catégorie. Les fichiers Ruby utilisent la même convention, ils n'ont donc pas besoin de l'extension .rb. Les compilateurs C n'ont besoin que d'un code C valide, vous pouvez donc les nommer .watoozy si vous le souhaitez.

S'il n'y a pas de contrainte technique, il y a la contrainte pratique du principe de la moindre surprise . Fondamentalement, il serait très surprenant de voir du code ruby ​​dans un fichier .pl, donc les gens ne le font généralement pas.

La seule exception à la règle

Dans certaines applications serveur, le script de démarrage se trouve dans un fichier sans extension pour faciliter le démarrage de l'application en tant que service. Dans ce cas, le fichier ressemble à n'importe quelle autre commande compilée. Tant que Perl sera installé, il se comportera également de cette façon.


Les compilateurs C traitent généralement leurs fichiers d'entrée différemment selon l'extension. Par exemple, des friandises gcc .que le code source en C, .cpp, .cc, .Cen tant que code source en C ++, .osous forme de fichier d'objet à être transmis à l'agent de liaison, et ainsi de suite. Vous pouvez remplacer cela avec une option de ligne de commande, mais je l'ai utilisé si rarement que je ne me souviens pas de quoi il s'agit. L' .cextension pour les fichiers source C est importante. L' .plextension pour les scripts Perl exécutables ne l'est pas (au moins sur les systèmes de type UNIX).
Keith Thompson

1
@KeithThompson: en fait, sur un système Unix compatible SUS, ces extensions de fichier font même partie des spécifications de la c99commande: pubs.opengroup.org/onlinepubs/9699919799/utilities/…
Jörg W Mittag

-4

L'extrait du livre «O'Reilly's Learning Perl, 6e édition» est une poubelle. Comparer C à perl n'est pas équivalent, car les démarreurs C seront compilés en un binaire, qui n'a pas d'extension.

Perl ne sera pas compilé, certains éditeurs de texte auront donc besoin de l'extension pour identifier le type de fichier.

En dehors des meilleures pratiques, vous ne devez pas coder en dur le nom de fichier de script complet avec l'extension n'importe où dans votre système. Vous devez toujours utiliser un lien symbolique ou un alias dépend de votre système d'exploitation.

À l'avenir, si vous devez modifier le fichier d'origine, il vous suffit de modifier le lien symbolique pour pointer vers votre nouvel emplacement.


La déclaration sur les éditeurs de texte peut être valide - mais emacs et vim sont capables de détecter un script Perl sans extension spéciale. Votre affirmation sur les "meilleures pratiques" serait plus convaincante avec un certain soutien. J'installe tout le temps des scripts Perl sur mes systèmes (Linux) sans extensions, et cela n'a jamais causé de problème.
Keith Thompson

Oui, bien sûr, votre script s'exécutera s'il a le hash bang ( #!) en ligne, vous mentionnez que vous travaillez sur linux, ce qui est génial .. la prochaine fois que vous installerez une application avec un gestionnaire de paquets, faites très attention à la façon dont il crée également un lien symbolique vers votre répertoire bin au lieu de simplement écrire le fichier directement dans votre binrépertoire .. chaque merveille pourquoi.
Aaron Goshine

Cela dépend peut-être du gestionnaire de paquets? Sur mon système Ubuntu 14.04, j'ai 325 scripts Perl installés directement sous /usr/bin, pas en tant que liens symboliques; ils ont tous été installés par le gestionnaire de paquets du système. Le gestionnaire de packages possède sa propre base de données qui conserve la trace de l'emplacement de tous les fichiers de chaque package. (Pour les logiciels que je construis à partir des sources, j'utilise des liens symboliques.) Mais je ne sais pas ce que cela a à voir avec le fait que les scripts Perl devraient avoir une .plextension.
Keith Thompson

Je pense que peut-être allé de haut ici, le point que j'essayais de faire est.
Aaron Goshine

1
Devait-il y avoir plus à ce commentaire?
Keith Thompson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.