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

12

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.

Jared
fuente
Como explican las respuestas, la extensión no es importante. Para los scripts (incluido Perl), lo importante es la línea shebang .
1
No señor, no estoy de acuerdo. Sin una extensión de archivo, ¿cómo deciden los editores de IDE y programadores sobre el resaltado de sintaxis?
GrandmasterB
3
@GrandmasterB mirando la línea shebang o leyendo modelinas. Nunca usaría una .plextensión para programas que quisiera distribuir (esa información es ruido, no señal), pero es un recordatorio útil para los scripts locales. De todos modos, esta discusión es irrelevante para> 90% del código Perl, ya que está en un módulo (se .pmrequiere extensión) o en una prueba ( .textensión habitual).
amon
1
@GrandmasterB Desarrollo en Linux, y tanto Vim como Kate identifican correctamente un archivo que comienza con la línea #!/usr/bin/env perlcomo un script de Perl si el archivo no tiene una extensión conflictiva (como .cpp). El fileprograma (usado para deducir un tipo MIME para una entrada dada) deduce correctamente text/x-perlindependientemente de la extensión.
amon
3
En algún momento pensé que se observó que el .pl extensión fue de p erl l ibraries, y de alguna manera se transformó en lo que las personas utilizan para los programas.
brian d foy

Respuestas:

14

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.

Keith Thompson
fuente
1

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.

coteyr
fuente
1

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.

Alexander Shcheblikin
fuente
0

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.

Berin Loritsch
fuente
Los compiladores de C suelen tratar sus archivos de entrada de manera diferente según la extensión. Por ejemplo, golosinas gcc .como código fuente en C, .cpp, .cc, .Ccomo código fuente de C ++, .ocomo un archivo de objeto a ser transmitidos al enlazador, y así sucesivamente. Puede anular eso con una opción de línea de comandos, pero la he usado tan raramente que no recuerdo qué es. La .cextensión para los archivos fuente C es importante. La .plextensión para los scripts ejecutables de Perl no es (al menos en sistemas similares a UNIX).
Keith Thompson
1
@KeithThompson: de hecho, en un sistema Unix compatible con SUS, esas extensiones de archivo son incluso parte de la especificación del c99comando: pubs.opengroup.org/onlinepubs/9699919799/utilities/…
Jörg W Mittag
-4

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.

Aaron Goshine
fuente
La declaración sobre los editores de texto puede ser válida, pero tanto emacs como vim pueden detectar un script Perl sin una extensión especial. Su afirmación sobre la "mejor práctica" sería más convincente con un poco de apoyo. Instalo scripts de Perl en mis sistemas (Linux) sin extensiones todo el tiempo, y nunca ha causado un problema.
Keith Thompson
Sí, por supuesto, tu script se ejecutará si tiene el hash bang ( #!) en línea. Mencionas que trabajas en Linux, lo cual es genial ... la próxima vez que instales una aplicación con un administrador de paquetes, presta mucha atención a cómo también crea un enlace simbólico a su directorio bin en lugar de simplemente escribir el archivo directamente en su bindirectorio ... cada pregunta es por qué.
Aaron Goshine
Tal vez eso depende del administrador de paquetes? En mi sistema Ubuntu 14.04, tengo 325 scripts de Perl instalados directamente debajo /usr/bin, no como enlaces simbólicos; todos fueron instalados por el administrador de paquetes del sistema. El administrador de paquetes tiene su propia base de datos que realiza un seguimiento de las ubicaciones de todos los archivos para cada paquete. (Para el software que construyo desde la fuente, uso enlaces simbólicos). Pero no estoy seguro de qué tiene que ver eso con si los scripts de Perl deberían tener una .plextensión.
Keith Thompson
Creo que podría haber llegado a la cima aquí, el punto que estaba tratando de hacer es.
Aaron Goshine
1
¿Se suponía que había más en ese comentario?
Keith Thompson