Extensões de arquivo para scripts de shell do Unix [fechado]

Eu só chamaria .sh algo que é destinado para ser portátil (e esperançosamente é portátil).

Caso contrário, acho que é melhor esconder a linguagem. O leitor cuidadoso irá encontre-o na linha shebang de qualquer maneira. (Na prática, .bash ou .zsh, etc … sufixos raramente são usados.)

Comentários

• Somente nesta página, já podemos ver uma quantidade não trivial de pessoas usando. Por que você diz que eles são " raramente usado "? Alguma citação? Ou é apenas baseado na sua experiência?
• Eu usaria .bash se ' é para ser fornecido por outro script e é compatível apenas com bash, etc. Se ele puder ser obtido por qualquer shell compatível com bourne, como sh, dash , ou bash, eu daria a ele uma extensão .sh. Se ' fosse para ser executado, eu não ' colocaria uma extensão.

Eu diria que não existem “boas práticas” para extensões de arquivo, estritamente por uma questão técnica: Unix / Linux / * sistemas de arquivos BSD não suporte a extensões em si. 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 há um ponto especial no inode- equivalente moral é reservado para uma extensão.

Aquele pequeno discurso agora acabou, eu acho “um pouco bobo colocar um sufixo” .sh “ou” .ksh “ou” .bash “em um shell nome do arquivo de script. Um programa é um programa: nenhum benefício existe em distinguir o que é executado. Nenhum unix ou linux ou qualquer outro kernel decidiu chamar um interpretador em algum arquivo apenas por causa de um sufixo de nome de arquivo. É tudo feito pelo #! linha, ou alguma outra sequência de “número mágico” de bytes no início do arquivo. Na verdade, decidir o que executar com base em uma “extensão” de nome de arquivo é um dos fatores que tornam o Windows um ímã de malware. Veja quantos golpes 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 incentive o usuário a apenas clicar duas vezes na “imagem”. 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 de qualquer maneira. Às vezes, cc foi um sh-script, firefox é um sh-script, startx é um sh-script. Não acredito que haja um cognitivo ou benefício organizacional em marcar um script com um sufixo “.sh”.

Comentários

• Eu discordo! Meu trabalho consiste em empacotar um aplicativo envolvendo milhares de arquivos que variam de executáveis binários a scripts de shell (ksh, bash e alguns csh legados). Para mim, acredite em mim faz a diferença ser capaz de saber em um piscar de olhos (ou em um regex) o que tipo de arquivo que estamos discutindo e que estamos procurando. Meu ponto é que poderia b e um benefício em distinguir o que é executado e uma prática recomendada deve encorajar a declaração explícita do tipo de arquivo.
• @rahmu: escreva isso como uma resposta. Dê alguns detalhes sobre como nomes distinguíveis de regex ajudam a empacotar (e talvez manter) esse aplicativo. Observe especificamente a interação entre o que interpreta o arquivo e o sufixo do nome do arquivo ' e como isso o ajuda a realizar as tarefas. Eu ' estou interessado em argumentos sérios contra meu ponto de vista e ' estou disposto a mudar se ' estou convencido. Votei positivamente em seu comentário para provar isso.
• Eu adoraria, infelizmente só posso falar de minha experiência atual em meu trabalho atual.Eu não ' não sei muito sobre boas práticas e padrões em geral ; Acho que devo fazer alguma pesquisa antes de postar uma resposta aqui. Eu ' examinarei isso hoje à noite depois do trabalho 🙂
• @rahmu O " arquivo existe para determinar o tipo de arquivo. É capaz de distinguir scripts escritos para diferentes shells.
• Se você der a um script de shell uma extensão .sh, você ' terá que digitar isso .sh como parte do nome do comando ao iniciá-lo. Essa ' é a principal razão pela qual eu não ' não gosto de inserir essa extensão (mesmo com qualquer coisa que tenha uma linha shebang). BTW, o problema no Windows não é o prefixo .exe em si (é ' trivial criar um executável chamado image.jpg no Linux, afinal), mas o fato de o Windows geralmente ocultar essa extensão, combinado com o fato de que a ação necessária para iniciar um executável e abrir um documento é exatamente a mesma.

