Gli script Perl non hanno davvero estensione?

Il consiglio nel libro è perfettamente valido - almeno per i sistemi di tipo UNIX. L'esecuzione dello script è controllata dalla riga #! , non dalla parte di estensione del nome del file. L'utilizzo 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 #! ; al contrario, il metodo utilizzato per aprire un file dipende dall'estensione. Ad esempio, la shell di Windows potrebbe essere configurata in modo che facendo doppio clic su un file .pl (o eseguendola da un prompt) la 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 suffisso .pl richiesto da Windows potrebbe "perdere" su sistemi UNIX-like. Probabilmente è meglio avere un metodo di installazione specifico per il sistema che sceglie un nome appropriato per lo script durante l'installazione.

Su sistemi UNIX-like, un'estensione .pl è in gran parte innocua e, se la trovi utile come promemoria di quale linguaggio è usato da un particolare script (forse hai una collezione di .pl , .py , .sh e .rb script), quindi puoi farlo. Ma ci sono degli svantaggi a tale approccio, come descritto nel libro: se si reimplementa uno script in una lingua diversa, dovrai cambiare il nome e aggiornare qualsiasi cosa lo chiami.

(i moduli Perl devono avere un'estensione .pm in modo che Perl possa trovarli. Per esempio, questo:

use Foo::Bar;

farà in modo che l'interprete cerchi un file denominato Bar.pm in una directory denominata Foo in una delle directory elencate nell'array @INC . Ma i file .pm non sono pensati per essere eseguiti direttamente.)

This is the only source I've seen with this view, everything else I've read has supported the .pl extension.

Lo trovo sorprendente. La maggior parte dei consigli che ho visto dice non per usare l'estensione .pl 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 facoltativa e il punto che l'utente non ha bisogno di conoscere la lingua è corretto al 100% nella maggior parte dei casi.

in esecuzione add 2 3 e il recupero di 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 me stesso) conosca la lingua per qualche motivo.

example.sh o example.pl per mostrare a diversi modi di eseguire lo stesso compito.

Tutto ciò detto però, è più comune non avere un'estensione, ma è tutto gusto.

L'estratto in effetti fornisce un consiglio perfettamente valido.

Vorrei anche aggiungere che per un sistema più piccolo è piuttosto semplice andare oltre e rinominare alcuni file e / o stringhe qua e là in caso di cambiare idea sull'implementazione.

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

In effetti, Python richiede questo design, e di solito lo script principale Python (quello senza estensione nel nome) è costituito da poche righe che fanno il boot di tutta l'app.

Tutto 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 di Ruby usano la stessa convenzione, quindi non hanno bisogno dell'estensione .rb. I compilatori C hanno bisogno solo di un codice C valido, quindi puoi chiamarli .watoozy se lo desideri.

Sebbene non vi sia alcuna limitazione tecnica, esiste il vincolo pratico del principio della sorpresa minima . Fondamentalmente, sarebbe molto sorprendente vedere il codice rubino in un file .pl, quindi le persone generalmente non lo fanno.

L'unica eccezione alla regola

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

L'estratto, tratto dal libro "O'Reilly's Learning Perl, 6th Edition" è spazzatura. Il confronto tra C e Perl non è equivalente, poiché gli avviatori C saranno compilati con un binario, che non ha un'estensione.

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

A parte le best practice, non dovresti inserire il nome completo del file script con estensione ovunque nel tuo sistema, dovresti sempre usare un link simbolico o un alias dipende dal tuo sistema operativo.

In futuro, se hai bisogno di cambiare il file originale, devi solo modificare il link simbolico per puntare alla tua nuova posizione.