Na wikipedia, o artigo para .sh diz:
For the .sh file extension type, see Bourne shell.
Que tal outras shells unix?
Eu sei que o shebang é usado dentro do arquivo para indicar um intérprete para execução, mas eu me pergunto:
.sh independentemente de qual shell eles são executados? Eu só chamaria .sh de algo que é significado para ser portável (e esperamos que seja portátil).
Caso contrário, acho melhor esconder a linguagem. O leitor atento vai encontrá-lo na linha shebang de qualquer maneira. (Na prática, .bash ou .zsh , etc ... sufixos são raramente usados.)
Eu diria que não existem "boas práticas" para extensões de arquivos, estritamente em um aspecto técnico: os sistemas de arquivos Unix / Linux / * BSD não suportam extensões per se. O que você está chamando de extensão é meramente um sufixo de um único nome de arquivo. Isso é diferente dos sistemas de arquivos e sistemas operacionais VM / CMS, VMS, MS-DOS e Windows, onde um ponto especial no inode-moral-equivalent é reservado para uma extensão.
Esse pequeno discurso agora acabou, acho um pouco ridículo colocar um sufixo ".sh" ou ".ksh" ou ".bash" em um nome de arquivo de script de shell. Um programa é um programa: não existe benefício em distinguir o que é executado. Nenhum unix ou linux ou qualquer kernel decidiu chamar um interpretador em algum arquivo apenas por causa de um sufixo de nome de arquivo. Tudo é feito pela linha #! , ou alguma outra sequência de bytes "número mágico" no início do arquivo. Na verdade, decidir o que executar com base em um nome de arquivo "extensão" é um dos fatores que torna o Windows um ímã de malware. Veja quantos scams de malware do Windows envolvem um arquivo chamado "something.jpg.exe" - por padrão, o Windows mais recente não mostra a extensão ".exe" e incentiva o usuário a clicar duas vezes na "imagem". Em vez de uma exibição de imagem em execução, o malware é executado.
O que você pode pensar como um comando direto é geralmente um script de shell. Às vezes cc tem sido um script sh, firefox é um script sh, startx é um script sh. Não acredito que exista um benefício cognitivo ou organizacional para marcar um script com o sufixo ".sh".
Como alguém que trabalhou em uma infinidade de ambientes em nix, tive que escrever em uma grande variedade de shells. Acredite ou não, através das plataformas, as conchas não são as mesmas. Então, se você mantiver sua biblioteca pessoal em múltiplos shells (quando necessário), é muito útil usar extensões para identificar os shells. Dessa forma, quando você muda para outra plataforma e o shell é um pouco diferente, você sabe quais scripts serão direcionados para modificações. .sh .ksh .bsh .csh ...
Como você disse, as extensões de arquivo Unix são puramente informações. Você só precisa do seu script para ter um shebang correto e ser executável.
Você pode não ter nenhuma extensão ou usar .sh .
Eu pessoalmente uso as seguintes convenções, independentemente do shell usado (csh, tcsh, bash, sh, ...):
.sh para scripts clássicos, de baixo a alto grau. Extensões de script de shell são bastante úteis. Por exemplo, eu freqüentemente escrevo scripts que possuem múltiplos arquivos em vários idiomas (por exemplo, bash, awk e lua) no mesmo diretório. Se eu precisar procurar uma string apenas nos arquivos bash, a extensão torna isso muito útil para reduzir os falsos positivos. Ou se eu quiser fazer uma contagem de linha de todo o meu código bash para esse projeto.
É difícil digitar a extensão ao executar o programa, portanto, também faço um link simbólico sem a extensão para o executável principal, para editá-lo / executá-lo sem precisar digitar a extensão toda vez. Os links simbólicos são baratos e fáceis.
Você não deve usar uma extensão para executáveis, pois eles não são intercambiáveis. Imagine que você tenha um script de shell a.sh e, em seguida, reescreva em python a.py , agora você precisa alterar cada programa que chama seu script, vazou detalhes de implementação.
Toda a extensão de nome de arquivo no Windows do Mircosoft é uma bagunça: por exemplo, o que poderia ter sido a.audio, b.audio, c.audio , poderia ser a.mp3, b.wav, c.ogg e d.picture, e.picture, f.picture é d.jpeg, e.png, f.gif . Na maioria das vezes não nos importamos com o formato do áudio ou da imagem. Também precisamos passar muito tempo ensinando aos novos usuários todas as extensões de arquivo.
Como outros já disseram, o shell não se importa com extensões. No entanto, permite a rápida identificação humana de arquivos. Eu vejo arquivos terminando em .py ou .sh e eu rapidamente sei o que eles (pelo menos) deveriam ser. Como Steve diz, pesquisar por extensão de arquivo ou fazer uma contagem de linhas também são considerações práticas.