Extensões de arquivo para scripts shell unix [fechado]

45

Na wikipedia, o artigo para .sh diz:

Para o tipo de extensão de arquivo .sh, consulte Bourne shell .

E quanto a outras conchas unix?

Eu sei que o shebang é usado dentro do arquivo para indicar um intérprete para execução, mas eu me pergunto:

Quais são os prós e os contras das extensões de arquivo versus nenhuma extensão de arquivo?

— Amelio Vazquez-Reina
fonte

4

Às vezes, scripts de shell sem shebang (ou sem permissões de exec) podem ser encontrados. Nesse caso, um nome terminado em .sh pode ser uma dica para o usuário executá-lo bash script.sh(ou sh, é claro).

— Ansgar Esztermann 15/02/12

3

Se um script de shell tem uma extensão, geralmente é .sh. Eu nunca vi um script .ksh ou .bash. A maioria dos scripts shell não possui extensão, como todos os scripts em /etc/init.d/* como exemplo.

— Richard Holloway

Embora uma conclusão simplista (sim ou não) seja opinião, as coisas a considerar não são.

— ctrl-alt-delor 17/10

35

Eu chamaria apenas .shalgo que deveria ser portátil (e espero que seja portátil).

Caso contrário, acho melhor esconder a linguagem. O leitor cuidadoso o encontrará na linha shebang de qualquer maneira. (Na prática, .bashou .zsh, etc ... sufixos são raramente utilizados.)

— Stéphane Gimenez
fonte

1

Somente nesta página, já podemos ver uma quantidade não trivial de pessoas usando-a. Por que você diz que eles são "raramente usados"? Alguma citação? Ou isso é meramente baseado na sua experiência?

— Pacerier 15/09/15

23

Eu diria que não existem "boas práticas" para extensões de arquivo, estritamente em termos técnicos: sistemas de arquivos Unix / Linux / * BSD não suportam extensões por si só. O que você está chamando de extensão é apenas 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 local especial no equivalente inode-moral é reservado para uma extensão.

Esse pequeno discurso agora acabou, acho um pouco tolo 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 intérprete em algum arquivo apenas por causa do sufixo do nome do arquivo. Tudo é feito pela #!linha, ou alguma outra seqüência de "número mágico" de bytes no início do arquivo. De fato, decidir o que executar com base em uma "extensão" de nome de arquivo é um dos fatores que tornam o Windows um imã 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 clicar duas vezes no botão "

O que você pode pensar como um comando direto geralmente é um script de shell de qualquer maneira. Às vezes cctem sido um script sh, firefoxé um script sh, startxé um script sh. Não acredito que exista um benefício cognitivo ou organizacional em marcar um script com o sufixo ".sh".

— Bruce Ediger
fonte

24

Discordo! Meu trabalho consiste em empacotar um aplicativo que envolve milhares de arquivos que variam de executáveis binários a scripts de shell (ksh, bash e alguns csh herdados). Para mim, acredite, faz diferença poder saber rapidamente (ou em uma regex) que tipo de arquivo estamos discutindo e procurando. O que quero dizer é que pode haver um benefício em distinguir o que é excutado e uma prática recomendada deve encorajar a declaração explícita do tipo de arquivo.

— 21412 rahmu

4

@rahmu: escreva isso como resposta. Dê algumas informações específicas sobre como os nomes distinguíveis em 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 ajuda você na execução de tarefas. Estou interessado em argumentos sérios contra o meu ponto de vista e estou disposto a mudar se estiver convencido. Votou seu comentário para provar isso.

— 22612 Bruce Ediger

3

Eu adoraria, infelizmente, só posso falar da minha experiência atual no meu trabalho atual. 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 vou olhar para ele esta noite depois do trabalho :)

— rahmu

2

@rahmu O comando "file" existe para determinar o tipo de arquivo. É capaz de distinguir scripts escritos para diferentes shells.

— Matt

3

Se você der uma .shextensão a um script de shell , precisará digitá-lo .shcomo parte do nome do comando ao iniciá-lo. Essa é a principal razão pela qual eu não gosto de colocar essa extensão (o mesmo com qualquer coisa que tenha uma linha shebang). BTW, o problema no Windows não é o .exeprefixo em si (é trivial criar um executável nomeado image.jpgno 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 o mesmo.

— Celtschk

12

Como alguém que trabalhou em uma infinidade de ambientes? Nix, tive que escrever em uma ampla variedade de conchas. Acredite ou não, através das plataformas, as conchas não são as mesmas. Portanto, se você mantiver 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 é um pouco diferente, você sabe quais scripts devem ser alvos de modificações. .sh .ksh .bsh .csh ...

— Jumpylodo
fonte

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

— Pacerier

Você não possui um #!no início do script (por exemplo #!/bin/bash)?

— ctrl-alt-delor 11/07

Gnu / Linux, BSD e UNIX são todos Unix. Não há necessidade de? Nix. Linux é um kernel, o Android usou o Linux, mas não é um Unix (a menos que você adicione software extra, nesse caso, você tem um aplicativo Unix).

— ctrl-alt-delor 11/07

@ ctrl-alt-delor: "Unix" é uma marca comercial . As pessoas costumam usar "? Nix" para evitar o problema da marca registrada (e dos pedantes).

— JS.

@JS `UNIX 'é uma marca comercial do The Open Group. Unix e unix não são greens.org/about/unix.html

— ctrl-alt-delor 17/10

6

Você não deve usar uma extensão para executáveis, pois eles não são intercambiáveis. Imagine que você possui um script de shell e a.sh, em seguida, reescreva em python a.py, agora você precisa alterar todos os programas que o chamam de script, e vazou detalhes de implementação.

Toda a extensão do 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.ogge 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 gastar muito tempo ensinando aos novos usuários todas as extensões de arquivo.

— ctrl-alt-delor
fonte

Outra razão para não usar *.shEu corri em é que Debian de run-partsnão executar scripts com extensões, como em /etc/cron.*/: archive.oreilly.com/pub/post/runparts_scripts_a_note_about.html