Como alguém que trabalhou em vários ambientes? nix, tive que escrever em uma grande variedade de cartuchos. Acredite ou não, entre as plataformas, as conchas não são as mesmas. Portanto, se você mantém sua biblioteca pessoal em vários shells (quando necessário), é muito útil usar extensões para identificar os shells. Dessa forma, quando você muda para outra plataforma e o shell é ligeiramente diferente, você sabe quais scripts direcionar para modificações. .sh .ksh .bsh .csh …

Comentários

• Isso parece concordar com unix.stackexchange.com/questions/31760/ …
• Você não tem um #! no início do script (por exemplo, #!/bin/bash)?
• Gnu / Linux, BSD e os UNIXes são todos Unix. Não há necessidade de? Nix. Linux é um kernel, o Android usa Linux, mas não é Unix (a menos que você adicione um software extra, caso em que você tem um aplicativo Unix).
• @ ctrl-alt-delor: " Unix " é uma marca comercial . As pessoas costumam usar "? Nix " para evitar o problema de marca registrada (e os pedantes).
• @JS ` UNIX ' é uma marca comercial do The Open Group. Unix e unix não são greens.org/about/unix.html

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 reescreva em python a.py, agora você precisa alterar todos os programas que chamam seu script , você vazou detalhes de implementação.

Toda a extensão de nome de arquivo no Windows da Mircosoft é uma bagunça: por exemplo, o que poderia ter sido a.audio, b.audio, c.audio, é 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 o áudio ou a imagem estão inseridos. Também temos que passar muito tempo ensinando aos novos usuários todas as extensões de arquivo.

Comentários

• Outra razão para não para usar *.sh que acabei de descobrir é que o Debian ' s run-parts ganhou ' t execute scripts com extensões, como em /etc/cron.*/: archive.oreilly.com/pub /post/runparts_scripts_a_note_about.html

Como você disse, as extensões de arquivo Unix são puramente informações. Você só precisa que seu script tenha um shebang correto e seja executável.

Você pode não ter extensão ou usar .sh.

I use pessoalmente as seguintes convenções, independentemente do shell usado (csh, tcsh, bash, sh, …):

• nenhuma extensão para sistema ou scripts de alto grau (extremamente raro).
• o .sh para scripts clássicos, de baixo a alto grau.

Comentários

• O que você quer dizer com " scripts clássicos, de baixo a alto grau "?
• Eu acho Eu quis dizer abstração ou nível de organização com isso. Ou seja, você não ' se importa com a ferramenta de linguagem / script usada por trás de alguns comandos: portanto, você não ' usa qualquer extensão. Para outros, é bom saber que é um bash ou algum script de shell ksh exótico (com a extensão apropriada). … mas isso foi há 2 anos;)

As extensões de script de shell são bastante úteis. Por exemplo, costumo escrever scripts que têm vários arquivos em vários idiomas (por exemplo,bash, awk e lua) no mesmo diretório. Se eu precisar pesquisar uma string apenas nos arquivos bash, a extensão torna isso muito útil para reduzir falsos positivos. Ou se eu quiser fazer uma contagem de linha de todo o meu código bash para esse projeto.

É uma dor ter que digitar a extensão ao executar o programa, então 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 a cada vez. Symlinks são baratos e fáceis.

Comentários

• Isso parece concordar com unix.stackexchange. com / questions / 31760 / …

Como já foi dito, o shell não se preocupa com extensões. No entanto, ele permite a rápida identificação humana de arquivos. Vejo arquivos que terminam em .py ou .sh e eu rapidamente sei o que eles (pelo menos) deveriam ser. Como Steve disse, pesquisar por extensão de arquivo ou fazer uma contagem de linha também são considerações práticas.