Como saber que cabeçalho do script usar e por que isso importa?

raramente tenho de escrever scripts bash para vários fins não relacionados e, embora normalmente tenha uma boa ideia dos comandos que quero no script, muitas vezes não faço ideia do cabeçalho a usar ou porque estou a usar um quando o encontro. Por exemplo:

  • script de linha de comandos padrão:
    • #!/bin/bash
  • Python:
    • #!/usr/bin/env python

Os Scripts parecem funcionar bem sem cabeçalhos, mas se os cabeçalhos são o padrão, há uma razão para eles e não deviam ser ignorados. Se tem um efeito, então é uma ferramenta valiosa que pode ser usada para realizar mais.

minimamente, gostaria de saber quais os cabeçalhos a usar com os scripts MySQL e o que os headers fazem nos scripts Standard, Python e MySQL. Idealmente, eu gostaria de uma lista genérica de cabeçalhos ou uma compreensão de como criar um cabeçalho baseado em que programa está sendo usado.

Author: Still.Tony, 2014-02-12
Source

2 answers

Como o Kernel executa as coisas

Simplificado (um bit), existem duas maneiras que o kernel em um sistema POSIX sabe como executar um programa. Um, se o programa está em um formato binário do kernel entende (como ELF), o kernel pode executá-lo "diretamente" (mais detalhes fora do escopo). Se o programa é um arquivo de texto começando com um shebang, como 

#!/usr/bin/somebinary -arg

Ou o que-tem-você, o kernel realmente executa o comando como se tivesse sido dirigido para executar: 

/usr/bin/somebinary -arg "$0"

Onde {[[7]} está aqui o nome do ficheiro do programa que acabou de tentar executar. (Então você pode dizer imediatamente por que tantas linguagens de scripts usam # como um comentário-iniciador – isso significa que eles não têm que tratar o shebang como especial.)

Caminho e o comando env

O 'kernel' não olha para a variável de ambiente PATH para determinar de que executável está a falar, por isso, se estiver a distribuir um 'script' em python para sistemas que possam ter múltiplos versões do python instaladas, você não pode garantir que haverá um 

#!/usr/bin/python

env, no entanto, é POSIX , Então você pode contar com ele existente, e ele irá procurar python no caminho. Assim, 

#!/usr/bin/env python

Irá executar o programa com a primeira python encontrada no seu caminho.

BASH, SH e significados especiais para invocação Alguns programas têm semântica especial para como são invocados. Em particular, em muitos sistemas /bin/sh é uma ligação simbólica para outro shell, tal como /bin/bash. Embora bash não contenha uma implementação perfeitamente POSIXLY_STRICT de sh, quando é invocado como /bin/sh é mais rigoroso do que seria se invocado como plain-old-bash.

Limitações MySQL e arg

A linha shebang pode ser de comprimento limitado e tecnicamente, só pode suportar um argumento, por isso o mysql é um pouco complicado – você não pode esperar passar um nome de utilizador e nome de base de dados para um script mysql.

#!/usr/bin/env mysql
use mydb;
select * from mytbl;

Vai falhar porque o o kernel irá tentar mysql "$0". Mesmo que tenha as suas credenciais num ficheiro .my.cnf, o mysql tentará tratar "$0 " como nome de base de dados. Da mesma forma: 

#!/usr/bin/mysql -e
use mydb;
select * from mytbl;

Vai falhar porque novamente, "$ 0 " não é um nome de tabela (você espera).

Não parece haver uma sintaxe apropriada para executar directamente um script mysql desta forma. A sua melhor aposta é canalizar os comandos sql para o mysql directamente: 

mysql < my_sql_commands
 7
Author: kojiro, 2014-02-12 16:06:44

Http://mywiki.wooledge.org/BashGuide/Practices#Choose_Your_Shell

Quando a primeira linha de um script começa com {[[0]}, isso é o que se chama um "shebang". Quando o script é executado como um executável, o sistema operacional usa essa linha para determinar como executar o script, isto é, para encontrar o programa com que o script deve ser executado. É incorreto que "scripts funcionam bem sem cabeçalhos" -- se você não tem uma linha shebang, você não pode ser invocado usando a chamada execute (), o que significa que muitos (a maioria?) programas não serão capazes de executar seu script. Às vezes, a invocação de uma concha tentará usar a própria concha na ausência de um shebang, mas não se pode confiar que seja esse o caso.

(há uma excepção a isso -- se alguém iniciar o seu script executando sh yourscript ou bash yourscript, a linha shebang não é lida de todo, e o script que eles escolheram é usado; no entanto, executar scripts desta forma é uma má prática, como o autor normalmente sabe melhor do que o usuário o que é o interpretador correto).

Resumindo:

  • Se quiser usar funcionalidades modernas, e quiser que o Utilizador seja capaz de substituir a versão da linha de comandos em uso, colocando uma versão diferente da bash mais cedo no seu caminho, use #!/usr/bin/env bash
  • Se quiser usar funcionalidades modernas e garantir que corre sempre com a consola do sistema, use #!/bin/bash
  • Se vais escrever o teu guião para te conformares estritamente com o POSIX sh, usa #!/bin/sh

Não há uma lista limitada de linhas shebang que podemos dar-lhe, uma vez que qualquer executável nativo (programa não-script) pode ser usado como um interpretador de script, e, portanto, ser colocado em um shebang. Se você criou um arquivo chamado myscript com #!/usr/bin/env yourprogram, deu executável permissões, e correu ./myscript foo bar, isto iria resultar em /usr/bin/env yourprogram myscript foo bar sendo invocada; yourprogram seria executado por /usr/bin/env (depois de um CAMINHO de pesquisa), e seria responsável para saber o que fazer com myscript e seus argumentos.

Para um história extremamente detalhada das linhas de shebang e como elas funcionam através de sistemas modernos e antigos, veja http://www.in-ulm.de/~mascheck / various / shebang/

 4
Author: Charles Duffy, 2014-02-12 15:50:36