Eu tenho um monte de scripts executáveis enrolados à mão no meu diretório $ HOME / bin. Alguns são escritos em bash, alguns em Ruby. Todos eles têm a linha shebang no topo dizendo ao shell que interpretador usar (bash ou Ruby, no meu caso).
Gostaria de saber se é melhor colocar extensões de arquivo nesses scripts para indicar em qual linguagem de script eles estão escritos? Por exemplo, os scripts em Ruby teriam o sufixo * .rb e os bash teriam o sufixo * .sh.
Atualmente, esses scripts têm nomes simples, sem extensão de arquivo.
Qual é a melhor prática?
Você pode executar comandos curinga como ls *.rb ou cp *.sh se quiser organizar seus scripts no futuro.
Comece cedo ou lamente depois, na minha opinião.
Editores como vim também poderão aplicar o realce de sintaxe correto com base em ou arquivo extensão.
Isso também pode ser feito usando modelines em vários editores. Por exemplo. para vim:
# vim: ft=sh
Bem - como a maioria das coisas na vida: depende de suas necessidades.
Você afirmou que esses scripts residem em um diretório bin e suponho que esses scripts devem ser chamados a partir da linha de comando. Como usuário eu considero irritante se eu tenho que digitar bla.ksh ou foo.bash. Além disso, se o codificador decide mover para anular outro intérprete, o nome do comando também mudaria e eu teria que corrigir outros scripts que fazem uso dessas ferramentas - muito irritante, mesmo se usuário e codificador são a mesma pessoa.
Mas, por outro lado, uso extensões como .sh ou .tcl em meus diretórios de criação de projetos. Dessa forma, posso usar os recursos make para implantar os arquivos em seus diretórios de destino - mas, neste estágio, removo o sufixo do arquivo.
Obviamente, existem algumas diferenças entre arquivos executáveis nos diretórios bin e arquivos "fonte" editáveis.
#! . .pm , .sh ou .so em tais casos. No caso de um programa compilado, a diferença entre "source" e "executable" é óbvia: um contém código-fonte, o outro contém linguagem de máquina ou bytecode interpretado. No caso de um script, não há nenhuma diferença óbvia, mas o comando make mantém uma separação nocional entre o "código-fonte de um script" e a "versão executável de um script": seu "compilador" padrão para "script de shell" "é simplesmente cp .
Eu recomendaria manter um diretório $HOME/source separado e:
ln -s ../source/foo.sh $HOME/bin/foo ; ou install -m 755 foo.sh ../bin/foo ; ou Makefile para executar uma verificação de sintaxe antes de copiar o arquivo de origem de $HOME/source para $HOME/bin
Nota de rodapé: um módulo de script de shell só pode ser usado por outro script de shell e modifica o contexto interno desse script usando os comandos internos . ou source . Isso é diferente de um script executável, que (como qualquer programa) é executado como um processo separado e não pode modificar seu processo pai. Como uma convenção aproximada, os módulos vão em /usr/lib/name_of_program/name_of_module.sh enquanto os comandos vão em /usr/bin/name_of_command (sem nenhum sufixo).
Não é necessário. O kernel já está informado do intérprete correto a ser usado (pela linha #! ), e todos os editores de texto populares também o lêem, então adicionar uma extensão não faria nada útil, apenas aumentaria a digitação. A única vez que um programa executável tem uma extensão é quando é de alguma forma importante (para o programa ou o usuário ou ambos).
Módulos e bibliotecas, por outro lado, quase sempre têm extensões ( .rb para módulos Ruby, .so para bibliotecas compartilhadas ELF e assim por diante).
Tags bash shell-script script