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

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.

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.

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.

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.

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.

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.