¿Deberían los scripts de Perl realmente no tener extensión?

Recién comencé a leer O'Reilly's Learning Perl, 6ª edición y me sorprendió cuando me encontré con este extracto.

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

Imaginemos que ha escrito eso en su editor de texto. (No se preocupe aún por lo que significan las partes y cómo funcionan. Lo verá en un momento). En general, puede guardar ese programa con el nombre que desee. Perl no requiere ningún tipo especial de nombre de archivo o extensión, y es mejor no usar una extensión.

¿Por qué es mejor no tener extensión? Imagine que ha escrito un programa para calcular los puntajes de boliche y les ha dicho a todos sus amigos que se llama bowling.plx. Un día decides reescribirlo en C. ¿Todavía lo llamas con el mismo nombre, lo que implica que todavía está escrito en Perl? ¿O les dice a todos que tiene un nuevo nombre? (¡Y no lo llames bowling.c, por favor!) La respuesta es que no es asunto de ellos en qué idioma está escrito, si simplemente lo usan. Por lo tanto, debería haberse llamado simplemente bolos en primer lugar.

Esta es la única fuente que he visto con esta vista, todo lo demás que he leído ha admitido la extensión .pl. Todavía no soy un programador de Perl, y quería saber cuál era la opinión de la comunidad sobre esto antes de adquirir un hábito.

El consejo del libro es perfectamente válido, al menos para sistemas similares a UNIX. La ejecución del script está controlada por la #!línea, no por la parte de extensión del nombre del archivo. El uso de una extensión especial para los scripts de Perl expone información que no debería ser importante para cualquiera que ejecute el script.

Windows es un asunto diferente. Windows no es compatible con el #!mecanismo; en cambio, el método utilizado para abrir un archivo depende de la extensión. Por ejemplo, el shell de Windows podría configurarse de modo que hacer doble clic en un .plarchivo (o ejecutarlo desde un indicador) lo pase como argumento al intérprete de Perl. La instalación de un sistema Perl probablemente lo configurará automáticamente.

Para los scripts de Perl destinados a ser portátiles, el .plsufijo requerido por Windows podría "filtrarse" en sistemas similares a UNIX. Probablemente sea mejor tener un método de instalación específico del sistema que elija un nombre apropiado para el script cuando esté instalado.

En sistemas similares a Unix, una .plextensión es en su mayoría inofensivas, y si le resulta útil como un recordatorio de lo que el lenguaje es utilizado por un script en particular (tal vez usted tiene una colección de .pl, .py, .sh, y .rbguiones), entonces usted puede hacer eso. Pero hay inconvenientes en ese enfoque, como se describe en el libro: si vuelve a implementar un script en un idioma diferente, tendrá que cambiar el nombre y actualizar todo lo que lo llame.

(Los módulos de Perl deben tener una .pmextensión para que Perl pueda encontrarlos. Por ejemplo, esto:

use Foo::Bar;

hará que el intérprete busque un archivo nombrado Bar.pmen un directorio nombrado Fooen uno de los directorios enumerados en la @INCmatriz. Pero los .pmarchivos no deben ejecutarse directamente).

Esta es la única fuente que he visto con esta vista, todo lo demás que he leído ha admitido la .plextensión.

Me parece sorprendente. La mayoría de los consejos que he visto dice que no use la .plextensión para scripts ejecutables.

No importa

#!/usr/bin/perl

le dice al sistema qué programa usar para ejecutar el código.

si cambiaste eso a

#!/usr/bin/bash

o

#!/usr/bin/python

usarías un intérprete diferente.

Tener la extensión es totalmente opcional, y el punto de que el usuario no necesita saber el idioma es 100% correcto en la mayoría de los casos.

correr add 2 3y recuperar 5 es todo lo que me importa (como usuario).

La única vez que agrego una extensión a los scripts es si necesito que el usuario final (algunas veces yo mismo) conozca el idioma por alguna razón.

example.sh o example.pl para mostrar diferentes formas de realizar la misma tarea.

Todo lo dicho, sin embargo, es más común no tener una extensión, pero todo es gusto.

El extracto de hecho hace un consejo perfectamente válido.

También agregaría que, para un sistema más pequeño, es bastante trivial revisar y cambiar el nombre de algunos archivos y / o cadenas aquí y allá en caso de cambiar de opinión sobre la implementación.

Por otro lado, una tendencia moderna en el desarrollo de sistemas de gran tamaño implica tener el archivo ejecutable principal sin ninguna extensión, mientras que todos los módulos de los que depende aún tienen la extensión específica del idioma.

De hecho, Python requiere esto por diseño, y generalmente la secuencia de comandos principal de Python (la que no tiene extensión en el nombre) es solo unas pocas líneas de arranque de toda la aplicación.

Todo lo que el libro te dice es que en Unix, la extensión del archivo no es más que una convención. En realidad, muchos tipos de archivos pertenecen a esta categoría. Los archivos Ruby usan la misma convención para que no necesiten la extensión .rb. Los compiladores de C solo necesitan un código C válido, por lo que puede nombrarlos .watoozy si lo desea.

Si bien no hay restricción técnica, existe la restricción práctica del principio de menor sorpresa . Básicamente, sería muy sorprendente ver el código ruby ​​en un archivo .pl, por lo que la gente generalmente no hace eso.

La única excepción a la regla.

En algunas aplicaciones de servidor, el script de inicio está en un archivo sin extensión para facilitar el inicio de la aplicación como servicio. El archivo se parece a cualquier otro comando compilado en ese caso. Mientras tenga instalado Perl, también se comportará de esa manera.

El extracto, del libro "O'Reilly's Learning Perl, 6th Edition" es basura. Comparar C con perl no es equivalente, para empezar, C se compilará en un binario que no tiene una extensión.

Perl no se compilará, por lo que algunos editores de texto necesitarán la extensión para identificar el tipo de archivo.

Como parte de las mejores prácticas, no debe codificar el nombre de archivo completo de la secuencia de comandos con extensión en ninguna parte de su sistema, siempre debe usar un enlace simbólico o un alias depende de su sistema operativo.

En el futuro, si necesita cambiar el archivo original, solo necesita cambiar el enlace simbólico para que apunte a su nueva ubicación.