Os scripts Perl realmente não devem ter extensão?

Comecei a ler Learning Perl, 6ª edição, da O'Reilly , e fiquei surpreso quando me deparei com este trecho.

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

Vamos imaginar que você digitou isso no seu editor de texto. (Não se preocupe ainda com o que as partes significam e como elas funcionam. Você verá isso em um momento.) Geralmente, você pode salvar esse programa com o nome que desejar. O Perl não requer nenhum tipo especial de nome de arquivo ou extensão, e é melhor não usar nenhuma extensão.

Por que é melhor não ter extensão? Imagine que você escreveu um programa para calcular as pontuações no boliche e disse a todos os seus amigos que se chama boliche.plx. Um dia você decide reescrevê-lo em C. Você ainda o chama pelo mesmo nome, o que implica que ele ainda está escrito em Perl? Ou você diz a todos que tem um novo nome? (E não chame isso de boliche.c, por favor!) A resposta é que não é da conta deles em que idioma está escrito, se eles estão apenas usando. Por isso, deveria ter sido simplesmente chamado de boliche em primeiro lugar.

Essa é a única fonte que eu já vi com essa visualização. Todo o resto que eu li tem suporte para a extensão .pl. Ainda não sou programador Perl e queria saber qual era a visão da comunidade sobre isso antes de me tornar um hábito.

O conselho do livro é perfeitamente válido - pelo menos para sistemas do tipo UNIX. A execução do script é controlada pela #!linha, não pela parte da extensão do nome do arquivo. O uso de uma extensão especial para scripts Perl expõe informações que não devem ser importantes para quem executa o script.

O Windows é uma questão diferente. O Windows não suporta o #!mecanismo; em vez disso, o método usado para abrir um arquivo depende da extensão. Por exemplo, o shell do Windows pode ser configurado para que um clique duplo em um .plarquivo (ou a execução de um prompt) o passe como argumento para o interpretador Perl. A instalação de um sistema Perl provavelmente configurará isso automaticamente para você.

Para scripts Perl destinados a serem portáteis, o .plsufixo exigido pelo Windows pode "vazar" em sistemas semelhantes ao UNIX. Provavelmente, é melhor ter um método de instalação específico do sistema que escolha um nome apropriado para o script quando ele estiver instalado.

No UNIX-like sistemas, a .plextensão é na maior parte inofensivo, e se você achar que é útil como um lembrete de que a linguagem é usada por um script particular (talvez você tem uma coleção de .pl, .py, .sh, e .rbroteiros), então você pode fazer isso. Mas existem desvantagens nessa abordagem, conforme descrito no livro: se você reimplementar um script em um idioma diferente, precisará alterar o nome e atualizar qualquer coisa que o chamar.

(Os módulos Perl precisam ter uma .pmextensão para que o Perl possa encontrá-los. Por exemplo, isto:

use Foo::Bar;

fará com que o intérprete procure um arquivo nomeado Bar.pmem um diretório nomeado Fooem um dos diretórios listados na @INCmatriz. Mas os .pmarquivos não devem ser executados diretamente.)

Esta é a única fonte que eu já vi com essa visualização, tudo o que eu li tem suporte para a .plextensão.

Eu acho isso surpreendente. A maioria dos conselhos que vi diz para não usar a .plextensão para scripts executáveis.

Não importa

#!/usr/bin/perl

informa ao sistema qual programa usar para executar o código.

se você mudou isso para

#!/usr/bin/bash

ou

#!/usr/bin/python

você usaria um intérprete diferente.

Ter a extensão é totalmente opcional, e o ponto em que o usuário não precisa saber o idioma é 100% correto na maioria dos casos.

correr add 2 3e voltar 5 é tudo que me interessa (como usuário).

A única vez que adiciono uma extensão aos scripts é se eu precisar que o usuário final (algumas vezes eu mesmo) conheça o idioma por algum motivo.

example.sh ou example.pl para mostrar maneiras diferentes de realizar a mesma tarefa.

No entanto, é mais comum não ter uma extensão, mas é tudo bom gosto.

O trecho de fato faz um conselho perfeitamente válido.

Eu também acrescentaria que, para um sistema menor, é bastante trivial revisar e renomear alguns arquivos e / ou seqüências de caracteres aqui e ali, no caso de mudar de idéia sobre a implementação.

Por outro lado, uma tendência moderna em desenvolvimento largish sistemas implica ter o arquivo executável principal sem qualquer extensão enquanto todos os módulos que ele depende ainda ter a extensão de idioma específico.

De fato, o Python exige isso por design, e geralmente o script principal do Python (aquele sem extensão no nome) é apenas algumas linhas de inicialização do aplicativo inteiro.

Tudo o que o livro está dizendo é que, no Unix, a extensão do arquivo nada mais é do que uma convenção. Na realidade, muitos tipos de arquivos se enquadram nessa categoria. Os arquivos Ruby usam a mesma convenção para que não precisem da extensão .rb. Os compiladores C precisam apenas de um código C válido, para que você possa nomeá-los como .watoozy se desejar.

Embora não exista restrição técnica, há a restrição prática do princípio da menor surpresa . Basicamente, seria muito surpreendente ver o código ruby ​​em um arquivo .pl, para que as pessoas geralmente não o façam.

A única exceção à regra

Em alguns aplicativos de servidor, o script de inicialização está em um arquivo sem extensão para facilitar a inicialização do aplicativo como um serviço. O arquivo se parece com qualquer outro comando compilado nesse caso. Contanto que você tenha o Perl instalado, ele também se comportará dessa maneira.

O trecho do livro "O'Reilly's Learning Perl, 6ª Edição" é lixo. Comparar C com perl não é equivalente, pois os iniciantes C serão compilados em um binário que não possui extensão.

O Perl não será compilado; portanto, alguns editores de texto precisarão da extensão para identificar o tipo de arquivo.

Como parte das práticas recomendadas, você não deve codificar o nome do arquivo completo do script com extensão em qualquer lugar do sistema. Você sempre deve usar um link simbólico ou um alias depende do sistema operacional.

No futuro, se você precisar alterar o arquivo original, precisará alterar o link simbólico para apontar para seu novo local.