Devo colocar extensões de arquivo * .sh e * .rb em todos os meus scripts?

Eu tenho um monte de scripts executáveis ​​manualmente no meu diretório $ HOME / bin. Alguns são escritos em bash, outros em Ruby. Todos eles têm a linha shebang na parte superior, informando ao shell qual intérprete 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 apenas nomes simples, sem extensão de arquivo.

Qual é a melhor prática?

Você pode executar comandos curinga como ls *.rbou cp *.shse desejar organizar seus scripts no futuro.

Comece cedo ou se arrependa mais tarde, na minha opinião.

Editores como vimtambém poderão aplicar o realce de sintaxe correto com base no shebang ou na extensão do arquivo.

Isso também pode ser feito usando modelines em vários editores. Por exemplo, para o vim:

# vim: ft=sh

Bem - como a maioria das coisas na vida: depende de suas necessidades.

Você declarou que esses scripts residem em um diretório bin e presumo que esses scripts sejam chamados na linha de comando. Como usuário , considero irritante se precisar digitar bla.ksh ou foo.bash. Além disso, se o codificador decidir mudar para outro intérprete, o nome do comando também mudaria e eu teria que alterar outros scripts que fazem uso dessas ferramentas - muito irritante, mesmo que usuário e codificador sejam a mesma pessoa.

Mas, por outro lado, uso extensões como .sh ou .tcl nos diretórios de construção do meu projeto. Dessa forma, eu 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 ​​em bindiretórios e arquivos "de origem" editáveis.

• Para arquivos de origem, é útil ter um sufixo para que você possa ver o que é o quê e ajudar algumas ferramentas menos inteligentes que não conseguem varrer a #!linha.
• Para módulos, eles são usados ​​apenas por um conjunto de programas relacionados, todos os quais usam o mesmo intérprete (ou nenhum intérprete), e é convencional incluir .pm, .shou .sonesses casos.
• Para programas executáveis, seu nome faz parte do "contrato de programação" pelo qual os usuários e outros scripts o invocam. É importante que o nome não mude, mesmo que a implementação mude ; então, obviamente, o nome do arquivo não deve ter um sufixo

No caso de um programa compilado, a diferença entre "origem" e "executável" é óbvia: uma contém código fonte, a outra contém linguagem de máquina ou interpretado por código. No caso de um script, não há diferença óbvia, mas o makecomando 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 "shell script" é simplesmente cp.

Eu recomendaria manter um $HOME/sourcediretório separado e:

• mantendo um link simbólico, como feito por ln -s ../source/foo.sh $HOME/bin/foo; ou
• copie-os manualmente após fazer alterações (e testá-los), usando install -m 755 foo.sh ../bin/foo; ou
• usando uma Makefileregra para executar uma verificação de sintaxe antes de copiar o arquivo de origem $HOME/sourcepara o$HOME/bin

Nota de rodapé: um módulo de script de shell é utilizável apenas 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 convenção geral, os módulos entram /usr/lib/name_of_program/name_of_module.shenquanto os comandos entram /usr/bin/name_of_command(sem nenhum sufixo).

Não é necessário. O kernel já está informado sobre o intérprete correto a ser usado (pela #!linha), e todos os editores de texto populares também o leem, portanto, adicionar uma extensão não faria nada útil, apenas aumentava 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 ( .rbpara módulos Ruby, .sopara bibliotecas compartilhadas ELF e assim por diante).