— Ross Patterson

5

Como você disse, as extensões de arquivo Unix são meramente informações. Você só precisa que seu script tenha uma aparência correta e seja executável.

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

Pessoalmente, uso as seguintes convenções, independentemente do shell usado (csh, tcsh, bash, sh, ...):

nenhuma extensão para scripts de sistema ou de alto nível (extremamente raro).
o .shpara scripts clássicos, de baixo a alto grau.

— Ouki
fonte

O que você quer dizer com "scripts clássicos, de baixo a alto grau"?

— Pacerier 15/09/2015

Eu acho que quis dizer abstração ou nível de organização com isso. Ou seja, você não se importa com qual ferramenta de idioma / script é usada por trás de alguns comandos: portanto, você não usa nenhuma extensão. Para outros, é bom saber que é um bash ou algum script exótico do ksh shell (com a extensão adequada). ... mas isso foi há 2 anos;)

— Ouki 15/09/2015

3

As extensões de script do shell são bastante úteis. Por exemplo, geralmente escrevo scripts que possuem vários 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 tornará isso muito útil, para reduzir falsos positivos. Ou se eu quiser fazer uma contagem de linhas de todo o meu código de base para esse projeto.

É doloroso ter que digitar a extensão ao executar o programa, por isso 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.

— Steve
fonte

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

— Pacerier 15/15

2

Como outros já disseram, o shell não se importa com extensões. No entanto, ele permite a rápida identificação humana de arquivos. Vejo arquivos terminando em .pyou .she sei rapidamente o que eles (pelo menos) devem ser. Como Steve diz, pesquisar por extensão de arquivo ou fazer uma contagem de linhas também são considerações práticas.

— qwr
fonte