Gli script Perl non dovrebbero davvero avere estensione?

Ho appena iniziato a leggere Learning Perl di O'Reilly , 6a edizione e sono rimasto sorpreso quando mi sono imbattuto in questo estratto.

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

Immaginiamo di averlo digitato nel tuo editor di testo. (Non preoccuparti ancora di cosa significano le parti e di come funzionano. Vedrai quelle in un momento.) In genere puoi salvare quel programma con qualsiasi nome desideri. Perl non richiede alcun tipo speciale di nome file o estensione, ed è meglio non usare affatto un'estensione.

Perché è meglio non avere estensione? Immagina di aver scritto un programma per calcolare i punteggi di bowling e di aver detto a tutti i tuoi amici che si chiama bowling.plx. Un giorno decidi di riscriverlo in C. Lo chiami ancora con lo stesso nome, sottintendendo che è ancora scritto in Perl? O dici a tutti che ha un nuovo nome? (E non chiamarlo bowling.c, per favore!) La risposta è che non è affar loro in che lingua è scritto, se lo stanno semplicemente usando. Quindi, in primo luogo, avrebbe dovuto essere chiamato semplicemente bowling.

Questa è l'unica fonte che ho visto con questa vista, tutto il resto che ho letto ha supportato l'estensione .pl. Non sono ancora un programmatore Perl e volevo sapere qual era il punto di vista della community su questo argomento prima di prendere l'abitudine.

I consigli nel libro sono perfettamente validi - almeno per i sistemi simili a UNIX. L'esecuzione dello script è controllata dalla #!riga, non dalla parte dell'estensione del nome del file. L'uso di un'estensione speciale per gli script Perl espone informazioni che non dovrebbero essere importanti per chiunque esegua lo script.

Windows è una questione diversa. Windows non supporta il #!meccanismo; invece, il metodo utilizzato per aprire un file dipende dall'estensione. Ad esempio, la shell di Windows potrebbe essere configurata in modo tale che facendo doppio clic su un .plfile (o eseguendolo da un prompt) lo passerà come argomento all'interprete Perl. L'installazione di un sistema Perl probabilmente lo configurerà automaticamente.

Per gli script Perl destinati a essere portatili, il .plsuffisso richiesto da Windows potrebbe "infiltrarsi" in sistemi simili a UNIX. Probabilmente è meglio avere un metodo di installazione specifico del sistema che scelga un nome appropriato per lo script mentre viene installato.

Su UNIX-like sistemi, un .plprolungamento è per lo più innocui, e se lo trovate utile come promemoria di ciò che il linguaggio è usato da un particolare script (forse avete una collezione di .pl, .py, .sh, e .rbgli script), allora si può fare. Ma ci sono degli svantaggi di questo approccio, come descritto nel libro: se reimplementi uno script in una lingua diversa, dovrai cambiare il nome e aggiornare tutto ciò che lo chiama.

(I moduli Perl devono avere .pmun'estensione in modo che Perl possa trovarli. Ad esempio, questo:

use Foo::Bar;

farà sì che l'interprete cerchi un file chiamato Bar.pmin una directory nominata Fooin una delle directory elencate @INCnell'array. Ma i .pmfile non sono fatti per essere eseguiti direttamente.)

Questa è l'unica fonte che ho visto con questa vista, tutto il resto che ho letto ha supportato l' .plestensione.

Lo trovo sorprendente. La maggior parte dei consigli che ho visto dice di non usare l' .plestensione per gli script eseguibili.

Non importa

#!/usr/bin/perl

indica al sistema quale programma utilizzare per eseguire il codice.

se lo hai cambiato in

#!/usr/bin/bash

o

#!/usr/bin/python

useresti un interprete diverso.

Avere l'estensione è totalmente facoltativo e il punto in cui l'utente non ha bisogno di conoscere la lingua è corretto al 100% nella maggior parte dei casi.

correre add 2 3e tornare indietro 5 è tutto ciò che mi interessa (come utente).

L'unica volta che aggiungo un'estensione agli script è se ho bisogno che l'utente finale (alcune volte io stesso) conosca la lingua per qualche motivo.

esempio.sh o esempio.pl per mostrare a diversi modi per eseguire la stessa attività.

Detto questo, è più comune non avere un'estensione, ma è tutto gusto.

L'estratto fa davvero un consiglio perfettamente valido.

Vorrei anche aggiungere che per un sistema più piccolo è abbastanza banale ripassare e rinominare alcuni file e / o stringhe qua e là in caso di ripensamenti sull'implementazione.

D'altra parte, una tendenza moderna nello sviluppo di sistemi di grandi dimensioni implica avere il file eseguibile principale senza alcuna estensione mentre tutti i moduli da cui dipende hanno ancora l'estensione specifica della lingua.

In effetti, Python lo richiede in base alla progettazione e di solito lo script Python principale (quello senza estensione nel nome) è solo poche righe che avviano l'intero app.

Tutto ciò che il libro ti dice è che su Unix, l'estensione del file non è altro che una convenzione. In realtà, molti tipi di file rientrano in questa categoria. I file Ruby usano la stessa convenzione quindi non hanno bisogno dell'estensione .rb. I compilatori C richiedono solo un codice C valido, quindi puoi nominarli .watoozy se lo desideri.

Sebbene non vi siano restrizioni tecniche, esiste il vincolo pratico del principio della minima sorpresa . Fondamentalmente, sarebbe molto sorprendente vedere il codice ruby ​​in un file .pl, quindi la gente generalmente non lo fa.

L'unica eccezione alla regola

In alcune applicazioni server, lo script di avvio si trova in un file senza estensione per facilitare l'avvio dell'applicazione come servizio. Il file assomiglia a qualsiasi altro comando compilato in quel caso. Finché hai installato Perl, si comporterà anche in questo modo.

L'estratto del libro "O'Reilly's Learning Perl, 6a edizione" è spazzatura. Il confronto tra C e perl non è equivalente, poiché i principianti C saranno compilati in un binario, che non ha estensione.

Perl non verrà compilato, quindi alcuni editor di testo avranno bisogno dell'estensione per identificare il tipo di file.

A parte le migliori pratiche, non è necessario codificare il nome completo dello script con estensione in qualsiasi punto del sistema. Utilizzare sempre un collegamento simbolico o un alias in base al sistema operativo in uso.

In futuro, se è necessario modificare il file originale, è sufficiente modificare il collegamento simbolico per puntare alla nuova posizione.